RunPodではじめる画像生成
格安クラウドGPUサービス、RunPodを用いた画像生成に成功したので、 その方法を備忘録として記しておく。
アカウント作成、入金などは割愛する。
方法
URLは以下から。右上の「Deploy X.X.X」をクリックすればできるはず。 https://console.runpod.io/hub/runpod-workers/worker-a1111
作成したendpointは、左メニューのResources->Serverless、またはデフォルトならトップ画面の右上から確認できるはず。 そこから、コマンドを確認できる。
$ curl -X POST https://api.runpod.ai/v2/{endpoint_id}/run \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer YOUR_API_KEY' \
-d '{"input":{"prompt":"a photo of an astronaut riding a horse on mars","negative_prompt":"blurry, bad quality","width":512,"height":512,"num_inference_steps":20,"guidance_scale":7.5,"seed":42}}'
AirTagを買った
先日、AirTagを買った。
タイトル通りなのだが、その際に調べたことを、
忘れてもいいように記しておきたい。
AirTagのしくみ
AirTagは、Appleから2021年に発売された、位置情報タグである。
これ自身はSIMも必要とせず、GPS機能も持っていない。
では、どのように位置情報を発信しているのかというと、AirTagが発するbluetooth電波を
他人のiPhoneなどが拾って、匿名で位置情報を伝えている。
以下、公式HPから引用。
あなたのAirTagは、近くにある「探す」ネットワーク上のデバイスが検知できるように、安全なBluetooth信号を送信します。
すると、信号を受け取ったデバイスは、AirTagの位置情報をiCloudに送信。
あなたは「探す」アプリを開いてマップ上で確認できるというわけです。このプロセスは完全に匿名で行われ、
情報は暗号化されるので、あなたのプライバシーは守られたまま。効率も良いので、バッテリー残量やデータ使用量を心配する必要はありません。1
この機能はAppleのFind Myというしくみに組み込まれている。
日本語では探すだったりデバイスを探すだったりする。
このFind Myに対応している機器であれば、AirTagと同じように使えたりする。
例えば、つい先日の2026年3月に発売されたXiaomi Tag(https://www.mi.com/jp/product/xiaomi-tag/)
であれば、AirTagと同じように位置情報を確認することができる。
AirTagの持つ、正確な場所を見つける機能は、UWBチップ非搭載のため使えないものの、
音を出すことは可能なので十分だったりする。
AirTagは定価4980円、Xiaomi Tagは1980円であるため、買うなら安い方で良かったな、
と若干思ったりしている。追加購入するときは、考慮に入れたい。
Androidでは
先程まで、Apple圏の話をしてきたが、Androidでも同様のしくみが存在する。
Find Hubというものらしい。が、私はiPhoneユーザーであるため、あんまり調べていない。
先述のXiaomi Tagは、こちらにも対応しているらしい。
まとめ
この機能は便利で月額課金などもない。すごい。後々「サブスク限定!」みたいにならないといいな。
kopiaの挙動についての調査
Veleroを使ってk8sをCloudflare R2にバックアップしている。
k8sシステムのバックアップは、backups/フォルダ内に日付フォルダが作成されて保存される。
私はバックアップを10日分と設定しており、それより前のフォルダはVeleroが勝手に消してくれる。
PVのバックアップにはVelero内部でkopiaが使われていて、差分バックアップしているらしい。
このバックアップのサイズが日に日に増えていっている。
Velero本体側は古いファイルは確実に消されているが、kopia側は内部がよくわかんない。
その原因を調査すべく、我々はアマゾンの奥地へと向かった。
まず、S3 Browser(https://s3browser.com/)を使用してバックアップサイズを確認する。
PV以外が原因の可能性もあるため(kopiaが原因でない可能性もあるため)、念のため
backups/
31.63 MB (33 166 071 bytes)
kopia/
730.84 MB (766 345 759 bytes)
この時点でkopiaが原因であることは確定だが、もう少し深堀してみる。
Veleroは、namespaceごとにkopiaのバックアップリポジトリを作るらしい。
リポジトリごとのサイズを見てみよう。
kopia/kube-system/
960.84 KB (983 897 bytes)
kopia/default/
149.79 MB (157 062 963 bytes)
kopia/commafeed-k8s/
580.12 MB (608 298 899 bytes)
commafeed-k8sのサイズが大きいので、原因が簡単にわからないか見てみよう。
まず、以下のコマンドでkopiaでリポジトリに接続する。
$ kopia repository connect s3 --bucket=velero-backup \
--access-key=MY_ACCESSS_KEY \
--secret-access-key=MY_SECRET_ACCESSS_KEY \
--endpoint=my_endpoint.r2.cloudflarestorage.com \
--prefix=kopia/commafeed-k8s/
「映画ドラえもん のび太の絵世界物語」を見に行った話
少し前になるが、ドラえもんの映画を見に行った。
別に書くほどの内容でもないのだが、記憶容量を空けるために、その時のことを書いておく。
見に行ったのは4月12日土曜日。場所も書いてもいいのだが、ネットに晒すわけだし、伏せておこう。
見に行ったきっかけというか、ある人に、見に行ったほうがいいとラインが来て、見に行ったわけだ。
そいつに、具体的な感想を話そうかと思っていたのだが、
当分会う機会も無さそうなので、ここで吐いておく。
感想を書くと、まあ良かった。
シナリオは、シンプルオブシンプルである。
こいつは、敵と見せかけた味方だろうな、というやつは、やっぱり味方。
こいつは敵だろうなという奴は、やっぱり敵。
日常パートで変な使い方をしたひみつ道具は、最終決戦で使う。
ヒロインが変な動きをしたら、その理由は最後に明かされる。
ジャイアンは男前。何の捻りもない王道の筋書きである。
だが、それがいいのである。劇場版ドラえもんに変なことなんて望んでいない。
私が見たい劇場版ドラえもんがそこにあった。
そして、ドラえもん、劇場版ドラえもんへの愛が多分に感じられた。
ほんやくコンニャク、きせかえカメラ、と言った劇場版の定番道具はもちろん、
水加工用ふりかけ、かるがるつりざおといったマイナー道具、
そして、チンカラホイ、テケレッツノパー、といった作品内のオマージュ、
また、誰もが忘れているであろう、パパの絵が上手い設定、等、
ドラえもんコミックス内の情報を広く扱っている。
これはドラえもんファンもニッコリである。
結局、みんなはミームが大好き、ということなのかもしれない。
ドラえもんミームである。それが、ファンの見たい物だったのかもしれない。
ドラえもんファンが作ったドラえもんファンの映画。それが本作なのかもしれない。
調べたら、本作の脚本家は大変なドラえもんマニアだったようだ。
忘れてもいいようにリンクを貼っておく。(今、私が書いているこの記事は何の案件でもないしリンク先から1円たりとももらっていないことも念の為に書いておく)
NEWSポストセブン 『映画ドラえもん のび太と絵世界物語』制作陣インタビュー#2 『映画ドラえもん のび太の絵世界物語』脚本家が明かす「こだわりのオマージュ」、考え抜いた「王道の展開」
以上。
ラズパイ内のKubernetesでPodを動かす
自分の RaspberryPi 4B でk8sを動かすことに成功したので、
備忘録としてその記録をまとめておく。
インストール
公式に出ているkubeadmでインストールする方法は、難しすぎて
実質不可能なので、おとなしくk3sを使う。
公式のクイックスタートのコマンドそのままだと書き込みできずにエラー発生するので、
以下のように権限644を付加する。1
curl -sfL https://get.k3s.io | K3S_KUBECONFIG_MODE="644" INSTALL_K3S_EXEC="server" sh -
もしくは、設定ファイル/etc/rancher/k3s/config.yamlで権限付加を明記し、サービス再起動でもいいだろう。
write-kubeconfig-mode: 644
サービス再起動は以下のコマンドでできる。2
停止
sudo systemctl stop k3s-agent
起動
sudo systemctl start k3s-agent
これでk8sのインストールは完了
PodとServiceの起動
基本的に公式のチュートリアル
に従ってPodの導入とServiceの起動ができる。
しかし、imageはarmには対応していないようなので、別途指定する必要がある。
今回は、動かせばいいだけなので、適当にnginxのimageを使用した。
そして変更してできたmanifest、load-balancer-example.yamlが以下。
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app.kubernetes.io/name: load-balancer-example
name: hello-world
spec:
replicas: 5 # 1でも動きます
selector:
matchLabels:
app.kubernetes.io/name: load-balancer-example
template:
metadata:
labels:
app.kubernetes.io/name: load-balancer-example
spec:
containers:
- image: docker.io/arm64v8/nginx # arm対応imageを指定
name: hello-world
ports:
- containerPort: 80 # Pod側の待受ポート
iTunesの引っ越し方法
先日、古いPCからiTunesを引っ越しする機会があったので、備忘録がてら記録。1
丸ごと引っ越しする場合
引っ越し前のPCでやること
iTunesに音楽を取り込む際に、適当なフォルダから取り込むなどして、
実体ファイルがバラバラなことがあります。
その実体ファイルをまとめます。
iTunesを起動します。左上のファイル->ライブラリ->ライブラリを整理をクリック。
「ライブラリを整理」ウィンドウが表示されるので、「ファイルを統合」にチェックを入れて
「OK」をクリック。
これで、「ミュージック」フォルダ内の「iTunes」フォルダに、音源の実体ファイルがまとめられます。
この「iTunes」フォルダを新しいPCに移動します。
引っ越し後のPCでやること
元のPCから移動した「iTunes」フォルダを引っ越し先の「ミュージック」直下に入れます。
shiftキーを押しながらiTunesを起動するとフォルダ選択を迫られます。
配置した「iTunes」フォルダ内の.itlファイルを選択します。
この操作は必要ないかもしれません。
一部だけ引っ越しする場合
既に引っ越し先のiTunesに音楽が入っていて、音楽フォルダを追加したい場合です。
引っ越し前のPCでやること
音楽フォルダを新しいPCにコピーします。以上。
引っ越し後のPCでやること
iTunesでファイル->フォルダをライブラリに追加から旧PCから持ってきた音楽フォルダを選択します。
それで、音楽がiTunesに取り込まれるはずです。
その後、実体を取り込むために、左上のファイル->ライブラリ->ライブラリを整理をクリック。
「ライブラリを整理」ウィンドウが表示されるので、「ファイルを統合」にチェックを入れて
「OK」をクリック。
これで、音楽/iTunesフォルダの容量がちゃんと増えているはずです。
不要になった、旧PCから持ってきた音楽フォルダを削除します。
(正しく実体が残っているか再生するなどして念のため確認してください)
わんだふるぷりきゅあ感謝祭
何を血迷ったか、今日記を書いている。
今は東京にいるのだ。具体的に言うと、皇居北側の喫茶店。ティールーム花。
当たりである。ブレンド440円、サンドイッチ380円とかなり安い。
ここでなんとか有意義な時間を作ろうとしたものの、残念ながら
私はそこまで殊勝な人間ではなかったようだ。無念。
そして今は2月10日。わんぷり感謝祭を終えた月曜日。
また次の曲が始まるのです。
感謝祭に行って最も良かったのは、松田颯水の挨拶。
オーディションに落ちても、また受けさせてくれた事務所への感謝。
自分をそこの枠に割り当ててもらえることへの感謝を述べられていた。
本当はもっとお金落とさなければいけないのだろうけれども、
モノを管理したくないし、安く済ませるのなら安く済ませたいから、あまり買っていない現状。
疲れたので書くのはここまで。
AWSで自宅を固定ドメインにする
前提
DDNSの仕組みを利用します。以下を満たすものとします。
- ドメインを既に保有している
- 自宅が動的グローバルIP
しくみ概要
家の端末から、lambdaにアクセスして、グローバルIPを取得します。
再度lambdaにアクセスし、既存のDNSレコードとIPが異なるなら、DNSを更新します。
つまり、lambdaは二度実行されます。
方法
基本的にAWS公式サンプル
の通りに実行すれば導入できます。
1. AWS CloudShell から以下を実行します。
git clone https://github.com/awslabs/route53-dynamic-dns-with-lambda.git
pip install -r requirements.txt
2. DNS レコードの更新をテストするために以下パッケージを追加します。
sudo yum update
sudo yum install perl-Digest-SHA
3. 以下コマンドでデプロイします。
cdk bootstrap
cdk deploy
4. 設定を行うために付属のnewrecord.pyを実行します。
python3 newrecord.py
このコマンドは、さきほどのCDKがデプロイされているか確認します。
デプロイされていない場合、以下を返却します。
Dyndns stack not found, ensure the right AWS CLI profile is being used.
ホームページ作成
ホームページを作成しました。
無為に日々を生きているような気がして、
何か情報発信する場を設けるためです。
うまいこと、進めていけたらいいなと思います。