Day12：ログ・デバッグ（後半）
テーマ：実務で使える“デバッグの型”を身につけ、トラブルを未然に防ぐ Dockerfile / Compose の書き方を理解する
後半では、前半・中盤で学んだ
docker logs と docker exec の使い方
をさらに実務レベルに引き上げます。
ここでは、
「どう調べるか」だけでなく「そもそもトラブルを起こさない設計」
まで踏み込みます。
あなたが Day12 を終える頃には、
“障害対応できるエンジニア” としての基礎が完成します。
デバッグの型を身につける
まずは「型」で動くと迷わない
実務では、障害対応は 感覚ではなく型で動く ことが重要です。
ここでは、プロのエンジニアが実際に使っている
Docker デバッグの型 を紹介します。
デバッグの型①：起動しないときの型
1. ログでエラー内容を確認
docker logs <ID>
起動直後のエラーはほぼ 100% ログに出ます。
例：
Error: Cannot find module 'express'
2. コンテナ内部でファイル確認
docker exec -it <ID> bash
ls /app
ファイルが無い → COPY ミス
node_modules が無い → npm install ミス
3. Dockerfile の COPY / RUN を見直す
特に COPY の順番はトラブルの元です。
デバッグの型②：接続エラーの型（web → db）
1. ログで接続エラーを確認
docker logs web
例：
ECONNREFUSED 127.0.0.1:3306
これは localhost に DB がいない という意味。
2. コンテナ内部でネットワーク確認
docker exec -it web bash
ping db
応答があればネットワークは OK。
3. 環境変数を確認
env | grep DB
DB_HOST=db が無ければ設定ミス。
デバッグの型③：API が応答しないときの型
1. リアルタイムログで挙動確認
docker logs -f api
2. ポートが開いているか確認
docker exec -it api bash
netstat -tlnp
アプリが 3000 番で待っていない → アプリ側の設定ミス。
3. 0.0.0.0 で待っているか確認
127.0.0.1 で待っていると、外部からアクセスできません。
デバッグの型④：Restarting を繰り返すときの型
1. 状態確認
docker ps
2. ログ確認（最重要）
docker logs <ID>
Restarting 中は exec が使えないため、
logs が唯一の情報源 です。
トラブルを未然に防ぐ Dockerfile の書き方
1. COPY の順番を最適化
COPY package*.json ./
RUN npm install
COPY . .
これで npm install がキャッシュされ、
ビルドが安定します。
2. CMD を 1 つだけにする
複数書くと最後の CMD しか動きません。
3. EXPOSE と実際のポートを一致させる
EXPOSE 3000
アプリは 3000 番で待つ
docker run -p 3000:3000
この 3 つがズレるとトラブルの元です。
トラブルを未然に防ぐ docker-compose.yml の書き方
1. environment を明示的に書く
environment:
DB_HOST: db
DB_USER: user
2. depends_on を使って起動順序を明確に
depends_on:
- db
3. service名で接続する
localhost を使わない。
web → api → db
すべて service名で接続。
実務で使う「最強のデバッグチェックリスト」
コンテナが動かないとき
- logs を見たか
- ps で状態を見たか
- exec で内部を確認したか
- ファイルはあるか
- 環境変数はあるか
- ポートは開いているか
- localhost を使っていないか
このチェックリストを使えば、
ほとんどの障害は 5〜10 分で原因にたどり着けます。
後半まとめ
あなたがここまで理解できていれば、Day12 のゴールは完全達成です。
- logs と exec を使い分ける“デバッグの型”を理解した
- 起動エラー・接続エラー・ポート問題・Restarting の原因を特定できる
- Dockerfile / Compose の書き方でトラブルを未然に防げる
- 実務で使えるチェックリストを持てた