ログ確認とコンテナ内操作
動いているコンテナの様子を知る基本が docker logs です。コンテナが標準出力に書いた内容を表示し、-f を付ければログを追従して監視できます。中に入って調べたいときは docker exec を使い、-it を付けて起動中のコンテナでシェルを開けば、ファイルの確認や設定の調査ができます。コンテナはアプリ専用に最小構成で作るため、トラブル時はこの2つで状況をつかみます。
コンテナが思ったとおりに動かない。あるいは、バックグラウンドで黙々と動いているコンテナの中で、いま何が起きているのか知りたい。そんなとき、何を頼ればいいのか。
答えは2つ、「ログを見る」操作と「中に入って調べる」操作だ。
コンテナはアプリ専用に最小構成で作られていることが多く、GUI もなければ余計なツールも入っていない。だから、トラブルの状況をつかむにはこの2つの手段を使いこなせることが出発点になる。具体的には docker logs と docker exec を押さえる。まずは外から覗くログから見ていく。
📜 バックグラウンドの中身を覗く――docker logs
コンテナが標準出力(画面に相当する出力)へ書いた内容は、docker logs コンテナ名 でまとめて確認できる。
-d でバックグラウンド起動したコンテナは、画面に何も表示されない。だから、調子が悪いときはまずこのログで様子を見るのが基本だ。たとえば docker logs web とすれば、nginx のアクセスログやエラーが時系列で表示される。
アプリが起動直後に落ちてしまうようなときも、ここに原因のメッセージ(設定ファイルが見つからない、ポートが使えない、など)が出ていることがほとんどだ。
ログを過去の記録としてではなく、いま流れている様子として追い続けたいときはどうするか。-f(follow)オプションを付けて docker logs -f web とする。
こうすると、コンテナに新しいログが書き込まれるたびに、その行が画面へリアルタイムに流れ続ける。サービスを操作しながらログの動きを目で追う、いわゆるログ監視の定番だ。たとえば別の端末でWebサーバにアクセスしながら、こちらで docker logs -f を回してアクセスログが増えるのを確認する、といった使い方をする。
流し続ける表示を止めるには Ctrl + c を押す。直近の一定行だけ見たいときは --tail 50 を付けて docker logs --tail 50 web のようにすると、末尾の50行に絞って表示でき、各行の時刻も見たいなら -t(timestamps)を足す。
🚪 ログで足りないとき、中へ入る――docker exec
ログだけでは原因がつかめず、コンテナの中のファイルや設定そのものを調べたいときは、docker exec を使う。docker exec は「すでに動いているコンテナの中で、追加のコマンドを実行する」ためのコマンドだ。
シェルを開いて中を歩き回りたいときは、-it を付けて docker exec -it web bash のように実行すると、稼働中のコンテナ web の中の bash にそのまま入れる。
プロンプトが root@(コンテナID) に変わり、あとは通常の Linux と同じように ls や cat で設定ファイルを確認したり、cat /etc/os-release で中身がどのディストリビューションか確かめたりできる。調べ終わったら exit で抜ける。
ここで、よく似た docker run と何が違うのかをはっきりさせておこう。
docker run は「イメージから新しいコンテナを作って、その中でコマンドを実行する」操作だ。これに対して docker exec は「すでに動いている既存のコンテナに、後から入ってコマンドを実行する」操作である。
前者は新しい箱を作る、後者は今ある箱に後から入る、というイメージだ。たとえば -d で起動したサーバ系コンテナの中を調べたいときは、新しい箱を作る docker run ではなく、動いている箱に入る docker exec -it を使う、というのが正しい使い分けになる。
🐚 bash が無い――軽量イメージで何が起きているか
exec で中に入ろうとして bash が無い、というのはよくあるつまずきだ。
alpine のような極小イメージには bash が入っておらず、docker exec -it web bash が「実行ファイルが見つからない(executable file not found)」と失敗する。この場合は、より基本的なシェルである sh を指定して docker exec -it web sh とすれば入れる。「bash で駄目なら sh を試す」と覚えておくと、軽量イメージでも慌てずに済む。
また、入ったコンテナの中で「あるはずのコマンドが無い」と感じることも多い。これはバグではなく、コンテナがアプリに必要な最小限のものしか持っていないためだ。調査用のツールが足りないときは、一時的にコンテナ内でパッケージを入れることもできるが、それはあくまで一時しのぎで、恒久的な変更は Dockerfile 側で行うのが筋になる。
🔭 全体像は、どのコマンドで一望できるか
ログと exec に加えて、状況把握を助ける補助コマンドもある。
docker ps -a でコンテナが Up なのか Exited なのかを確かめれば、「動いていないものに exec しようとしている」といった行き違いに気づける。
さらに踏み込んで設定の詳細(マウント状況や環境変数、割り当てポートなど)を確認したいときは docker inspect コンテナ名 が使える。コンテナのCPUやメモリの使用状況をリアルタイムに見たいときは docker stats が役立つ。
トラブル時は、まず docker ps -a で生死を見て、docker logs で出力を読み、必要なら docker exec で中に入る、という順序で切り分けると効率的だ。
🏥 この二段構えは、現場でどう効くか
実務でのコンテナのトラブル対応は、ほぼこの流れに集約される。
アプリが応答しない・起動しないときは、まず docker logs(必要なら -f)でエラーメッセージを探し、原因の見当をつける。ログだけで足りなければ docker exec -it で中に入り、設定ファイルの中身やマウントされたボリュームの状態、環境変数(printenv で確認)などを実地に調べる。
本番のコンテナを直接いじるのは最小限にとどめ、原因が分かったら Dockerfile や起動オプションを直して作り直す、というのが安全なやり方だ。つまずいたら、まずこれ。『まずログ、足りなければ中に入る』、この2段構えを身につけておけば、中身の見えないコンテナでも落ち着いて原因にたどり着ける。