コンテナと仮想マシンの違い

なぜ「分けたい」のか

1台のサーバーに複数のアプリをそのまま同居させると、ライブラリのバージョンが衝突したり、片方の暴走が全体を巻き込んだりします。そこで「独立した箱」に分けて、依存関係・設定・障害を箱の中に閉じ込めたい——これが仮想化やコンテナ化の出発点です。

分け方には大きく2系統あります。OS の下（ハードウェア層）で分けるのが VM、OS の上（プロセス層）で分けるのがコンテナです。

仮想マシン：OSごと仮想化する

VM は ハイパーバイザ（仮想化ソフト）が物理マシンを分割し、それぞれの上に ゲストOS を丸ごと 動かします。各VMは独自のカーネル・独自のメモリ空間を持つ、いわば「箱の中の1台のPC」です。

• ハイパーバイザが CPU・メモリ・ディスクを仮想的に切り出す
• 各VMに 独立したゲストOS（カーネル込み） が載る
• ホストとは別の OS を動かせる（Linux ホスト上で Windows VM など）
• 隔離が強い：カーネルごと分かれているので、相互干渉が起きにくい

→ 代わりに、OS を何個も起動するぶん メモリ・ディスクを多く消費し、起動も分単位になりがちです。

コンテナ：カーネルを共有する

コンテナは ホストOSのカーネルをそのまま借りて、アプリとその依存物だけを隔離された空間で動かします。新しい OS を起動するのではなく、1つのプロセス群を「壁で囲う」 イメージです。

その壁を作っているのは、主に Linux カーネルの2つの機能です。

• namespace：プロセスID・ネットワーク・ファイルシステムなどの 見え方を分離（コンテナからは自分専用の世界に見える）
• cgroups：CPU・メモリなどの 使用量を制限（1つのコンテナが資源を食い尽くさないように）

ゲストOSを持たないぶん 数十MB〜と軽く、起動は秒〜ミリ秒。同じホストに何十個も詰め込めます。仕組みやコマンドは /devops/tools/docker/ が代表例です。

イメージ：箱の“設計図”

コンテナの実体は実行中のプロセスですが、その元になる イメージ が再現性のカギです。イメージは「アプリ＋依存ライブラリ＋最小限のファイル群」を固めた 読み取り専用のテンプレートで、これを起動するとコンテナになります。

• Dockerfile（設計図）→ ビルド → イメージ（テンプレート）→ 実行 → コンテナ（実体）
• イメージは レイヤ構造：差分だけを重ねるのでキャッシュが効き、配布も差分転送で速い
• 同じイメージなら どこでも同じように動く（「自分の環境では動く」問題を減らす）

# イメージをビルドして実行するだけ
docker build -t myapp:1.0 .
docker run -p 8080:80 myapp:1.0

VMにもイメージ（VMテンプレート/AMI 等）はありますが、OS丸ごとなのでサイズはGB級。コンテナイメージのアプリ単位の小ささ・差分の速さが、CI/CD や大量デプロイと相性が良い理由です。

比較表

つまずきポイント

つまずきやすい点を整理します。

• 隔離の過信：コンテナはカーネルを共有するため、カーネルの脆弱性を突かれるとホストや他コンテナに波及し得ます。マルチテナントで強い隔離が要るなら、VMや軽量VM技術（Firecracker, Kata Containers 等）を検討します。
• 「コンテナ＝Linux」ではない：Windows コンテナも存在しますが、Linux コンテナは Linux カーネル上、Windows コンテナは Windows カーネル上 が原則。Windows/Mac の Docker は内部で Linux VM を動かして橋渡ししています（だから手元では“VMの上のコンテナ”になっている）。
• 状態の持ち方：コンテナは使い捨て（イミュータブル）前提が基本。データはコンテナ内に貯めず、ボリュームや外部DBへ。この考え方は /devops/immutable-infra/ と地続きです。

どっちを選ぶ？

• アプリを素早く・大量に・同じ環境で動かしたい（マイクロサービス、CI/CD、スケール）→ コンテナ
• 強い隔離・別OS・カーネル依存が必要（マルチテナント基盤、レガシー、規制対応）→ VM
• 両方の良いとこ取り（堅いインフラ境界の上に軽い箱）→ VMの上でコンテナ（実務の主流）