鯖缶

#70#note-2:

もうひとつの問題は、 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: ネットワーク関係の設定についての知見がない

メインストレージ上での重複は後で考えるとして、バックアップの dedup については PBS を使うことでかなり良好に解決できそう。 (cf. #133)

Docker (compose) コンテナを動かすことだけ考えた distro を使いたい気がして、 Flatcar Container Linux などが良さげではある。
しかし現状 Proxmox VE の VM/CT のプロビジョニングを自動化できていない (日常の保守作業は ansible である程度自動化できているがインスタンスの作成・破棄が手動になっている) 以上、 VM/CT 作成の段階でパラメータを与えるタイプの Flatcar は果たして Debian + ansible に比べていかほど作業が楽になるか疑問でもある。

惰性で Debian の上に Docker を乗せて使っているが、ディスクの浪費以外にはそこまで困った要素がない。

たとえば Ryot のサーバは以下のような感じ。

• ホスト:
  • /var: 1.9 GiB
    • /var/lib/docker: 1.7 GiB
  • /usr: 563 MiB
  • (total: 2.5 GiB)
• コンテナ内:
  • /home: 237 MiB
    • /home/ryot: 237 MiB
      • /home/ryot/node_modules: 235 MiB
  • /usr: 211 MiB
  • (total: 462 MiB)

つまり今回の例だと、実際のところコンテナを使ったことによるオーバーヘッドといえそうなのは、コンテナ内の /usr (211 MiB) と、ホストの /var/lib/docker のうちコンテナ内のサイズに反映されていない量 (1.7 GiB - 462 MiB ≒ 1.2 GiB) 程度で、足して 1.4 GiB くらい。
もちろん Dockerfile 次第ではあるだろうが、今回の例が最終イメージのベースに alpine 等でなく node:20.10.0-bookworm-slim を使っている ことを考えると、思ったより状況は良さそう。

100コンテナ立てても大雑把に 150〜250 GiB のオーバーヘッドだとすると、どうにか耐えられないことはないかもしれない。
(ひとつのサービスあたり複数コンテナを使うことも多いが、その場合コンテナあたりのオーバーヘッドは多少軽減される。)
困ったら 1 TB しか積んでいない NVMe SSD をもう2〜3倍にすればいい。
あるいはもっとサイズ優先で SATA SSD を積みまくるか。

簡単にできそうなものから脱 Docker するという手もなくはないが、脱 Docker とベアメタルインストールが簡単にできそうかはストレージオーバーヘッドのデカさと実はあまり関係がなさそうだったりするのが悩ましくもある。
簡単にできるものほど脱 Docker するメリットが薄いという嫌な相関がないぶんだけマシではあるが。