Day12：ログ・デバッグ（中盤）
テーマ：実際の障害シナリオを使って “docker logs と docker exec をどう使い分けるか” を体で覚える
中盤では、前半で学んだ
docker logs（ログ確認）
docker exec（コンテナ内部調査）
を、実際のトラブル事例を使って「どう使い分けるか」を深掘りします。
ここを理解すると、あなたは
“原因を推測する人” から “原因を特定できるエンジニア”
に進化します。
コンテナ障害対応の基本フローを理解する
まずはこの順番を頭に入れる
障害対応は次の順番で進めると、最短で原因にたどり着けます。
- docker logs でエラー内容を確認する
- docker ps でコンテナの状態を確認する
- docker exec で内部に入り、設定・ファイル・ネットワークを調査する
この順番は、実務でもほぼ全員が使っています。
理由は「ログ → 状態 → 内部調査」が最も効率的だからです。
シナリオ1：アプリが起動直後に落ちる
Step1：まずログを見る
docker logs web
ログにこう出ていたとします。
Error: Cannot find module 'express'
これは
express がインストールされていない
という意味です。
Step2：コンテナに入って確認
docker exec -it web bash
ls node_modules
ここに express がなければ、
Dockerfile の npm install が正しく動いていない可能性が高いです。
Step3：原因を特定
- COPY の順番が間違っている
- package.json がコピーされていない
- npm install がキャッシュされている
などが考えられます。
シナリオ2：web → db の接続が失敗する
Step1：ログを見る
docker logs web
ログにこう出ていたとします。
Error: connect ECONNREFUSED 127.0.0.1:3306
これは
localhost に DB がいない
という意味です。
Step2：コンテナに入ってネットワーク確認
docker exec -it web bash
ping db
応答があれば、
ネットワークはつながっている
ということです。
Step3：環境変数を確認
env | grep DB
もし DB_HOST=db が設定されていなければ、
docker-compose.yml の environment が間違っています。
シナリオ3：コンテナは動いているのに API が応答しない
Step1：ログをリアルタイムで追う
docker logs -f api
リクエストが来ているか、エラーが出ているかを確認します。
Step2：コンテナ内部でポート確認
docker exec -it api bash
netstat -tlnp
ここで
アプリが 3000 番で待っているか
を確認します。
もし 3000 番で待っていないなら、
アプリ側の設定ミスです。
Step3：Dockerfile の CMD やアプリ設定を確認
- CMD が間違っている
- ポート番号が違う
- アプリが 0.0.0.0 で待っていない（127.0.0.1 で待っている）
などが原因になります。
シナリオ4：コンテナが “Restarting” を繰り返す
Step1：状態確認
docker ps
STATUS が Restarting なら、
起動 → エラー → 再起動 を繰り返しています。
Step2：ログで原因確認
docker logs <ID>
多くの場合、
- ポート競合
- 環境変数不足
- DB 接続失敗
- CMD の書き間違い
が原因です。
Step3：exec は使えない
Restarting 状態では exec が失敗します。
つまり、
logs が唯一の情報源
になります。
docker logs と docker exec の使い分けを深掘りする
docker logs が向いている場面
- アプリのエラーを知りたい
- 起動時のエラーを確認したい
- Restarting の原因を知りたい
- リクエストの流れを追いたい（-f）
docker exec が向いている場面
- ファイルが正しくコピーされているか確認したい
- 環境変数が正しいか確認したい
- ネットワークがつながっているか確認したい
- DB や Redis に直接接続して状態を見たい
この使い分けができると、
障害対応のスピードが劇的に上がります。
中盤まとめ
あなたがここまで理解できていれば、中盤はクリアです。
- 障害対応は「logs → 状態 → exec」の順で進める
- 起動直後のエラーは logs が最速
- 接続エラーは logs と exec の両方で調査
- Restarting は logs が唯一の情報源
- exec でファイル・環境変数・ネットワークを直接確認できる