Day12：ログ・デバッグ（前半）
テーマ：コンテナの“中で何が起きているか”を読み取り、原因を突き止める力をつける
Day12 の前半では、Docker を使った障害対応の基本である
docker logs（ログ確認） と docker exec（コンテナに入って調査）
を、初心者でも直感で理解できるように解説します。
ここを理解すると、あなたは
「コンテナが動かない」「エラーが出る」
といったトラブルに冷静に対処できるようになります。
ログを見ることは「コンテナの声を聞く」こと
docker logs は最初に使う“聴診器”
アプリが動かないとき、まずやるべきことは ログを見ること です。
ログには、アプリが
- 何をしようとしたか
- どこで失敗したか
- どんなエラーが出たか
がすべて書かれています。
コマンド
docker logs <コンテナID>
例：Node.js アプリが落ちたとき
ログにこう出ているかもしれません。
Error: Cannot find module 'express'
これは
express がインストールされていない
という意味です。
ログを見るだけで、原因の 80% は分かります。
docker logs の“よく使うオプション”を深掘りする
リアルタイムでログを追う（tail -f のように）
docker logs -f <コンテナID>
-f は follow（追跡） の意味で、
アプリが出力するログをリアルタイムで見られます。
Web サーバや API のデバッグで必須です。
最新のログだけ見たい
docker logs --tail 50 <コンテナID>
直近 50 行だけを表示します。
docker exec は「コンテナの中に入って直接調査する」ためのコマンド
コンテナの中に入る＝サーバに SSH する感覚
docker exec は、コンテナの中に入り、
ファイルを見たり、コマンドを実行したりできる強力なコマンドです。
docker exec -it <コンテナID> bash
これで何ができるか
- ファイルの中身を見る
- 設定ファイルが正しいか確認する
- node や python のバージョンを確認する
- DB に直接接続して状態を確認する
つまり、
「アプリが動いている現場に直接入り込む」
というイメージです。
例題：web コンテナが DB に接続できないとき
まずログを見る
docker logs web
ログにこう出ていたとします。
Error: connect ECONNREFUSED 127.0.0.1:3306
これは
localhost（127.0.0.1）に DB がいない
という意味です。
次にコンテナに入って確認
docker exec -it web bash
中に入ったら、ping で確認できます。
ping db
もし応答があれば、
ネットワークはつながっている
ということです。
docker exec が使えると“原因の切り分け”ができる
例：ファイルがコピーされていない
docker exec -it web bash
ls /app
ここに必要なファイルがなければ、
Dockerfile の COPY が間違っていることが分かります。
例：環境変数が設定されていない
docker exec -it web bash
env
ここに DB_HOST がなければ、
docker-compose.yml の environment が間違っています。
前半まとめ
あなたがここまで理解できていれば、前半はクリアです。
- docker logs は「コンテナの声を聞く」ための最初のツール
- エラーの 80% はログを見るだけで分かる
- docker exec は「コンテナの中に入って直接調査する」ためのコマンド
- bash でファイル確認・環境変数確認・ネットワーク確認ができる
- logs と exec を使いこなせば、障害対応の基礎は完成