6.1コンテナの仕組み

2.05 で仮想マシンを学びました。コンテナはさらに軽量な仮想化の形態で、1台のホストカーネルを複数のアプリケーションで共有しながら、それぞれを独立したプロセス群のように見せます。仕組みを支えるのは特別なハードウェアではなく、Linux カーネルが持つ隔離・制限機能です。

6.1.1物理マシン・仮想マシン・コンテナの比較

• 物理マシン＝1台のハードウェアに1つの OS。リソースは占有できるが台数分の物理コストがかかる。
• 仮想マシン＝ハイパーバイザーがハードウェアを仮想化し、ゲストごとに独立したカーネルを持つ。隔離は強いが、ゲスト OS 分のオーバーヘッド（起動時間・メモリ・ディスク）が乗る。
• コンテナ＝ホストのカーネルを共有し、プロセス単位で隔離する。ゲスト OS が無いため起動が数秒未満・メモリ消費も小さく、同一ホスト上で多数を動かせる。ただし異なるカーネルを持つゲスト（例：別 OS 種別）は動かせない。

6.1.2隔離を支えるカーネル機能

• 名前空間（namespaces）＝プロセスから見える世界を分割するカーネル機能。PID（プロセスID空間）・net（ネットワーク）・mnt（マウントポイント）・UTS（ホスト名）などの種類があり、コンテナ内のプロセスは自分専用の世界しか見えない。
• cgroups（control groups）＝プロセスグループに対してCPU・メモリなどのリソース使用量を制限・計測するカーネル機能。あるコンテナが他のコンテナのリソースを食い尽くすのを防ぐ。
• 両者は役割が異なる＝名前空間は「何が見えるか」を分離し、cgroups は「どれだけ使えるか」を制限する。コンテナはこの2つの組み合わせで実現される軽量な隔離環境である。

コンテナファイルシステムとイメージの関係も試験の急所です。イメージは読み取り専用の複数レイヤー（後述の Dockerfile の各命令が1レイヤーに対応）を積み重ねたもので、union filesystem（統合ファイルシステム）の仕組みにより、あたかも1つのファイルシステムであるかのように見せます。コンテナを起動すると、その読み取り専用レイヤー群の上に薄い書き込み可能レイヤー（コンテナレイヤー）が1枚重なります。コンテナ内でファイルを変更・追加すると、その差分だけがこの書き込み可能レイヤーに記録され、元のイメージレイヤーは変更されません。この設計により、同じイメージから何個でもコンテナを起動でき、それぞれが独立した差分だけを持つため、ディスクも起動も軽量です。コンテナを削除すると、通常はこの書き込み可能レイヤー（＝コンテナ固有の変更分）が失われる点も押さえておきましょう。名前空間の観点では、コンテナ内で ps を実行すると自分のコンテナ内のプロセスしか見えず、PID も 1 番から独立して振られます（ホスト側から見ると別の PID が対応している）。cgroups の観点では、あるコンテナに CPU やメモリの上限を設定しておけば、そのコンテナが暴走してもホスト全体やほかのコンテナへ影響が及びにくくなります。

6.1.3この節のまとめ

• コンテナ＝ホストカーネルを共有（VM は独立カーネル）。隔離は名前空間（可視性）＋cgroups（リソース制限）で実現
• イメージ＝読み取り専用レイヤーの積み重ね、コンテナは書き込み可能レイヤーを1枚追加して差分だけを持つ