M1Macminiのサーバー運用は相変わらず快適なのだけど、特にサーバー運用時にはDockerが便利。
コンテナという仕組みがメンテナンスに大助かりで、豊富なWebUIに対応することも利便性向上に拍車をかけている。
macOSは標準でかなりの数のサーバー機能が使用可能だけど、それでも出来ない部分をDockerコンテナに任せることで更なる拡張が可能。
そして何よりmacOSの標準機能を超えた部分を全てDockerコンテナで実行することで、設定AppとDockerだけで全ての機能の管理が可能になるのが優秀。とても素晴らしいソリューションである。
問題点
それほど素晴らしいDockerであるのだけども、せっかく使うのならば全てDockerに任せてしまいたくなるのは人間の性というものだろう。
わたしもVPN環境構築をきっかけに、次々とコンテナを導入した。今後はn8nやnodeREDなんかも使おうとしているから、益々活躍することは間違いなし。
ところがそんな中、Dockerコンテナという檻に入ることを拒む者がいた。
そう、Homebridgeである。
どうしてこうなったのか
Dockerとは仮想環境の一種であるため、大抵全てはLinux環境をベースに・・・もとい前提にしている。
しかしDockerは完全な仮想マシンではなく、軽量化のためにホストとなるOSのカーネルの機能を一部流用している・・・らしい。詳しくは知らないけど。
macOSは元々Linuxに近い血を引いていることもあって問題にならなかったけど、Homebridgeでは遂に問題が出た。
症状はいたって単純で、Homekitにブリッジを追加する際に見つからないと表示されるのみ。
しかしコンテナ内のWebUIにはしっかり別デバイスからアクセス可能であり、なんならWebUI内でSwitchBotのプラグインの動作確認すら取れている。しかし一番重要なHomekitへの追加のみが行えなくなってしまうのだ。ダメじゃん。
もちろんmacOSにHomebrewとnpmで突っ込んでいれば問題なく動作するし、なんならBonjourとか考えなくていい分LinuxやWindowsより遥かに楽である。それが Dockerコンテナに放り込んだ瞬間にこれ。わけがわからん。
一応原因らしいものとして、Host Networkingという機能に非対応であることが挙げられていた。GitHubのこことここで取り上げられており、Dockerにブチギレている様長々と議論されている様子が確認出来る。
しかし肝心の—net=hostオプションは既に対応が表明されているし、そもそもHost Networkingを要する理由もいまいち分からないしで、Discordコミュニティを含めてお手上げ状態。
試行錯誤の記録
解決方法として主流なのが、大人しくHomebridgeにはLinux仮想マシンを用いるというものであった。あえてDockerを使う理由にホストOSの環境に傷をつけたくないことが挙げられるため、それを満たすには仮想マシンが最適だろう。
幸い軽量なLinuxを動作させる事例は多くあるし、ラズパイの恩恵であのUbuntuもARM版が存在するためAppleシリコンMacでも困ることもない。Homebridgeも64bitARMのラズパイ稼働が主流なため、Macホストでの仮想マシンによくあるアーキテクチャの違いで困ることは全くないと言える。ラズパイ用のOSを使い回せるのはARM64であるAppleシリコンのメリット。
しかし、それでは管理方法が疎かになっているのではないか。と、考えた。
しょーじきこの辺で「もうそこまで行くと法人レベルの案件じゃね？」とか「そもそもホストOS直接稼働で困ってないんだから別によくね？」とか一瞬思ったけど、そういうのガン無視しないと生きていけない生物なので無視することに。
方法論
Dockerコンテナとしての管理を可能にしながら、ホストをmacOSとしてHomebridgeを動作させる。しかしDocker Desktop for Macは使えない。
解決方法としていくつか挙げられるが、最終的には素直な仮想化となった。
没案1:Rancher Desktopを使う
これはDocker Desktopと同じく、Dockerコンテナを扱えるmacOS App。
Docker Desktopの商用利用有償化に伴って利用する人が増えたらしく、それなりに実行された記録がある。
Homekitに追加できないのはDocker Desktopの問題である、とフォーラムに記載されていたので、Docker Desktop以外を使えばいいと考えた。
完全移行を考えて他のコンテナを移動していくと問題なく動いたので、Homebridgeも同じく導入。
しかしダメだった。いやDocker Desktopよりマシであるのだが、結局何もできなかった。
ちゃんとアクセサリとして認識されるのでいけると思いきや、通信できませんの一言で断罪された。
まだ可能性はあるので、追求していけば実現できそう・・・なんだけど。言い訳させてもらうとRancher Desktop、UIが物凄く使いづらいのだ。
コンテナ一覧で停止しても自動更新されず、設定項目にネットワークの項目がないから打つ手なし、原因を調べるのも億劫になる程面倒なUIだったので管理環境として微妙であった。
まあ他の手段だとどうせPortainer任せになることが見えていたのでUIがあるだけマシなのだけど、せっかくUIがあるのなら活かしたかったので泣く泣く断念。
というわけで没案1が誕生した。
没案2:Dockerコンテナとして仮想マシンを動かす
仮想マシンでDockerを動かすのとは逆で、こちらはDockerコンテナの中に軽量なLinux環境を突っ込んでその上にHomebridgeを載せようというアプローチ。
標準だとDockerコンテナはmacOSの機能を流用して補完するため、補完しきれなかった部分を動作させられない。これがHomebridgeで必要なものと一致してしまったために今回の問題は起きている。
であればHomebridge用のDockerコンテナの中にホストOSに依存しない完全なLinux環境を用意してしまえば、そのLinux環境で動くHomebridgeの動作に問題はないのでは？ということ。
そしてここに突っ込むHomebridgeはDocker版ではなく直接稼働させるので、結果的に「ちょっとリソース多く消費するけどmacOSでも使える、Homebridgeが動くDockerコンテナ」が完成するという寸法である。UTMを使った方法と比べると利点は遥かに多い。
要するにMacで動くHomebridgeのDockerコンテナを自作するわけだから、Docker Desktop for Macで今までと変わらない管理が出来るし、IPアドレスの共有も可能だからUTMのようなトラブルも起きない。
そして何より稼働時の見た目が美しいので、実現すれば儲け物くらいの感覚で挑み始めた。Linuxが入ったDockerコンテナとして、multiarch/ubuntu-core(Docker Hub)をチョイス。
Ubuntu Coreは他のソフトが実行可能なOSレイヤーとdpkg・aptのみが含まれた最小規模のUbuntu。Dockerの代わりにdpkgとaptを組み込んだBurmillaOSのような存在で、規模の割に無限に拡張可能でかなり万能なOSに仕上がっている。
研究を進めていく上で分かったのだけど、Apple仮想化を使わずにネットワークデバイスを見直していけばこの手法もワンチャンあるかもしれない。とはいえ相変わらずnet=hostオプションの動作次第な部分が大きい。
成功:UTM+BurmillaOS
単純な仮想マシンだと管理が面倒になるのなら、仮想マシンの中のDockerに全コンテナを突っ込んでしまえば統括管理できるはず。
Portainerがあれば仮想マシンを覗かずにコンテナの追加削除再起動なんでも出来るし、仮想マシンの中であっても大きく差は出ないと考えた。
そして出てくる、Docker専用OSなるものの数々。
特にやばいのがRancherOSで、ほぼLinuxカーネルとDockerのみで構成され徹底的に無駄を削ぎ落とし、残されたのはDockerコマンドと専用のWebUIのみという凄まじい存在。
しかしコイツはどうやら開発終了したらしく、後継としてBurmillaOSが登場していた。
このBurmillaOSはAppleシリコンのmacOSで動作検証してあり、UTMのエミュレート機能を使えば動作するとのこと。ラズパイで動くくせにARMの仮想環境で動かないのは納得いかないけど、検証されているのは非常に助かる。
そしてコマンドラインに慣れない中起動まで進め、ライブブート環境で試行錯誤すること約8時間・・・ブリッジの追加まで完了！
当然WebUIもしっかり動作しており、他のコンテナを全てここに放り込めばPortainerでのGUI管理も可能だろう。
URLに書いてある通り、起動するには仮想マシンのUEFIを無効にしモニターデバイスをvirtio-vgaにしてあげる必要があることに注意。
引っかかったポイントとして2点。1つはUTMのネットワーク設定。
初期設定だとホストのIPアドレスを共有するモードになっているけど、これだと仮想マシンにはホストOSからしかアクセスできないらしい。
この状態では当然Homekitもアクセサリが見つからないとか言い出すので使用は不可能。試してみたところブリッジで別のIPを割り当ててやれば動作したので、別のIPである前提で考えた方が無難かもしれない。仮想的にラズパイ置いてるイメージ。
IPアドレスはHomebridge起動中のコマンドラインでサラッと流されるのでそこで確認出来るほか、MACアドレスはUTM側で自由に設定できるのでルーターで固定することも可能。
もう1つはストレージ。何も考えずにぽちぽちして進めていくとライブブートになり恐らくRAMにデータ保存しているので、仮想マシンのメモリを盛っていないと何も出来ない上に再起動すれば全てのデータが消えるという、ちょっとなんのために導入したのか分からない状態になってしまう。
なんでこんな当たり前のことをわざわざ言うかって？こんなことにも気付かずにISOをqemu-imgでqcow2に変換しては容量足りないなあとかほざいて(実は起動は成功した)、データ消えるってことはサスペンド運用なのかなあとか半日試行錯誤したドアホがいたからだよ。Ubuntu触ったの10年前だからライブブートの存在覚えてなかったの許して
一通り検証を終えた後にインストール完了、設定していくとついでに今まで出来なかったIKEv2VPNまで設定できてしまってびっくり。
このBurmillaOSもARMじゃないためエミュレートになってリソースに無駄が生じるなど弱点は残っており、最終的にはARM64対応のAlpineベースで落ち着いた。
所感
とりあえずHomebridgeが動けばいいやと思っていたら、IKEv2のVPNまで動いて熱が入ってしまった。かれこれ数日これにかかりきりで、例のシステムの見直しなんか吹っ飛んでしまっている。
仮想Linuxは地味にARM64なMacのメリットが活かされており、ラズパイで培われた各種OSを片っ端からエミュレートなしで試せるのは非常に優秀。Dockerに適した超軽量OSも色々存在していて、特にWebUIを備えたRancherOSの存在を知れたのは大きい。
最近はWebUIの便利さに気付き始めたところだったけど、地味に今回でSSHの利便性に気付いた。
得られた知識は糧にしつつ、更なる深掘りを続けていく予定。
