Docker／コンテナ — アプリを箱ごと運んで どこでも同じに動かす

Docker の世界は、イメージとコンテナの2語で回っています。

• イメージ（※1）— 箱の設計図。不変のテンプレートで、これ自体は動かない
• コンテナ — イメージを起動して動いている実体（実行インスタンス）

イメージは1枚岩ではなく、レイヤ（※2）＝差分の積み重ねでできています。下からベースOS層・ランタイム/ライブラリ層・アプリ層…と重なり、同じ層は共有・キャッシュされます。だから配布もビルドも速く済みます。

登場人物メモ:

• ※1 イメージ — アプリと環境を固めた不変のテンプレート
• ※2 レイヤ — イメージを構成する差分の層。共有・再利用でき、キャッシュが効く
• ※3 レジストリ — イメージを保管・配布する倉庫（Docker Hub など）

1. Dockerfile（手順書）にアプリと環境の作り方を書く
2. それをビルドしてイメージ（設計図）を作る
3. イメージをレジストリ（※3 倉庫）へ push（アップロード）する
4. 使う場所で pull（ダウンロード）し、run でコンテナとして起動する

同じイメージを配れば、開発でも本番でも同じものが立ち上がる——これが ポータビリティ（持ち運びやすさ）の本質です。

なぜ「軽いのに隔離されている」のか。土台の OSの仕組み が鍵です。

• namespace（名前空間） — プロセスから見える範囲を仕切る。他のコンテナやホストが見えないので、独立して見える
• cgroups — CPUやメモリなど使える資源に上限をかける。1つが暴走しても巻き込まれにくい
• カーネルは共有 — 別OSを積まないので、起動は秒単位で軽い

つまりコンテナは「小さな仮想マシン」ではなく、隔離して資源制限したプロセスだと捉えると腑に落ちます。

• イメージの肥大化 — 不要な物まで層に積むと重くなる（最小限の土台を選ぶ）
• 状態の消失 — コンテナは使い捨て前提。消えて困るデータは外部（ボリューム等）へ
• カーネル依存 — ホストと大きく異なるOSは共有カーネルでは動かせない
• latest 頼み — バージョンを固定しないと、環境ごとに中身がずれて「動かない」が再発する