DOCKER VISUALIZER
Docker コンテナライフサイクル
コンテナの状態遷移（create → start → running → stop → remove）をステップで可視化します。
○
初期状態
docker images — イメージを確認
ローカルにダウンロード済みのイメージを確認します。イメージはコンテナの「設計図」であり、読み取り専用のレイヤーの積み重ねです。nginx:latest イメージを使ってコンテナを作成していきます。
Running
Paused
Stopped
Removed
Image
DOCKER ステップログ
1docker images — イメージを確認
2docker run — コンテナを作成・起動
3docker ps — 実行中コンテナを確認
4docker pause — コンテナを一時停止
5docker unpause — 一時停止を解除
6docker stop — コンテナを停止
7docker rm — コンテナを削除
解説
📌Docker コンテナとは
Docker コンテナは、アプリケーションとその依存関係をパッケージ化した軽量な実行環境です。 ホストOSのカーネルを共有しながら、プロセス・ネットワーク・ファイルシステムを隔離することで、どの環境でも同じように動くことを保証します。
たとえるなら、引っ越しの段ボール箱のようなものです。 中身（アプリ）と必要なもの（ライブラリ・設定ファイル）をまとめて箱に入れれば、どこに持っていっても同じように開けて使えます。 VM（仮想マシン）が「家ごと移動する」のに対し、コンテナは「箱だけ移動する」ので圧倒的に軽量です。
Docker Engine、containerd、Kubernetes など、コンテナ技術は現代のインフラの基盤になっています。 起動は数秒で完了し、イメージサイズは数十MB〜数百MB程度です。
ライフサイクル：
docker create で箱を準備 → docker start で起動 → docker stop で停止 → docker rm で削除⚙️コンテナの特徴
- ⚡軽量：VMのようにOSを丸ごと含まないため、イメージサイズは数十MB〜数百MBに収まります。起動も数秒で完了し、VMの「数分かかる起動」とは桁違いのスピードです。
- 📦ポータブル：開発マシンでもクラウドでも、同じイメージが同じように動きます。「自分のPCでは動いたのに、本番で動かない…」という問題を根本的に解消します。
- ♻️使い捨て可能（イミュータブル）：コンテナを壊しても、同じイメージからすぐ作り直せます。上のツールで remove → create を試すと、この「使い捨て」の感覚が分かります。
- 🔒隔離性：各コンテナはプロセス・ネットワーク・ファイルシステムが分離されています。1つのコンテナが壊れても他に影響しません。Linux の Namespace と cgroup という仕組みで実現されています。
🌍ユースケース
🚀 開発環境の統一
Docker Compose で MySQL + Redis + Nginx を一発構築。チーム全員が同じ環境で作業できる
🔄 CI/CD パイプライン
GitHub Actions や Jenkins でテスト・ビルド・デプロイをコンテナ内で実行。環境差異の問題を排除
☁️ マイクロサービス
各サービスを独立したコンテナで運用。Netflix, Spotify 等が大規模に採用
🧪 検証・実験
新しいツールやバージョンをホストを汚さず検証。不要になったら docker rm で即削除
🧩用語解説
イメージ（Image）
＝ コンテナの設計図
＝ コンテナの設計図
コンテナを作るための読み取り専用テンプレートです。Dockerfile から
docker build で作成されます。 レイヤーの積み重ねで構成されており、一度作ったら変更されません。コンテナ（Container）
＝ イメージから作った実行環境
＝ イメージから作った実行環境
イメージの上に書き込み可能なレイヤーを1つ追加したものです。 1つのイメージから何個でもコンテナを作れます（クッキーの型から何枚でもクッキーが焼けるイメージ）。上のツールの緑色の箱がコンテナです。
ライフサイクル（Lifecycle）
＝ コンテナの一生
＝ コンテナの一生
created → running → paused → stopped → removed という状態の流れです。 上のツールのステップ遷移がまさにこの流れを表しています。各状態で内部的に何が起きているかは Card 5 で解説しています。
ポートマッピング（Port Mapping）
＝ ホストとコンテナの窓口をつなぐ
＝ ホストとコンテナの窓口をつなぐ
-p 80:80 は「ホストの80番ポートに来た通信をコンテナの80番ポートに転送する」という意味です。 コンテナはデフォルトでは外部からアクセスできないため、ポートマッピングで「窓口」を開けます。docker create vs docker run
＝ 分割実行 vs 一括実行
＝ 分割実行 vs 一括実行
docker create はコンテナを作るだけ（created 状態）。 docker run は create + start を一発で実行します（running 状態）。 実務ではほとんど docker run を使います。🔄コンテナのライフサイクルの仕組み
1
Created — コンテナの「箱」ができる
docker create（または docker run の前半部分）を実行すると、カーネルがコンテナの実行環境を準備します。この段階ではプロセスはまだ動いていません。この段階で行われること
1. 書き込みレイヤーの追加：イメージの読み取り専用レイヤーの上に、コンテナ固有の書き込み可能なレイヤー（thin layer）を OverlayFS で重ねます。コンテナ内で行われたファイル変更はすべてこのレイヤーに記録されます。
2. ネットワーク設定：デフォルトでは
bridge ネットワークに接続されます。veth ペア（仮想ネットワークインタフェース）が作成され、片方がコンテナに、もう片方が docker0 ブリッジに接続されます。-p 80:80 を指定していれば、iptables の NAT ルールでポート転送が設定されます。3. メタデータの生成：コンテナ ID の割り当て、設定ファイル（
config.v2.json）の作成、ホスト名・DNS・環境変数の設定などが行われます。ボリュームマウントの準備もこの段階です。2
Running — プロセスが動いている
docker start（または docker run の後半部分）を実行すると、Linux Namespace で隔離された空間の中でメインプロセス（PID 1）が起動します。Linux Namespace による隔離
Namespace はカーネルのリソースをプロセスごとに分離する仕組みです。コンテナは以下の Namespace を使い、ホストや他のコンテナから完全に隔離されます。
PID NSプロセスIDを分離。コンテナ内のメインプロセスは PID 1 に見えるが、ホストからは別の PID
NET NSネットワークスタックを分離。コンテナ独自の IP アドレス・ルーティングテーブル・iptables を持つ
MNT NSファイルシステムのマウントを分離。コンテナ内の / はイメージ + 書き込みレイヤーの合成
UTS NSホスト名を分離。コンテナ独自のホスト名を持てる（docker run --hostname）
cgroup によるリソース制限
cgroup（Control Group）は、プロセスグループが使えるリソースの上限を設定する仕組みです。Namespace が「見える範囲」を制限するのに対し、cgroup は「使える量」を制限します。
docker run --memory=512m --cpus=1.5 のように指定すると、メモリ 512MB・CPU 1.5 コアに制限されます。 制限を超えると OOM Killer がプロセスを強制終了します。PID 1 の特殊性
コンテナ内のメインプロセスは PID 1 として動作します。通常の Linux では PID 1 は init/systemd ですが、コンテナではアプリケーションそのもの（nginx、node など）が PID 1 になります。 PID 1 が終了するとコンテナ全体が停止するため、シグナルの適切な処理が重要です。PID 1 はデフォルトで SIGTERM を無視するため、アプリが自分でハンドリングする必要があります（
--init フラグで tini を PID 1 にする回避策もあります）。3
Paused — プロセスが凍結されている
docker pause は cgroup の freezer を使ってプロセスを凍結します。 カーネルのスケジューラが対象プロセスへの CPU 時間の割り当てを停止するため、プロセスから見ると「次の実行順番が永遠に来ない」だけであり、凍結されていること自体に気づきません。cgroup freezer の仕組み
Linux カーネルのプロセススケジューラは、実行可能なプロセスに順番に CPU 時間を割り当てます（タイムスライス）。 freezer はこの仕組みに介入し、対象 cgroup 内のすべてのタスクを FROZEN とマークします。 スケジューラは FROZEN のタスクをスキップするため、プロセスは「待ち行列に並んだまま永遠に順番が来ない」状態になります。
SIGSTOP との違い
SIGSTOP はシグナルなので、親プロセスが waitpid() で検知でき、/proc/PID/status にも T (stopped) と表示されます。 一方 freezer はスケジューラレベルの操作なので、シグナルは一切送られず、プロセスの状態表示も変わりません。完全に透過的な停止です。保持されるもの
メモリ内容、ファイルディスクリプタ、TCP コネクション、ソケット、タイマーなどすべてが保持されます。
docker unpause するとスケジューラが再び CPU を割り当て、凍結直前の命令の「次」から実行再開します。プロセスから見ると「少し処理が遅延しただけ」に見えます。4
Stopped — プロセスが終了した
docker stop はプロセスにシグナルを送ってグレースフルシャットダウンを試み、応答がなければ強制終了します。シグナルによる2段階停止
第1段階：SIGTERM（終了要求）— メインプロセス（PID 1）に SIGTERM シグナルを送ります。 アプリケーションが SIGTERM をハンドリングしていれば、進行中のリクエストの完了・コネクションのクローズ・一時ファイルの削除など、後片付けを行ってから終了できます。
第2段階：SIGKILL（強制終了）— SIGTERM からデフォルト 10秒間のグレースピリオドを経ても終了しなければ、SIGKILL を送って即座に強制終了します。SIGKILL はプロセスが捕捉・無視できないため、確実に終了します。
docker stop -t 30 でグレースピリオドを変更できます。停止後に残るもの
プロセスは終了しますが、以下はすべて保持されます。
書き込みレイヤー
コンテナ内で作成・変更されたファイル
メタデータ
コンテナ設定、環境変数、ログ
ネットワーク設定
割り当てられた IP アドレスなど
これらが残っているため、
docker start で再起動できます。ただしメモリ上のデータ（変数の値、TCP コネクションなど）はすべて失われるため、プロセスは最初から起動し直しになります。これが pause との根本的な違いです。docker stop vs docker kill
docker stop は SIGTERM → 待機 → SIGKILL の「礼儀正しい」停止です。 docker kill は即座に SIGKILL を送る「強制」停止です。 通常は docker stop を使い、応答がないときだけ docker kill を使います。5
Removed — すべてが消える
docker rm でコンテナのすべての痕跡を削除します。ただしイメージと Volume は残ります。削除されるもの
書き込みレイヤー
コンテナ固有のファイル変更がすべて消える。OverlayFS の upperdir が削除される
メタデータ
config.v2.json、ホスト名設定、環境変数、コンテナログ
ネットワーク設定
veth ペアの削除、iptables ルールのクリーンアップ、IP アドレスの解放
残るもの
イメージ
読み取り専用レイヤー。同じイメージからいつでも新しいコンテナを作成できる
Volume
-v でマウントしていたデータ。docker volume rm しない限り残り続ける
コンテナの「使い捨て」設計
コンテナはイミュータブル（不変）な設計思想で使うのがベストプラクティスです。 コンテナ内部を直接変更するのではなく、Dockerfile を更新して新しいイメージをビルドし、古いコンテナを
rm して新しいコンテナを run するのが正しい運用方法です。 データの永続化が必要な場合は、必ず Volume を使います。❓コンテナに関するよくある質問
Q: コンテナとVMの違いは？
A: VMはOS丸ごと仮想化するため重く、起動に数分かかります。コンテナはホストのカーネルを共有してプロセスを隔離するだけなので、軽量で数秒で起動します。コンテナはアプリ単位の隔離、VMはOS単位の隔離と考えるとイメージしやすいです。
Q: docker run と docker create + docker start の違いは？
A: docker run = create + start を一発で実行するショートカットです。実務ではほとんど docker run を使います。create を単体で使うのは、起動前に設定を確認したい場合やテスト時です。
Q: コンテナを停止したらデータは消える？
A: docker stop ではデータは消えません（書き込みレイヤーが残り、docker start で再起動可能）。docker rm で初めて削除されます。永続化したいデータは Volume を使うのがベストプラクティスです。
Q: なぜ pause と stop が両方あるの？
A: pause は cgroup freezer でスケジューラから外すだけなので、メモリ・TCP接続・ファイルハンドルがすべて保持され、unpause で瞬時に再開できます。stop は SIGTERM でプロセスを終了させるため、再起動時にはプロセスが新規作成されます。一時的にCPUを解放したいだけなら pause、完全に停止してリソースを回収したいなら stop を使います。
Q: コンテナが停止できないときは？
A: docker stop は SIGTERM → 10秒後に SIGKILL を送ります。それでも止まらない場合は docker kill で即座に SIGKILL を送れます。根本的にはアプリ側で SIGTERM を適切に処理する実装が重要です。
関連コンテンツ
Docker Compose
マルチコンテナ構成の起動・通信・停止の仕組みを可視化
docker build とレイヤーキャッシュ
Dockerfileの各命令でレイヤーキャッシュがヒット/ミスする仕組みを可視化。命令の順番がビルド速度に与える影響を理解できます
Docker Registry
イメージのpush/pullとレイヤー単位の転送の仕組みを可視化
マルチステージビルド
複数ステージで最終イメージを劇的に軽量化する仕組みを可視化
Docker データ永続化
Volume・Bind Mount・tmpfsの3方式の仕組みとコンテナ削除時のデータの行方を可視化
Docker ポートマッピング
ホスト↔コンテナのポート転送とNATの仕組みを可視化