Docker Visual Learning Simulator | 視覚的に学ぶコンテナとLinuxカーネルの仕組み

仮想マシン(VM) と Dockerコンテナの構造比較

完全に独立したOSを持つ「VM」と、1つのカーネルを極限まで分け合う「コンテナ」のアーキテクチャ。

初心者向け：例え話で納得する違い

🏡 仮想マシンは「一戸建て」

家ごとに、水道、電気の配線、警備会社、全部を個別に用意します。完全に独立していて安全ですが、家を建てるのに時間がかかり（起動が数分）、土地も広く必要です。

🏢 コンテナは「シェアアパート」

1つの頑丈なビルの土台、配管、セキュリティをみんなで直接使いまわします。自分の部屋には鍵がかかっているので干渉しません。家を建てる必要がないため一瞬で部屋を用意でき（起動がミリ秒）、非常に省スペースです。

低レイヤー：カーネルとCPUハードウェアの真実

⚙️ Hypervisor Virtualization

CPUのハードウェア仮想化支援（Intel VT-x / AMD-V）を使い、特権命令をフック・エミュレートします。各VMは独立したメモリ空間（EPT/NPT）を持ち、自身の仮想デバイスドライバ経由で完全に別個のLinux/Windowsカーネルをブートさせます。

⚙️ Kernel Shared Process (NO Hypervisor)

コンテナは「通常プロセス」に過ぎません。仮想化デバイスは介さず、ホストのLinuxカーネルに対して直接 `system call` を送ります。隔離境界はカーネル空間内の内部フラグのみで守られ、オーバーヘッドがほぼ「ゼロ（0）」になります。

仮想マシン (Virtual Machine) STOPPED

アプリ / 依存ライブラリ (App A, B, C)

ゲストOS (完全な独自カーネル) ※ 各VMごとに数GB〜数十GB必要

ハイパーバイザー (Hyper-V / ESXi / VirtualBox)

ホストOS (Windows / macOS / Linux)

物理サーバー (CPU / メモリ / ストレージ)

OSブート時間 (システムロード): --

ホストメモリ消費: 0 MB

Docker コンテナ (Container) STOPPED

App 1 (Node)

App 2 (Go)

App 3 (Py)

Docker Engine (runc, containerd) ※ OSを内包せず、カーネルのプロセス空間を直結

ホストOSカーネルを直接共有 (Linux Kernel) NO OVERHEAD

ホストOS (Linux)

物理サーバー (CPU / メモリ / ストレージ)

コンテナ起動時間 (プロセス起動): --

ホストメモリ消費: 0 MB

リソーススケール・耐久テスト

同じスペックの物理サーバーで何台動かせるかをシミュレートします。

VM増設 (2.0GB空きサーバー) 0 台起動中

コンテナ増設 (2.0GB空きサーバー) 0 台起動中

Build, Ship, Run & OverlayFS の立体レイヤー構造

Dockerfileの構築プロセスと、極めて強力な「レイヤー（積層型）ファイルシステム」の仕組み。

環境選択:

初心者向け：例え話で納得する違い

📝 Dockerfile =「料理のレシピ」

「ベースにはこの材料を使って、この順番で調理してね」と書かれたインフラの自動指示書・台本です。

📦 イメージ =「冷凍食品パック」

レシピを元に調理を済ませ、ガチガチに不変（読込専用）で凍らせて保存したものです。

🚀 コンテナ =「レンジでチンした料理」

冷凍パックを温めて、食べられる状態（プロセス実行）にしたものです。元の冷凍食品は汚しません。

低レイヤー：OverlayFS（Union FS）と Copy-on-Write（CoW）

🧱 lowerdir (Read-Only)

下位レイヤー群。絶対に編集不可能な不変（Immutable）のフォルダ。複数の同一イメージコンテナで完璧に物理メモリ共有されます。

✍️ upperdir (Read-Write)

上位レイヤー。コンテナ起動時に動的に作られる薄い書き込み層。コンテナ内でのファイルの変更・追加はここに書き込まれます。

⚙️ Copy-on-Write (CoW) 動作

不変（ReadOnly）ファイルを編集しようとすると、その瞬間カーネルがファイルを上部の `upperdir` へコピーしてから編集を行います。

1. BUILD Dockerfile

2. LAYERS OverlayFS 3D Stack

app:latest

ビルドを実行すると、ここに読込専用(Read-Only)レイヤーが積み重なっていきます

3. RUN Container & Copy-on-Write

STANDBY

イメージをRun（実行）して、ファイル編集（CoWアクション）を実行してみましょう。

STATUS: UP (RUNNING)

コンテナ内のファイルの不変編集デモ:

src/index.js (不変)

index.js

lowerdir (読込のみ) ➡️ upperdir (書込) へ複製中...

App Server is listening on port 8080...

Linux Kernel の真髄: Namespace(名前空間) と cgroups

Linuxカーネル標準の「プロセス隔離」と「物理リソース調停」の仕組み。コンテナの本当の正体を暴きます。

初心者向け：例え話で納得する違い

🕶️ Namespace (名前空間) =「特殊な目隠しメガネ」

これをかけると、同じホストにいる他の人やアプリが全く見えなくなります。「自分だけがこのシステムを独占している！」と錯覚させる魔法のフィルターです。

⚖️ cgroups (コントロールグループ) =「リソース予算制限」

「CPUはこれだけ」「メモリは256円まで」と制限します。使いすぎたら自動的にLinuxカーネル（OOM Killer）に怒られて没収（強制終了）されます。

低レイヤー：clone()、pivot_root、cgroups v2 の仕組み

📞 clone() System Call

Dockerは `clone()` 時に `CLONE_NEWPID | CLONE_NEWNET | CLONE_NEWNS` などのフラグを渡すことで、隔離されたカーネルデータ構造のインスタンスを各プロセスに割り当てます。

📂 pivot_root System Call

従来のセキュリティが脆弱な `chroot` は使わず、`pivot_root` を用いて、プロセスのルートマウント自体を完全にOverlayFSの `merged` パスにすり替え、ホストファイルシステムへのアクセスを物理遮断します。

📈 cgroups v2 & sysfs

カーネルの統合ディレクトリ `/sys/fs/cgroup/` 下の該当スライスにプロセスID（PID）を書き込み、`cpu.max` や `memory.max` を書き換えることで、カーネルスケジューラが精密にCPU時間を制限します。

Namespace (名前空間による隔離)

隔離メガネを装着

ホストの視野 (Host Namespace)

PID 1 systemd (init)

PID 1024 dockerd (Docker)

PID 15421 node index.js (容器A)

PID 15480 python app.py

コンテナの視野 (Isolated Namespace)

PID 1 node index.js (メイン)

目隠しメガネが有効化されると、ホスト側の他のプロセス（PID 1, 1024, 15480）は完全に不可視となり、自プロセス（PID 1）しか存在しない視野となります。

Namespaceの種類と対応システムコールフラグ:

上のボタンを押すと、各名前空間のカーネルにおける役割が表示されます。

cgroups (リソース制限と割当)

Path: /sys/fs/cgroup/

特定のコンテナが暴走してCPUやメモリを食い尽くし、親サーバーや他のコンテナを巻き連れてクラッシュするのを防ぎます。

CPUリミット設定 (cgroup cpu.max) 100%

10% (cpu.max: 10000 100000) 100% (フル稼働)

コンテナの処理速度シミュレーター

順調にリクエストを処理中...

120 TPS

メモリ制限テスト (Limit: 256MB): HEALTHY

cgroup使用量 (memory.current): 32 MB / 256 MB

OOM Killerによりプロセスが即時SIGKILLされました！

Linux Kernel Syscall Trace (システムコール監視) リアルタイムトレース

> Waiting for kernel actions...

コンテナ外との接続: Port Forwarding (通信) と Volume (データ永続化)

使い捨てのコンテナが外部と通信し、コンテナを破棄(rm)してもデータを消失させないためのカーネルマウント技術。

初心者向け：例え話で納得する違い

☎️ ポート転送 =「ホテルの内線転送」

ホテルの代表番号（ホストのポート8080）への電話を、部屋番号「80」（コンテナのポート80）に自動で転送してくれるフロントの電話交換機のような役割です。

🗄️ ボリュームマウント =「銀行の貸金庫」

コンテナ内のデータをホスト（PC本体）の安全な金庫に預けます。アパート（コンテナ）を退去（削除）して部屋がまっさらになっても、金庫（ホスト側フォルダ）の中身は一切消えません。

低レイヤー：vethペア、iptables、bind mount の仕組み

🔌 Virtual Ethernet & iptables NAT

ホストとコンテナのNamespace間は、仮想LANケーブルの両端となる `veth` ペアで接続されます。ホストへ届いたアクセスは、カーネルのIPパケットフィルタシステム `iptables` のNAT転送（PREROUTING）によりコンテナに送り込まれます。

📂 Bind Mount (mount system call)

カーネルのシステムコール `mount(src, target, ..., MS_BIND, ...)` を呼び出すことで、ホストのファイルシステムのディレクトリツリー実体を、コンテナ内のローカルマウントツリーへ直接バインドします。

Port Forwarding (ネットワークと仮想ルータ)

-p 8080:80

ホストマシンの特定のポートへのアクセスを、隔離されたコンテナ内のポートへ橋渡しします。

ユーザー PC Browser

Host OS Port: 8080

Docker Container Port: 80

HOST http://localhost:8080 (iptables REDIRECT)

VETH-PAIR vethXXXX -> container_eth0 (IP: 172.17.0.2:80)

Docker Volume (データ永続化とマウント)

-v host_dir:container_dir

コンテナ内のディレクトリに、ホスト側のフォルダをカーネルを介して直結（バインドマウント）します。

コンテナ内のフォルダ /var/lib/mysql

ホストOSのフォルダ /home/user/db_data

コンテナとホストのデータは現在リンクされています (マウント中)。

Docker Visual Learner へのガイダンス

左側のナビゲーションメニューを選択して、Dockerの各技術要素に対応するインタラクティブなアニメーションを実行してみましょう。

仮想マシン(VM) と Dockerコンテナ の構造比較

初心者向け：例え話で納得する違い

低レイヤー：カーネルとCPUハードウェアの真実

リソーススケール・耐久テスト

Build, Ship, Run & OverlayFS の立体レイヤー構造

初心者向け：例え話で納得する違い

低レイヤー：OverlayFS（Union FS）と Copy-on-Write（CoW）

Linux Kernel の真髄: Namespace(名前空間) と cgroups

初心者向け：例え話で納得する違い

低レイヤー：clone()、pivot_root、cgroups v2 の仕組み

Namespace (名前空間による隔離)

cgroups (リソース制限と割当)

コンテナの処理速度シミュレーター

コンテナ外との接続: Port Forwarding (通信) と Volume (データ永続化)

初心者向け：例え話で納得する違い

低レイヤー：vethペア、iptables、bind mount の仕組み

Port Forwarding (ネットワークと仮想ルータ)

Docker Volume (データ永続化とマウント)

Docker チートシート & 重要カーネル操作コマンド

仮想マシン(VM) と Dockerコンテナの構造比較