先日ポチったRaspberry Pi 5 16GB RAMを、まずはDockerホストとdnsmasqサーバーの移行先として構築しましたが、無事メモリ使い切れず、16GBもいらんかったか……となっている今日このごろです。用途によってはしっかり使い切っているという人も見かけたりはしますが、いやあ普通にむずいですね。
現在のメモリ使用量
というわけで現在のメモリ使用量は…… 2GB。つまり空きは14GB。4GBモデルで足りるやないか！！！
載せているものがなにもないのかと言えば、そんなこともないのですが、メモリ負荷が少ないコンテナばかりという説はあります。
コンテナホストなので、たとえば通常時のメモリ空き容量が残り2GBみたいなカツカツな運用をすると、コンテナのビルド時にメモリ不足で苦しむことになりそうなので、1/3くらいは余裕を持たせた状態で運用できればいいかなと思ってはいましたが、そもそも1/3すら使えていなくてさすがにワロタ。
サイジングをミスったかあ
Pi 5 16GB RAMに持ってきた物は、現状は以下の通り。こんなに持ってきてもまだ2GBなんですよね。っていうか、こうして列挙してみると、よくわからんものが大量に動いてるな……？
- ESXi上のdnsmasqのVMからdnsmasq
- ESXi上の雑用コンテナホストVMから全部のコンテナ
- ESXi上のMastodon/MisskeyサーバーのコンテナホストVMから、Misskeyサーバー
- 雑用ラズピッピからツール類
- Mastodonで動かすボット類
- 玄関のドアロック確認ツール
2.5VM（Mastodonは移行しない予定でいるため）の移行が終わったものの、メモリ使用量に反映されないのは、VMのOS部分のメモリが食っていたとか、VMへのメモリ割り当てに対してVM内の使用量がそもそもなかったのではとか、要因はありそうです。が、それにしてもメモリ使用量が少ねえな。自作のツール類は基本的にpythonイメージベースのただのスクリプト類なので、まあ、並べてもそんなには食わないか。
というわけで、現在はデスクの頭上で稼働するPi 4の中身を全部Pi 5に持っていって、物理ラズピッピの稼働数を減らす作戦も開始。ここは半年前にPi 2からPi 4に変えたばかりでしたが、Pi 5の置き場がないので、ここに来てもらおうかと。中身がいまだにBullseyeだったのでいい機会なのですが、エアコンと照明操作をやっているエアぴっぴのライブラリ周りがなんかダメそうなのが課題です。
dnsmasqの移行
ここからは、移行したサービスの移行メモ。
dnsmasqはUbuntu Server 20.04からの移行でしたが、ネットワークがsystemd-networkdからNetworkManagerに変わるため、それに向けた対応が必要でした。
まず自動起動に失敗する。なんでやねん。
/lib/systemd/system/dnsmasq.service のAfterを以下の通り変更すればOKとのことでしたが、最初からそうであってくれ感がすごい。NetworkManager以外の場合を考慮すればそうもいかんのは、そうなんですが。
```
After=network.target
↓
After=NetworkManager-wait-online.service
```
また、IPv6周りの名前解決がうまくいかなくなり、1週間くらい苦労しましたが、たぶん解決。1点は、ドメイン名をローカルで解決させるための設定をHGWに入れていたのを忘れていたので、これを更新。もう一点は、resolv.confにIPv6のDNSサーバーもいれる必要があった点。入れないとデーモンがIPv6でlistenしなくて謎。Ubuntuではそんなことしなくて良かったので、たぶんsystemd-resolvdが実はなんかやってくれていた可能性があります。
dnsmasq用にdnsmasq_resolv.confを書くことにして、dnsmasq_resolv.confにIPv6とIPv4それぞれの上位DNSサーバーを並べたところ、IPv4/IPv6両方でlistenするようになりました。ただこれも、再起動後の自動起動時にはIPv6のリッスンに失敗していたりして謎。完全解決が何故かむずい。
resolv-file=/etc/dnsmasq_resolv.conf
Dockerコンテナの移行
コンテナの移行はx86_64からarm64にアーキテクチャが変わることになりましたが、そこらの違いとかでつまづくことはほぼなく、スムーズに移行ができました。
移行のついでに、docker-compose.ymlの書き方を直したり（compose.ymlへのリネームはしてない）、Dockerfileのベースイメージを更新したりしました。あとは、ディレクトリ配置も変更。こんな感じにしてみました。
/home/akkie/docker/（コンテナ名） … コンテナの中身 /home/akkie/docker/volumes/（コンテナ名） … ボリュームのデータ
rpilocator_jaコンテナ
こいつはPlaywrightを使っていて、Chromeがコンテナ内で動きますが、x86_64のChromeをインストールするDockerfileになっていたため書き換え。Chromeにarm64版がないため、Chromiumを使えという感じっぽかったので、そうしました。x86_64のときにchromiumにしてなかったのはなんでだったっけな？また、Pythonイメージも3.12に変更。以前はライブラリのバグの影響で3.12の採用ができていませんでしたが、いつの間にか解消されていました。
use python3.12. use chromium instead of chrome · Akkiesoft/rpilocator_ja@ee6bc31 · GitHub
Misskeyサーバー
https://misskey.mugiko.moe をPi 5に移行しました。これも特筆することはなく、サクッと持ってこれました。これが一番のメモリ食いになることを期待しましたが、ビルド時を含めそんなことはなく。動作も特にもたつきはありません。強いて言えば起動が少し遅くなった気がしますが、逆に言えばその程度です。
Pi 5の動作温度とケース
Pi 5の動作温度ですが、なんと40度で動いています。しかしこれは、現在の配置場所がエアコンの風が当たる場所っぽく、これのせいで（暖気でも）冷却になっているようです。エアコンを止めると45〜50度くらいになります。
とは言え、ほぼ裸で運用するのもなんなので、ケースを会社の3Dプリンターで作りました。ただ、ケースを付けると熱がこもるようで、動作温度が50度より上になって、ファンもほぼ常時回転になるようでした。うーん、そもそもケースはいらない説がある……？というわけで今は一旦外していますが、一応紹介。
データはこちらの方のものを利用させてもらいました。
https://www.printables.com/model/909805-case-for-raspberry-pi-5-with-pimoroni-nvme-base-opwww.printables.com
こんな感じ。ボトムは普通の黄色で、トップは蓄光の黄色です。
ケースを取り付けるとこんな感じ。
そして部屋の電気を消すとぼんやりと光ります。実際は写真明るくはないですが、いいですね。
しかし、デスク上の雑用ラズピッピも統合すると決める前にプリントしたので、これだとGPIOの穴がないという問題が起こっています。GPIOポートの穴ありバージョンをプリントし直さないといけないか。先程の排熱を考えると、裸運用のまま行ってしまうべきなのか。せっかく作ったのに悩ましいところです。
まとめ
この程度の用途ではPi 5の4GB RAMでも十分という悲しい結論が今のところでています。かなぴ。
あとはもう他に統合できるものがない気がするので、一時的なコンテナを動かす場としてもガシガシ使わんと無理げってかんじです。
いま考えているのは、KVMもここで動かして、VMレベルで分離したいやつも乗せるプラン。そうするといよいよ本格的にメモリを使えそうですが、KVMホストはESXiホストだったやつであらためて構築してVMを持ってくるつもりなので、そこまでしなくてもいいなという感じはしています。
一旦はラズピッピのメモリのことは分かれて、自宅サーバーのESXiの置き換え関連の作業をすすめようとおもいます。今日はUbuntu Server 20.04のルーター兼VPNサーバーを24.04に移行しました。サクッと切り替えられたのでヨシ。NASのVMもやっつけるぞ。
そういえば
MagPi Issue 150で載ってました。150号記念で150のプロジェクトと人物の中で挙げられています。JeffとかPhilの並びにいるの、だいぶ恐れ多い。なお、次号からはタイトルが変わるんだそう。そのままでもいい気がするんですけどね。
