ContainerとVMの違い

このページで学ぶこと

• Containerの役割
• Container Engine
• Container Image
• Running Container
• Host Kernel共有
• アプリケーション分離
• VMとContainerの構成差
• VM上のContainer

1. コンテナはアプリケーション実行環境を分離する

コンテナは、アプリケーションとその実行に必要な依存関係をまとめ、他のアプリケーションから分離された実行環境として動かすための仕組みです。

基本的な考え方は、

アプリケーション
    ↓
コンテナ
    ↓
コンテナエンジン
    ↓
ホストOS / カーネル
    ↓
ハードウェア

です。

コンテナの中心は、物理コンピューターそのものをもう1台作ることではありません。

アプリケーションを実行する環境を分離する

ことが中心です。

2. コンテナは「小さいVM」ではない

コンテナとVMは、どちらも1台の基盤上で複数のワークロードを分離して動かすために利用できます。

しかし、構造は同じではありません。

VMの基本モデルは、

アプリケーション
    ↓
ゲストOS / カーネル
    ↓
仮想マシン
    ↓
ハイパーバイザー
    ↓
ハードウェア

です。

コンテナの基本モデルは、

アプリケーション
    ↓
コンテナ
    ↓
コンテナエンジン
    ↓
ホストOS / カーネル
    ↓
ハードウェア

です。

したがって、

コンテナ
=
小さくした仮想マシン

と考えるのは不正確です。

3. コンテナエンジン

コンテナエンジンは、コンテナイメージを利用してコンテナを実行・管理する役割を持つソフトウェアレイヤーです。

概念的には、

コンテナイメージ
      ↓
コンテナエンジン
      ↓
実行中コンテナ

という関係です。

ここでハイパーバイザーとコンテナエンジンを混同しないようにします。

実装によってはコンテナエンジンの内部で別のコンテナランタイムを利用する構成がありますが、その詳細な内部階層はCCNAでこの項目を学ぶ際の主眼ではありません。

4. コンテナイメージ

コンテナイメージは、コンテナを起動する元になるパッケージです。

イメージには、たとえば、

• アプリケーション
• ライブラリ
• 依存関係
• ユーティリティ
• ルートファイルシステムを構成するファイル

などを含めることができます。

つまりコンテナでは、アプリケーションだけを単独で置くのではなく、

アプリケーションが実行に必要とするユーザー空間側のファイルや依存関係をまとめて扱える

ことが重要です。

5. 「コンテナにはOSがない」だけでは不正確

コンテナを説明するとき、

VMにはOSがある
コンテナにはOSがない

とだけ覚えると誤解しやすくなります。

コンテナイメージにはルートファイルシステム、ライブラリ、ユーティリティなど、OSのユーザー空間に相当するファイルを含めることがあります。

重要なのは、

一般的なアプリケーションコンテナでは、VMのようにコンテナごとに独立したゲストOSカーネルを持つ基本構造ではない

という点です。

比較すると、

VM
→ ゲストOS / ゲストカーネルをVMごとに持つ基本モデル

コンテナ
→ ホスト側のカーネルを利用する基本モデル

となります。

6. コンテナイメージと実行中コンテナは別

イメージとコンテナも同じ意味ではありません。

考え方としては、

イメージ
  ↓ 起動
実行中コンテナ

です。

同じイメージを元に、複数のコンテナインスタンスを実行することもできます。

コンテナイメージ
   ├─ 実行中コンテナ A
   ├─ 実行中コンテナ B
   └─ 実行中コンテナ C

CCNAでは、少なくともイメージは実行元、コンテナは実行されたインスタンスという違いを説明できるようにします。

7. アプリケーションと依存関係をまとめる

コンテナイメージを使う理由を理解するには、アプリケーションだけでなく依存関係を見ることが重要です。

アプリケーションは実行時に、

• 特定のライブラリ
• ランタイム
• 設定ファイル
• ユーティリティ
• その他の依存関係

を必要とする場合があります。

コンテナでは、これらをイメージとしてまとめることで、

アプリケーション
+
依存関係
+
必要なユーザー空間ファイル
      ↓
コンテナイメージ

という形で扱えます。

これにより、アプリケーションの実行環境を再現しやすくなります。

8. ホストカーネル共有

VMとコンテナを分ける最重要ポイントの1つが、カーネルの扱いです。

一般的なアプリケーションコンテナでは、複数のコンテナがホスト側のカーネルを利用します。

コンテナ A ─┐
コンテナ B ─┼→ ホストカーネル
コンテナ C ─┘

つまり、

コンテナ A → カーネル A
コンテナ B → カーネル B
コンテナ C → カーネル C

というVMのゲストカーネルのような構造が基本ではありません。

このホストカーネル共有が、VMとの構造差を理解する中心です。

9. ホストカーネルを共有してもコンテナは分離される

カーネルを共有するからといって、

コンテナ同士は何も分離されていない

という意味ではありません。

コンテナは、OSが提供する分離機能を利用して、プロセスやファイルシステムビューなどの実行環境を分けます。

概念的には、

同じホストカーネル
      ↓
+-----------------------+
| コンテナ A : アプリA   |
+-----------------------+
| コンテナ B : アプリB   |
+-----------------------+
| コンテナ C : アプリC   |
+-----------------------+

のように、カーネルを共有しながらアプリケーション環境を分離します。

名前空間（Namespace）の種類やcgroupsの内部実装を詳細に覚えることは、このPageの主目的ではありません。

10. 分離単位の違い

VMとコンテナでは、主にどの単位を分離しているかが異なります。

この違いから、同じ「仮想化」「分離」という言葉が使われても、VMとコンテナでは構造が異なることが分かります。

11. VM側の構造を最小限だけ確認する

Page008で扱ったVMを、コンテナとの比較に必要な範囲だけ確認します。

物理ハードウェア
       ↓
ハイパーバイザー
       ↓
仮想マシン
       ↓
ゲストOS / カーネル
       ↓
アプリケーション

VMでは、ゲストOSが仮想ハードウェアをコンピューターとして利用します。

Page009で重要なのは、vNICや仮想スイッチを再講義することではなく、

VMにはゲストOS / カーネルという層があり、コンテナは一般にホストカーネルを共有する

という比較です。

12. VMとコンテナを層で並べる

2つの実行モデルを横に並べると違いが見えやすくなります。

したがって、

VM
→ ハードウェアを抽象化した仮想コンピューター上でゲストOSを動かす

コンテナ
→ ホストOS / カーネルの上でアプリケーション環境を分離して動かす

という違いで整理できます。

13. リソース使用量の違い

VMでは各VMがゲストOSを持つ基本モデルです。

コンテナでは各コンテナが独立したゲストカーネルを持たず、ホストカーネルを共有する基本モデルです。

そのため一般には、

VM
→ ゲストOSを含む分、リソースオーバーヘッドが大きくなりやすい

コンテナ
→ ゲストカーネルを個別に持たないため、オーバーヘッドを小さくしやすい

と説明できます。

ただし、

コンテナなら常に軽い
VMなら必ず遅い

という絶対的な性能比較ではありません。

ここでは基本構造から見た一般的なリソース使用量の傾向として理解します。

14. 起動単位も異なる

VMを起動するときは、通常ゲストOSの起動を含むコンピューター環境を立ち上げます。

コンテナでは、すでに動作しているホストOS / カーネルを利用しながらアプリケーション環境を起動します。

そのため構造上、コンテナは一般に小さい実行単位として扱いやすくなります。

VM
ハイパーバイザー
   ↓
ゲストOS起動
   ↓
アプリケーション

コンテナ
ホストカーネル
   ↓
コンテナ起動
   ↓
アプリケーション

ここでも「必ず何秒で起動する」といった製品依存の数値は覚える必要はありません。

15. VMとコンテナは排他的ではない

VMとコンテナは、必ずどちらか一方だけを利用する技術ではありません。

仮想マシンをコンテナホストとして利用する構成も成立します。

物理ハードウェア
      ↓
ハイパーバイザー
      ↓
仮想マシン
      ↓
ゲストOS / カーネル
      ↓
コンテナエンジン
      ↓
コンテナ

この構成では、ハイパーバイザーがVMを実行し、そのVM内部のゲストOS上でコンテナエンジンがコンテナを実行します。

16. VM上のコンテナが共有するカーネル

前の構成で、コンテナが利用するカーネルを正しく追います。

物理ホストのカーネルを直接共有する

とは限りません。

VM上にコンテナエンジンがあるなら、コンテナから見たホストはそのVMです。

したがって、

物理ハードウェア
      ↓
ハイパーバイザー
      ↓
VM
      ↓
ゲストOS / カーネル  ← コンテナが利用するカーネル
      ↓
コンテナエンジン
      ↓
コンテナ

となります。

つまり、

コンテナが共有するのは、そのコンテナエンジンが動作しているホスト環境側のカーネル

です。

17. ハイパーバイザーとコンテナエンジンは競合する役割ではない

ハイパーバイザーとコンテナエンジンを、どちらか片方だけを選ぶ同じレイヤーの製品と考えないようにします。

役割は異なります。

ハイパーバイザー
→ 仮想マシンを実行する

コンテナエンジン
→ コンテナを実行する

そのため、

ハイパーバイザー
   ↓
VM
   ↓
コンテナエンジン
   ↓
コンテナ

というように、異なるレイヤーとして同じ構成の中に存在できます。

18. イメージ化してもプラットフォーム依存が完全になくなるわけではない

コンテナイメージはアプリケーションと依存関係をまとめられるため、同じ環境を再現しやすくします。

ただし、

コンテナイメージにした
      ↓
CPU Architectureもカーネルもプラットフォームも完全に無関係

という意味ではありません。

コンテナはホスト側のカーネルを利用するため、イメージと実行プラットフォームの互換性が必要です。

CCNAでは詳細な互換性一覧を覚える必要はありませんが、

イメージ化 = あらゆるプラットフォームから完全独立

ではないことを押さえます。

19. よくある誤解を切り分ける

20. CCNAで問われる比較軸

この範囲では、ハイパーバイザー、VM、コンテナの役割（role）と機能（function）を説明（describe）できることが求められます。

したがってPage009では、製品固有のコンテナ操作ではなく、構成から役割を説明できることを重視します。

Dockerfile作成、レジストリ操作、Kubernetes、コンテナオーケストレーション、cgroupsや名前空間（Namespace）の詳細実装は、このPageの到達点ではありません。

21. 構成図を見たらレイヤーを上から追う

試験で構成図や説明文が出たときは、名称だけでなくレイヤーを追います。

コンテナホストが物理マシンの場合は、

アプリケーション
    ↓
コンテナ
    ↓
コンテナエンジン
    ↓
ホストOS / カーネル
    ↓
ハードウェア

です。

コンテナホストがVMの場合は、

アプリケーション
    ↓
コンテナ
    ↓
コンテナエンジン
    ↓
ゲストOS / カーネル
    ↓
仮想マシン
    ↓
ハイパーバイザー
    ↓
物理ハードウェア

です。

このレイヤー関係を追えれば、ハイパーバイザー、VM、コンテナエンジン、コンテナの役割を混同しにくくなります。

まとめ

Page009の中心は、コンテナをVMの小型版として覚えるのではなく、カーネルと実行レイヤーの違いから構造を説明することです。

重要な関係をまとめます。

仮想マシン
アプリケーション
    ↓
ゲストOS / カーネル
    ↓
VM
    ↓
ハイパーバイザー
    ↓
ハードウェア

コンテナ
アプリケーション
    ↓
コンテナ
    ↓
コンテナエンジン
    ↓
ホストOS / カーネル
    ↓
ハードウェア

覚える中心は、

• コンテナイメージは実行元のパッケージ
• 実行中コンテナは実行されたインスタンス
• コンテナエンジンがコンテナを実行・管理する
• 一般的なコンテナはホストカーネルを共有する
• VMはゲストOS / ゲストカーネルを持つ基本モデル
• コンテナはアプリケーション / プロセス環境を分離する
• コンテナはVMより一般にリソースオーバーヘッドを小さくしやすいが、絶対的な性能差ではない
• VM上でコンテナを動かす構成も成立する
• イメージ化してもCPU / カーネル / プラットフォームから完全独立するわけではない

ここまで説明できれば、CCNAで求められるハイパーバイザー / 仮想マシン / コンテナの役割と機能を、構造の違いから整理できます。