DockerはProxmox LXC内でのネイティブなパッケージインストールと比べて運用上の価値をもたらすのか？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

Does Docker Add Operational Value Over Native Package Installs Inside Proxmox LXC? - Zima Store Online

アプリケーションがOCIイメージまたはComposeスタックとして配布され、依存関係の分離が必要で、バージョン管理された定義からホスト間で再作成すべき場合、DockerはProxmox LXC内で運用上の価値をもたらします。1つの安定したLinuxサービスがsystemd、デバイス、ユーザー、ネットワーク、またはディストリビューションのセキュリティ更新と深く統合する場合、通常はネイティブパッケージのインストールのほうがシンプルです。追加のDockerレイヤーは、再現性とアプリケーションのライフサイクル分離が、ネストされたストレージ、ネットワーク、cgroupの複雑さを上回る場合にのみ価値があります。

同じLXC内における2つのアプリケーション管理モデルの比較

どちらの方式でも、外側のゲスト境界はProxmox LXCが定義し、Proxmoxホストのカーネルを共有します。違いは、そのゲスト内部で何が起こるかです。ネイティブインストールでは、アプリケーション、ライブラリ、ユーザー、サービスユニット、ログ、設定がLXCファイルシステムに直接配置されます。Dockerを追加すると、デーモン、イメージレイヤー、コンテナネットワーク、ボリューム、そして別のアプリケーション分離モデルが加わります。

ProxmoxはLXCを、pctツールキットで管理される基盤となるLinuxコンテナ技術と説明しています。LXC内にインストールしても、Dockerがこの境界を置き換えるわけではありません。Dockerは、外側のゲストと共有ホストカーネルに依存し続ける、ネストされたアプリケーションコンテナを作成します。

したがって、判断すべきことは「コンテナか、コンテナでないか」ではありません。1つのシステムコンテナを従来型のLinuxサーバーとして動作させるのか、それともDockerアプリケーションホストのように動作させるのか、という点です。

運用上の比較軸	LXC内のDocker	LXC内のネイティブパッケージ
デプロイ定義	イメージタグ、Compose YAML、環境、ネットワーク、ボリューム	ディストリビューションのパッケージ、リポジトリ、設定ファイル、systemdユニット
依存関係の分離	各イメージが独自のユーザー空間依存関係を保持可能	サービスがLXCのパッケージデータベースとライブラリを共有
更新	イメージをプルまたはビルドし、コンテナを再作成して、マウント済みデータを保持	ディストリビューションを通じてパッケージをインプレースでアップグレード
ロールバック	以前のイメージと互換性のあるデータ状態に戻す	パッケージのダウングレード、ファイルシステムスナップショット、またはLXC全体のロールバックを使用
デバイスアクセス	デバイスをLXC経由でDockerに渡す必要がある	アプリケーションがLXCのデバイスノードを直接使用
ネットワーク	ネストされたDockerブリッジ、ポート、DNS、ファイアウォールの動作	サービスがLXCのネットワーク名前空間に直接バインド
バックアップ	Composeファイル、シークレット、バインドマウント、名前付きボリュームのデータを保護	LXCファイルシステムと外部マウント、データベースを保護
最適な用途	複数サービスまたはベンダーによってコンテナ化されたアプリケーションスタック	OSとの統合性に優れた、単一の安定したデーモン

アプリケーションがすでにスタックとして定義されている場合、Dockerは価値をもたらします

多くのセルフホスト型アプリケーションは、主要なインストール方法としてイメージとComposeの例を公開しています。サービスイメージ、環境変数、ポート、ネットワーク、ヘルスチェック、シークレット、ボリュームを、パッケージコマンドやサービスファイルに分散させるのではなく、バージョン管理された1つのファイルに定義できます。

Dockerは、Composeによって、サービス、ネットワーク、ボリュームを1つのYAMLモデルで管理できると説明しています。別の担当者や交換用ホストが、定義と保護されたデータディレクトリから同じアプリケーションを再構築できる場合、これは運用上重要な価値になります。

この利点は、複数サービスのアプリケーションで特に大きくなります。Webアプリ、データベース、キャッシュ、ワーカーを1つのComposeプロジェクトとバージョン境界で共有できます。アップストリームのコンテナ手順をすべてネイティブパッケージ、ユーザー、サービスユニットに置き換えるよりも、スタックを再構築するほうが明快な場合が多くあります。

LXCがすでにアプリケーションの境界になっている場合は、ネイティブパッケージが有利です

サービスごとにLXCを1つ用意すれば、独立したファイルシステム、ネットワークID、リソース制限、バックアップ対象、オペレーティングシステム環境がすでに提供されます。アプリケーションが必要としない境界をDockerで追加すると、重複が生じる可能性があります。ネイティブデーモンはsystemdで実行し、標準ログに書き込み、ディストリビューションのユーザーを使用し、通常のパッケージマネージャー経由でセキュリティアップデートを受け取れます。

この方式は、ディストリビューションが適切なバージョンを提供している場合、DNS、監視エージェント、VPNエンドポイント、Webサーバー、小規模データベースなど、安定したインフラサービスに特に適しています。パッケージデータベース、サービスマネージャー、トラブルシューティング対象のネットワーク名前空間がそれぞれ1つで済みます。

必要なバージョンがディストリビューションと競合する場合、アプリケーションが多数のカスタムライブラリを必要とする場合、またはアップストリームがコンテナイメージでのみテストしている場合、ネイティブ方式は不利になります。Dockerを使わないためだけにパッケージのインストールを無理に行い、その結果としてサポート対象外の大規模なビルドプロセスを作ってしまうのは避けるべきです。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

依存関係の分離は、Dockerが単一サービスにもたらす最大の強みです

ネイティブLXCでは複数のパッケージを実行できますが、それらはシステムライブラリ、言語ランタイム、リポジトリの方針を共有します。あるサービスが、別のサービスより新しいPython、Node.js、Java、データベース、またはマルチメディアライブラリを必要とする場合があります。依存関係を固定したり置き換えたりすると、将来のディストリビューションアップグレードが難しくなる可能性があります。

Dockerイメージは、LXCファイルシステムの大部分から独立したアプリケーションのユーザー空間をパッケージ化します。サービスごとに異なるランタイムバージョンを使用でき、LXCのパッケージセットを変更する必要がありません。Docker Engineと外側のカーネルは共有されますが、アプリケーションの依存関係はより明確に分離されます。

この利点には限界があります。コンテナイメージには古いライブラリや脆弱なライブラリが含まれる可能性があり、バージョンやダイジェストを管理しない限り、イメージタグは変更される可能性があります。依存関係の分離によって競合は簡素化されますが、イメージのメンテナンス、脆弱性の確認、更新テストが不要になるわけではありません。

Dockerは再作成を容易にするが、データ復旧がデフォルトで簡単になるわけではない

Dockerでは、マウントされたボリュームを保持したまま、イメージ変更後にコンテナを再作成できます。公式のComposeの動作仕様では、変更されたサービスを停止して再作成しても、マウントされたボリュームのデータは引き続き利用できるとされています。これにより、データスキーマに互換性がある場合は、アプリケーション層のロールバックが容易になります。

永続状態については、明示的なマップが依然として必要です。Dockerボリューム、バインドマウント、データベース、シークレット、アップロードファイル、生成された証明書は、異なる場所に存在する可能性があります。コンテナを削除して再作成しても、これらのパスは保護されません。また、Proxmox LXCのバックアップでは、外部のバインドマウントやネットワークストレージが除外される場合があります。

ネイティブパッケージにも、別の形で同じ復旧上の問題があります。パッケージは再インストールできますが、設定、データベースファイル、キー、アプリケーションデータは復元する必要があります。Dockerが運用面で価値を発揮するのは、デプロイファイルとデータパスを、ネイティブサービスの状態よりも簡単に棚卸しできる場合に限られます。

ネストされたネットワークは、Dockerが生み出したメリットを損なうことがある

ネイティブサービスはLXCのインターフェースに直接バインドし、ゲストのファイアウォールとルーティングを使用します。Dockerでは通常、別のブリッジ、ポート公開、内部DNS、NATルールが追加されます。この抽象化はマルチサービススタックには便利ですが、Proxmoxのファイアウォール動作、macvlan、IPv6、トラブルシューティングを複雑にする可能性があります。

Dockerのネットワークドキュメントでは、Dockerが管理するネットワークを通じて、コンテナに独自のインターフェース、ゲートウェイ、ルーティング、DNSビューが提供されると説明されています。LXC内では、このモデルは外側のProxmoxコンテナネットワークの下位で動作し、それを置き換えるものではありません。

1つのサービスが1つのアドレスと少数のポートだけを必要とするなら、ネイティブネットワークのほうが簡単かもしれません。複数のコンポーネントがプライベートなサービスディスカバリーを必要とし、公開するポートを限定したい場合は、Dockerネットワークによって手動のプロキシ設定やループバック設定を減らせます。

デバイスアクセスでは通常、ネイティブインストールが有利

USBアダプター、シリアルコーディネーター、GPUレンダリングデバイス、チューナー、Coralアクセラレーターは、まずProxmoxからLXCに公開する必要があります。その後、Dockerでは同じデバイスを適切な所有権と権限で内部のアプリケーションコンテナにマッピングする必要があります。

ネイティブインストールでは、その2段階目のマッピングが不要になります。サービスはLXCのデバイスノードを直接使用できるため、UID、GID、cgroup、パスに関するトラブルシューティングが容易になります。この利点は、上流パッケージがディストリビューションを適切にサポートしている、ハードウェア依存のサービスで重要です。

ベンダーイメージに、扱いの難しいユーザー空間ライブラリがすでに含まれている場合、Dockerは引き続き有用です。ただし、外側のホストドライバーとLXCのマッピングは依然として機能する必要があります。イメージによって、Proxmoxのデバイスアクセス不足や互換性のないカーネルドライバーが解決されるとは考えないでください。

Dockerの更新はより置き換えやすく、ネイティブ更新はより統合されている

Dockerアプリケーションは通常、新しいイメージを取得してサービスを再作成することで更新します。古いイメージをロールバック用に残しておくことはできますが、データベースのマイグレーションや永続データとの互換性については、なおテストが必要です。互換性のないスキーマ変更を、イメージのロールバックだけで自動的に元に戻すことはできません。

ネイティブパッケージはディストリビューションを通じてインプレースで更新されます。セキュリティ修正、サービスユニット、ライブラリの移行、設定プロンプトはOSのパッケージモデルに従います。プロセスはなじみやすく統合されていますが、パッケージのバージョンが利用可能な状態で残っているか、事前にLXCのスナップショットを作成していない限り、以前のバージョンに戻すのは難しい場合があります。

DockerのDebian向けインストールガイドからも、Docker自体がEngine、containerd、runc、Buildx、Composeコンポーネントなど、独立したパッケージと依存関係のライフサイクルを追加することが分かります。各アプリケーションをコンテナ化していても、内側のプラットフォームは保守する必要があります。

入れ子のコンテナ化は、実際の保守上の境界を生み出す

LXC内のDockerは、外側のコンテナを通じて公開される、入れ子の名前空間、cgroup、ストレージドライバー、ケイパビリティ、カーネルの動作に依存します。Proxmoxは、プラットフォームのロードマップで入れ子のコンテナ化に関する既知の問題を文書化しています。つまり、正常に動作することを前提とせず、ホストのカーネルやProxmoxをアップグレードした後もテストすべきです。

ネイティブパッケージはDockerデーモンと、入れ子になったストレージ／ネットワーク層を必要としません。Dockerは、アプリケーションごとの依存関係でLXCのユーザー空間が汚染されるのを防ぎます。どちらの方式も、複雑さをなくすのではなく移動させるだけです。

ここが中止の境界線です。Dockerの実行に特権LXC、広範なケイパビリティ、特殊なストレージドライバーの回避策、ホスト更新後の繰り返しの修復が必要になるなら、運用上の価値はマイナスになっています。ネイティブパッケージを使うか、独自のカーネルを備えたVM内にDockerを配置してください。

運用再構築テストを実施する

1つのテスト用LXCにはアプリケーションをネイティブにインストールし、別のLXCではDocker経由でインストールする。
すべてのパッケージ、リポジトリ、Composeファイル、シークレット、ボリューム、バインドマウント、デバイスマッピングを記録する。
アプリケーションを更新し、両方の方式でロールバック手順を測定する。
各LXCバックアップを復元し、外部マウントされたデータを個別に検証する。
古いコンテナのファイルシステムをコピーせず、ファイルからDockerスタックを再作成する。
パッケージからネイティブサービスを再インストールし、設定とデータのみを復元してください。
Proxmoxホストのカーネルをアップグレードし、両方のアプリケーションが引き続き起動することを確認してください。

コマンドの数だけでなく、文書化されていない判断も数えてください。イメージとCompose定義によってアプリケーション固有の再構築が不要になる場合、Dockerには付加価値があります。標準的なディストリビューションの状態によってサービスの調査と復旧が容易になる場合は、ネイティブインストールに付加価値があります。

LXCにはどのインストールモデルが適していますか？

LXC内でDockerを使用する場合

アップストリームがコンテナを第一にサポートしている場合、アプリケーションに複数のコンポーネントがある場合、バージョンを分離する必要がある場合、Composeファイルとデータマウントでサービスを再現できる場合は、Dockerを選択してください。可能な限りLXCは非特権に保ち、ネストされたストレージとネットワークの動作を文書化してください。

ネイティブパッケージのインストールを選ぶ場合

安定した単一のサービスがsystemd、デバイス、ユーザー、またはLXCネットワークと統合され、ディストリビューションがサポート対象のバージョンを提供している場合は、ネイティブパッケージを選択してください。インストールを再現可能に保つため、記憶に頼ったシェル履歴ではなく、構成管理を使用してください。

代わりにDocker VMを使用すべき場合

複数のコンテナスタックが1台のホストを共有する場合、より強固なカーネル分離が必要な場合、またはネストされたLXCの要件が不安定になった場合は、DockerをVMへ移行してください。VMにはリソースのオーバーヘッドがありますが、Dockerに一般的なLinuxカーネルの境界と、より移植性の高いホスト環境を提供できます。

よくある質問

ProxmoxのLXC内でDockerを使用することはサポートされていますか？

正常に動作することはありますが、コンテナのネスト化により、カーネル、cgroup、ストレージ、ケイパビリティに関する依存関係が増えます。保守負担の少ない標準構成として扱う前に、使用するProxmoxのバージョン、LXCの特権モデル、ストレージドライバー、バックアップ経路、アップグレード手順を実際の構成でテストしてください。

アプリごとにLXCを1つ用意すれば、Dockerは不要ですか？

場合によります。LXCはすでにOS環境を分離しています。それでも、アップストリームのイメージ、Compose定義、バージョン分離、または複数サービスのアプリケーションパッケージ化が、純粋なネイティブLinuxインストールより有用な場合、Dockerには価値があります。

LXCのバックアップにはDockerボリュームが含まれますか？

バックアップ対象のストレージ内にデータが保存されている場合にのみ、バックアップに含まれます。外部バインドマウント、NAS共有、除外されたマウントポイントには、サービスがネイティブかコンテナ化されているかにかかわらず、別途保護とリストアテストが必要です。

最終結論

Dockerは、アプリケーションを依存関係が分離された再現可能なバージョン管理済みスタックに変え、データマウントを明示できる場合に、ネイティブLXCパッケージを上回る運用上の価値をもたらします。LXCがすでに必要な分離境界を提供し、サービスがシステム、デバイス、ネットワークとの直接統合の恩恵を受ける場合は、ネイティブインストールの方が適しています。ネストされたランタイムによる保守負担よりも、アプリケーション固有の保守作業を減らせる場合にのみDockerを使用してください。