機能 #70
完了
Ryot サーバを docker compose で立てなおす
nop_thread さんが11ヶ月前に追加.
4ヶ月前に更新.
説明
Is precompiled binary installation still supported as first-class citizen?
No, I can provide some help with it but I removed it since the server now has 4 running components: supervisord, caddy, backend and frontend. (It had only 1 earlier).
--- https://github.com/IgnisDa/ryot/issues/535#issuecomment-1872935838
シングルバイナリで動かす形式はもうちゃんとサポートする気がなさそうということで、実際アップデートに伴う DB マイグレーションもままならない状態になっているため、 docker compose に移行したい。
移行といっても Ryot サーバは立てて1週間程度であるうえ大したデータも入っていないため、立て直して同じデータを手動で入力しても良いくらいである。
web UI からのエクスポート→インポートで楽できるようなのでそうするつもりだが。
関連するチケット
4 (0件未完了 — 4件完了)
問題は、 docker 系を Proxmox VE で扱うのには一度失敗していることである。
当時は何に引っ掛かったのだったか……ネットワーク系 (特にパブリック IPv6 アドレス) の何かか？
ぼんやりした記憶だが、コンテナにパブリック IPv6 アドレスをどう割り当てるかで引っ掛かっていたのであれば、 HTTP/S のみを listen するようなサービスについてはこれは問題ない。
Cloudflare Tunnel を使うなりプライベート IPv4 アドレスで露出して別コンテナで reverse proxy を立てるなりで方法はいくらか思い付く。
もうひとつの問題は、 docker を動かす LXC コンテナを立てるのか、立てるならアプリごとに分割するか無関係なアプリまで全部乗せるか、あるいは Talos Linux で組んでいる Kubernetes クラスタを動かすのかの選択。
- アプリごとに LXC コンテナ (あるいは QEMU VM) を立てる (つまりだいたい LXC コンテナあたり compose.yaml が1つ対応)
- pro: よく隔離されるので、管理やインスタンス移動が楽
- con: /var/lib/docker の重複が激しくなる
- ZFS の dedup を使う手も考えられなくはない……と思ったが、たぶんその場合は ZFS pool ごと dedup を有効化せねばならないので面倒なのと、これだけのために FS のメモリ使用量を増やすのも嫌
- docker 用ぜんぶ乗せ LXC コンテナ (あるいは QEMU VM) を立てる
- pro: メモリ使用量は多少節約できるかも (大差ないかも)
- pro: /var/lib/docker の重複によるストレージオーバーヘッドを最小にできる
- con: 仮想ハードウェアリソースの割り当てが難しくなるかも
- con: 正しく動かすのが面倒になるかも
- ストレージ、ネットワーク資源、ネットワークアドレス、 docker 設定等の一部リソースが共有されてしまうため
- con: 自動化による管理が面倒になるかも
- 無関係なアプリを詰め込むのは VPS で経験があるが、あまり良い体験ではない
- 特に厄介なのは Proxmox VE レベルでの VM/CT スナップショットも全部乗せになってしまうためアプリ単位でのロールバックが難しくなること
- Kubernetes クラスタに乗せる
- pro: k8s はまさにこのための基盤なので (k8s さえちゃんと使えれば) 扱いやすいはず
- con: ansible での統一的な管理は難しくなるか？
- k8s の構成ファイル (deployment?) は ansible playbook と同じレイヤーのものなので、2つの構成管理を共存させることになる
- もしかすると ansible で
kubectl apply 的なことをできれば問題ないかも (できないはずはないが、綺麗に管理できるかは知らない)
- con: ノードを QEMU VM 等の仮想マシン (not LXC コンテナ) に乗せているため、オーバーヘッドがいかほどのものか不明
- con: VM を使うと Proxmox VE レベルでのリソース割り当ての柔軟性が損なわれる
- 一応 cordon してから drain で別ノードにコンテナを逃がしてシャットダウンして設定を変えて……などはできるが、面倒だし余計なリソースは食う
- con: ストレージバックエンドについての知見がない
- con: ネットワーク関係の設定についての知見がない
- 関連している 機能 #54: Ryot サーバを立てる を追加
- 題名 を Ryot サーバを docker compose で立てる から Ryot サーバを docker compose で立てなおす に変更
- 関連している 機能 #98: 自宅クラスタ (chuable, feng) 用の Docker レジストリの整備 を追加
- 関連している 機能 #139: chuable 上での docker コンテナの管理 を追加
- 関連している を削除 (機能 #139: chuable 上での docker コンテナの管理)
- 次のチケットに後続 機能 #139: chuable 上での docker コンテナの管理 を追加
実験も兼ねてということで、 Debian + docker-ce + cloudflared で立てた。
今のところ問題なく動いてそうに見える。
- ステータス を 新規 から 終了 に変更
- 開始日 を 2024/02/13 にセット
しばらく運用しての所感。
バージョンアップの様子がなかなかアグレッシブかつリリース形態もユーザーフレンドリーでないため、かなり不安視している。
マイナーバージョンどころかリビジョンの変更で設定ファイルの互換性が壊れたりとか、そのくせリリースノートは上書き型で各リリース間での変更 (特に設定スキーマの差分) は確認できないとか。
I normally just delete the releases that are generated by patch upgrades and put the release notes in the older release. For example, if I release v3.4.5, I will delete the release created by github actions and put the release notes in v3.4.0.
—— https://github.com/IgnisDa/ryot/issues/535#issuecomment-1872935838
あとは docker で v6 タグを追い掛けていると v6.8 が出ているのに v6.7 が最新として降ってくるとか。
エラーの様子からすると、詳細は確認できていないが気付かぬうちにバージョンが下がっていた可能性すらあると思っている。
いつ動かなくなっても不思議ではないので、管理は手間かもしれない。
今の状態で人におすすめするのは難しい。もっと楽できる自由ソフトウェアなプロダクトがあるならそちらを先に試すのが良さそうと感じている。
とはいえこれは運用面の話で、機能面では今のところ特に良くないと感じるようなところはない。
認証なしでの公開機能とかは community version ではなく pro version にのみ実装されるようだが、そういった機能の乖離や更には community version の骨抜き化のようなことがこれからどの程度進行するのかは注視していく必要があるかもしれない。
(export 機能があるのでロックインを過剰に心配する必要は今のところないと思うが。)
他の形式にエクスポート: Atom
PDF