1.5 コンテナの正体は「隔離されたプロセス」｜名前空間・cgroups・overlayfsの仕組みを図解

# tini を使ってゾンビプロセスを適切に回収する
docker run --init nginx

# コンテナ内のプロセス一覧（PID 1 が tini になる）
docker exec <container> ps aux
# → PID   COMMAND
# →   1   /sbin/tini -- nginx -g daemon off;
# →   7   nginx: master process
# →  21   nginx: worker process

下のシミュレータで、ホストとコンテナの「見える世界」の違いを体験してみてください。

4. NET・MNT・UTS：ネットワーク・ファイルシステム・ホスト名の分離

NET 名前空間 — 独立したネットワークスタック

NET名前空間により、コンテナは独立したネットワークインターフェース・IPアドレス・ルーティングテーブル・ポート番号空間を持ちます。ホストとコンテナが同じポート番号（例：80番）を同時に使っても衝突しないのはこの仕組みのためです。

docker run -p 8080:80 のポートマッピングは、ホストの8080番ポートへのパケットをコンテナのNET名前空間内の80番ポートへ転送するルールを iptables（または nftables）に追加することで実現しています（第5章で詳しく解説）。

MNT 名前空間 — コンテナ独自のルートファイルシステム

MNT名前空間により、コンテナは独自のマウントポイントのツリーを持ちます。コンテナ内で / を参照すると、イメージで定義されたファイルシステムが見えます。ホストの /etc/passwd などは（バインドマウントで明示しない限り）見えません。

UTS 名前空間 — 独自のホスト名

UTS（Unix Time-sharing System）名前空間はホスト名とNISドメイン名を分離します。コンテナ内で hostname を実行するとコンテナIDの先頭12文字が返り、ホストのホスト名とは独立しています。

# ホストのホスト名
hostname
# → server01

# コンテナ内のホスト名（デフォルトはコンテナIDの先頭12文字）
docker exec demo hostname
# → a3f2b1c4d5e6

# --hostname オプションでカスタムホスト名を設定できる
docker run --hostname myapp nginx

5. cgroups — リソース使用量を制限・計測する

名前空間は「見える世界」を分離しますが、リソース（CPU・メモリ・ディスクI/O）の消費量まで制限するわけではありません。1つのコンテナが暴走してホスト全体のメモリを食い尽くすことを防ぐのが cgroups（Control Groups）です。

cgroups はLinuxカーネルのサブシステムで、プロセスグループに対してリソースの「上限設定」「計測」「優先度制御」を提供します。

cgroups v1 と v2

cgroups には2つのバージョンがあり、現在はv2への移行が進んでいます。

# メモリ256MB・CPU 0.5コアに制限したコンテナを起動
docker run -d --name limited \
  --memory=256m \
  --cpus=0.5 \
  --pids-limit=100 \
  nginx

# コンテナのリソース使用量をリアルタイム確認
docker stats limited

# cgroups v2 環境（Ubuntu 22.04+ など）でのメモリ上限確認
CONTAINER_ID=$(docker inspect --format '{{.Id}}' limited)
cat /sys/fs/cgroup/system.slice/docker-${CONTAINER_ID}.scope/memory.max
# → 268435456  （= 256 × 1024 × 1024 バイト）

次のシミュレータでメモリ制限の動作を体験してみてください。

6. ユニオンファイルシステム — イメージのレイヤー構造

名前空間とcgroupsで「隔離」と「制限」はできました。残る課題は「コンテナ独自のファイルシステムをどう用意するか」です。VMのようにディスクを丸ごとコピーするのでは時間もスペースも無駄です。

Dockerはここで ユニオンファイルシステム（Union File System）を使います。Docker のデフォルト実装は overlay2（OverlayFS）です。

重要なポイントは3つです。

• イメージレイヤーは読み取り専用かつ複数コンテナで共有される（ディスク効率が高い）
• コンテナ内でのファイル変更はすべて書き込み可能レイヤーに記録される（コピーオンライト方式）
• コンテナを削除すると書き込み可能レイヤーも消える（永続化にはVolumeを使う — 第4章）

7. 3つの仕組みが合わさってコンテナになる

docker run nginx を実行したとき、内部では次のような処理が順番に行われています。

VMとの決定的な違いは、BIOSもブートローダーもカーネル起動も存在しない点です。カーネルはホストのものをそのまま使い、ステップ①〜③はミリ秒〜数百ミリ秒で完了します。これがコンテナの起動が速い理由です。

8. コマンドで確認する（Linux環境）

ここで説明した内容は実際のコマンドで確認できます。Docker が動いているLinux環境（WSL2含む）で試してみてください。

① コンテナのPIDとnamespaceファイルを確認する

# テスト用コンテナを起動
docker run -d --name demo nginx

# ホスト上でのコンテナの実際のPIDを取得
HOST_PID=$(docker inspect --format '{{.State.Pid}}' demo)
echo "Host PID: $HOST_PID"

# そのPIDの名前空間ファイル一覧（各名前空間へのシンボリックリンク）
ls -la /proc/$HOST_PID/ns/
# → cgroup → cgroup:[4026532456]
# → ipc    → ipc:[4026532458]
# → mnt    → mnt:[4026532459]
# → net    → net:[4026532461]
# → pid    → pid:[4026532460]
# → uts    → uts:[4026532457]
# → user   → user:[4026531837]  ← デフォルトはホストと共有（同じinode）

# ホストのPID 1と比較すると pid/mnt/net/uts/ipc が異なるinode番号になっている
ls -la /proc/1/ns/

② コンテナ内からPIDの見え方を確認する

# コンテナ内のプロセス一覧（PID 1から始まる）
docker exec demo ps aux
# → PID   USER   COMMAND
# →   1   root   nginx: master process nginx -g daemon off;
# →  29   nginx  nginx: worker process

# ホスト上では全プロセスが見える（PIDはHOST_PIDと一致）
ps aux | grep nginx
# → 3842  root   nginx: master process nginx ...
# → 3857  nginx  nginx: worker process

③ cgroupsでリソース制限を確認する

# メモリ256MB制限付きコンテナを起動
docker run -d --name limited --memory=256m nginx

# cgroups v2 環境（Ubuntu 22.04+ など）での確認
CONTAINER_ID=$(docker inspect --format '{{.Id}}' limited)
cat /sys/fs/cgroup/system.slice/docker-${CONTAINER_ID}.scope/memory.max
# → 268435456  （= 256 × 1024 × 1024 バイト = 256 MiB）

# リアルタイムのリソース使用量モニタリング
docker stats limited
# → CONTAINER   CPU %   MEM USAGE / LIMIT   MEM %
# → limited      0.0%   8.5MiB / 256MiB     3.3%

# OOM Killされたか確認する
docker inspect --format '{{.State.OOMKilled}}' limited
# → false（問題なし）/ true（メモリ超過で強制終了）

9. まとめ

コンテナは「軽量VM」ではなく、Linuxカーネルの3つの機能によって隔離・制限されたプロセスです。

参考リンク

• Linux man-pages: namespaces(7) — Linux名前空間の公式リファレンス（種類・フラグの詳細）
• Linux man-pages: cgroups(7) — cgroupsの公式リファレンス（v1/v2の違いも記載）
• Docker セキュリティドキュメント — namespaces・cgroups・capabilitiesのDockerでの使われ方
• opencontainers/runc（GitHub） — clone()・cgroup設定など低レベルコンテナ作成の実装が読めるOSS
• Docker: Runtime options with Memory, CPUs, and GPUs — –memory / –cpus 等のリソース制限オプションの公式ドキュメント

Dockerの基礎を動画で体系的に学びませんか？

実務で使う基礎だけを3時間に凝縮。環境構築から丁寧に解説しています。

クーポン割引で講座を見る →