VM vs LXC vs Docker：信頼済み・特権・インターネット公開サービスに適した境界はどれか？

エヴァ・ウォン

IceWhale author

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

VM vs LXC vs Docker: Which Boundary Fits Trusted, Privileged, and Internet-Facing Services? - Zima Store Online

信頼でき、適切にパッケージ化されたアプリケーションにはDockerを使用し、軽量なLinuxシステム環境にはLXCを使用し、サービスに独立したカーネルまたはより強固な信頼境界が必要な場合はVMを使用します。

これらは互換性のある3種類のラッパーではありません。Dockerはアプリケーションをパッケージ化し、LXCは小型のLinuxシステムに近い動作をし、VMはハードウェアを仮想化して独立したゲストカーネルを実行します。サービスがインターネットに公開されているか、広範な権限を必要とするか、GPUやUSBデバイスにアクセスするか、またはホストの状態を信頼せずに復元する必要があるかによって、適切な選択は変わります。

信頼性を分類し、カーネル境界を設定する

まず各サービスを、信頼できる内部サービス、特権インフラ、またはインターネットに公開された潜在的に悪意のあるサービスのいずれかに分類します。次に、イメージやパッケージの提供元、読み取り可能なデータ、侵害された場合に管理ネットワーク、バックアップネットワーク、家族用ファイルネットワークへ到達する可能性があるかを記録します。

サービスは小規模だからといって低リスクとは限りません。ホストのマウントを持たない公開ダッシュボードのほうが、ネットワーク認証情報やDockerソケットを保持し、すべての共有領域への書き込みアクセスを持つ内部自動化ツールより安全な場合があります。

この最初の判定だけで比較が終わることもあります。ワークロードがホストカーネルを共有してはいけない場合、メモリ使用量が少なくてもDockerとLXCは候補から外れます。一方、狭い範囲のマウントだけを持つ信頼できる単目的アプリであれば、VMを使っても実際のリスクは十分に変わらず、管理の手間だけが増える可能性があります。

DockerとLXCはホストカーネルを使用しながらプロセスを分離します。VMはハイパーバイザー境界の背後でゲストカーネルを実行します。カーネル共有とVM分離の比較では、すべてのコンテナが安全でないという主張ではなく、セキュリティ上の違いがアーキテクチャに由来する理由を説明しています。

Dockerは通常、アプリケーションとその依存関係に単位を絞ります。LXCは、init、パッケージ、アカウント、システムサービスを含む、より完全なユーザー空間を提供します。そのためLXCは小規模なLinux環境に便利ですが、VMになるわけではありません。

カーネルの多様性、信頼できないコード、またはゲストレベルで明確なファイアウォールとパッチ適用の境界が重要な場合はVMを選びます。ホストカーネルを共有することが許容でき、独立したゲストOSより運用の簡便さに価値がある場合は、DockerまたはLXCを候補に残します。

権限とハードウェアアクセスで既定の選択を変える

信頼できるDockerサービスも、ホストネットワーク、広範なケイパビリティ、書き込み可能なシステムマウント、またはコンテナ管理ソケットを必要とすると効率性が低下します。例外が増えるほど、狭いアプリケーション境界は弱まり、サービスを専用VMへ移すか、アクセス経路を再設計する価値が高まります。

LXCは、通常のパッケージマネージャー、安定したホスト名、選択したデバイスへのアクセスを必要とするLinuxサービスにとって、実用的な中間案になります。ただし、特権LXC、広範なバインドマウント、Dockerの入れ子構成を使うと結合が増えるため、リソースの節約と、アップグレードや復旧の難しさを比較する必要があります。

GPU、HBA、USBコーディネーター、特殊なNICを使用する場合は、リセット動作、権限、再起動後の永続性をテストします。デバイスへの直接アクセスはホスト上で最も簡単な場合がありますが、ハードウェアとIOMMUの構成が対応していれば、パススルーを使用するVMによって所有権の境界をより明確にできます。

インターネットへの公開をネットワークとIDの判断として扱う

公開サービスは、管理された1つのリバースプロキシまたはVPN経路の背後に配置し、管理インターフェースは非公開にして、サービス認証情報のアクセス範囲を最小限のデータセットに限定します。公開された管理パネル、再利用された秘密情報、ストレージやバックアップへの無制限のアクセスがある場合、実行時の分離だけでは補えません。

運用担当者がDocker、LXC、VMにワークロードを割り当てる方法についてのコミュニティでの議論からは、実際の環境ではハイブリッド構成がよく使われることが分かります。VMで信頼境界を確立し、その中でDockerを使ってアプリケーションをパッケージ化する構成です。これは3つ目のアーキテクチャであり、どれか1つの選択肢が失敗したという意味ではありません。

影響の大きい公開サービスでは、Dockerのほうが安価に実行できる場合でも、専用VMまたは専用ホストを優先します。影響の小さいアプリで、イミュータブルなデプロイ、限定されたマウント、強力なネットワーク制御がある場合は、Dockerがより簡単な答えになり得ます。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

パッチ、バックアップ、復元の単位を比較する

Composeファイル、秘密情報、バージョン、永続ボリュームを明確に分離すれば、Dockerは最も簡単に再構築できます。LXCはシステム単位で復元できますが、内部で手動変更されたパッケージは、文書化または自動化されていない限り構成のドリフトを生みます。

VMは通常、より多くのメモリとストレージを消費しますが、ゲストを独立したバックアップおよびロールバック単位にできます。ただし、その利点が実際にあるのは復元テストを行った後です。同じホスト上のスナップショットは、独立した復旧用コピーではありません。

判断軸	Docker	LXC	VM
主な単位	アプリケーションとボリューム	Linuxユーザー空間とファイル	ゲストOSと仮想ディスク
カーネル	ホストと共有	ホストと共有	独立したゲストカーネル
適した用途	パッケージ化された信頼できるアプリ	軽量なLinuxシステムサービス	より強固な信頼境界またはOS境界
権限に関する警告	ソケット、ケイパビリティ、広範なマウント	特権モード、入れ子構成、バインドマウント	パススルーとゲストの肥大化
復旧の検証	再作成とボリュームの復元	コンテナ状態の再作成または復元	ゲストを復元し、デバイスを検証

サーバー単位ではなくサービスごとに境界を選ぶ

狭い範囲のマウントと再現可能な定義を持つ、信頼できるアプリケーションスタックにはDockerを選びます。より完全なユーザー空間の恩恵を受け、独立したカーネルを必要としない効率的なLinuxシステムサービスにはLXCを選びます。信頼できない、またはインターネットに公開された、影響の大きいワークロード、別のオペレーティングシステム、またはゲスト分離によって所有権を明確にできるハードウェアにはVMを選びます。

ホームサーバーのオペレーティングシステムの選択は次の層にあたります。ホストの選択によって、利用できるバックアップ、ネットワーク、コンテナ、VMの制御が決まるためです。混在型サーバーでは、1つを普遍的な既定値とみなさず、3つすべての境界を使用できます。

サービスに特権的なホストアクセスが必要な場合、機密性の高い管理機能を公開する場合、または独立して復元できない場合は、密度の最適化をやめます。適切な境界とは、実際に懸念している障害を封じ込められる、最も複雑でない選択肢です。