Day2：基本コマンド完全習得（後半）
後半では、前半・中盤で学んだコマンドを “実務でどう使うか” という視点でまとめます。
ここを理解すると、Dockerの操作が「ただのコマンド入力」から「意図を持ったコンテナ管理」に変わります。
つまり、コンテナのライフサイクルを自在にコントロールできる状態になります。
コンテナ管理の“実務的な流れ”を理解する
実務では「作る → 動かす → 止める → 消す」を繰り返す
開発中は、コンテナを何度も作り直します。
コードを変えたらコンテナを再起動したり、環境を壊したら作り直したりします。
そのため、次の流れを自然に使えることが重要です。
docker run → docker ps → docker stop → docker rm
この流れが コンテナのライフサイクルの基本形 です。
よくある実務シナリオでコマンドを使いこなす
シナリオ1：コンテナが動いているか確認したい
開発中に「動いてる？止まってる？」が分からなくなることはよくあります。
そのときは：
docker ps
もし表示されないなら：
docker ps -a
これで「動いている」「止まっている」すべてのコンテナが見えます。
シナリオ2：コンテナが暴走したので止めたい
アプリが無限ループしたり、CPUを食いすぎたりしたときは：
docker stop コンテナID
stop は 安全に終了させる コマンドです。
プロセスに終了シグナルを送り、丁寧にシャットダウンします。
シナリオ3：環境を壊したので作り直したい
開発中に「設定を間違えた」「環境が壊れた」というのは日常茶飯事です。
そんなときは、コンテナを削除して作り直すのが最も早いです。
docker stop web
docker rm web
docker run --name web nginx
この流れを覚えると、
「壊れたら消して作り直す」 というDockerの強みを最大限活かせます。
シナリオ4：イメージが増えすぎたので整理したい
開発を続けていると、イメージがどんどん溜まっていきます。
一覧を見る：
docker images
不要なイメージを削除：
docker rmi イメージ名
ただし、
そのイメージを使ったコンテナが残っていると削除できません。
つまり、
コンテナ → イメージの順で削除する
というルールがあります。
コンテナとイメージの“関係性”を深掘りして理解する
コンテナは「実体」、イメージは「設計図」
イメージを削除しても、コンテナは動き続けることがあります。
なぜなら、コンテナはイメージを元に作られた“コピー”だからです。
逆に、コンテナを削除してもイメージは残ります。
これは、同じイメージから何度でもコンテナを作れるようにするためです。
この関係を理解すると、
「イメージを消すときはコンテナを先に消す」
というルールが自然に理解できます。
コンテナのライフサイクルを“図”として頭に描けるようにする
これが Docker の基本サイクル
docker run
↓
running（動作中）
↓ docker stop
exited（停止）
↓ docker rm
deleted（削除）
そして、イメージは別枠で存在します。
docker images → イメージ一覧
docker rmi → イメージ削除
この図が頭に浮かぶようになれば、
Dockerの基本操作は完全に理解できています。
Day2のゴール達成チェック
あなたは次の質問に答えられますか？
コンテナを作って動かすコマンドは？
動いているコンテナを見るコマンドは？
コンテナを止めるコマンドは？
コンテナを削除するコマンドは？
イメージ一覧を見るコマンドは？
イメージを削除するコマンドは？
コンテナとイメージの違いは？
コンテナのライフサイクルを説明できる？
これらを自分の言葉で説明できれば、
Day2のゴール「コンテナのライフサイクルを理解」は完全達成です。