6.2Dockerコンテナとイメージの管理

前節で学んだ名前空間・cgroups・イメージの仕組みは、Dockerというツールを通して日々の運用に落とし込まれます。コンテナを起動・一時停止・停止・削除し、イメージを取得・作成・配布する一連の操作コマンドを、状況に応じて正確に選べることが実務でも試験でも問われます。

6.2.1ネットワークと状態確認

• ポート変換（ポートマッピング）＝コンテナ内のポートをホストのポートに対応付ける仕組み（docker run -p 8080:80 のようにホスト側:コンテナ側で指定）。ホストの1つの IP アドレスで複数コンテナを外部に公開するための仕組み。
• フラットL2ネットワーク＝コンテナ同士がブリッジを介して同一の仮想L2ネットワーク（同一サブネット）に接続され、相互に通信できる既定のネットワークモデル。ルーティングを介さず直接到達できる構成が基本形。
• docker ps＝実行中のコンテナ一覧（-a で停止中も含め全件）。docker stats＝実行中コンテナのCPU・メモリ・ネットワークI/Oなどのリソース使用状況をリアルタイム表示。

6.2.2コンテナのライフサイクル管理

• docker run＝イメージから新規コンテナを作成して即座に起動（イメージがローカルに無ければレジストリから取得してから実行）。docker create＝コンテナを作成するだけで起動しない（後で docker start する運用に使う）。docker restart＝実行中／停止中のコンテナを再起動。
• docker pause＝コンテナ内の全プロセスを（cgroups freezer機能で）一時凍結し、CPU を使わせない。docker unpause＝凍結解除して実行再開。プロセスの状態は保持されたまま止まる点が停止（stop）と異なる。
• docker stop＝コンテナに終了シグナルを送り猶予期間の後停止（正常終了を試みる）。docker kill＝即座に強制終了（猶予なし）。docker rm＝停止済みコンテナを削除（実行中は -f で強制削除するか、先に stop/kill が必要）。

コンテナ内部を直接操作する場面ではdocker attachとdocker execを使い分けます。attachはすでに実行中のコンテナのメインプロセス（PID 1）の標準入出力に接続するもので、ログを流し見たり、そのプロセスへ直接入力したりする用途です。ただし接続を終了する際に Ctrl+C を送るとメインプロセスそのものが終了しコンテナが停止しかねない点に注意が必要です。一方execは実行中のコンテナ内で新しいプロセスを起動する仕組みで、docker exec -it コンテナ名 /bin/bash のようにデバッグ用のシェルを追加で開く用途に向きます。元のメインプロセスには影響しません。イメージの入手経路はDockerレジストリ（既定は Docker Hub）です。docker pullでレジストリからイメージを取得し、ローカルのdocker imagesで保有イメージの一覧（リポジトリ名・タグ・イメージID・サイズ）を確認し、不要になったらdocker rmiで削除します。docker importは、tar 形式にまとめられたファイルシステムのアーカイブからレイヤー履歴を持たない単一レイヤーの新規イメージを作成するコマンドです。イメージ自体を作る主戦場はDockerfileです。FROM・RUN・COPY・CMD などの命令を並べたテキストファイルを用意し、docker buildでその手順どおりに再現可能な形でイメージをビルドします（Dockerfile の各命令がおおむね1レイヤーに対応）。対してdocker commitは、すでに動いている（変更を加えた）コンテナの現在の状態をそのままイメージ化する手段で、手順書としての Dockerfile を残さないため再現性に劣りますが、素早く現状のスナップショットを残したいときに使えます。

6.2.3この節のまとめ

• ライフサイクル＝run（作成+起動）/create（作成のみ）/restart・stop（猶予あり）/kill（即時）/rm（削除）・pause/unpause（凍結/解除）
• イメージ＝レジストリからpull／imagesで一覧／rmiで削除／importで単層イメージ化。作成はDockerfile+build（再現可能）／commit（実行中の状態を直接画像化）