ログ確認とコンテナ内操作
動いているコンテナの様子を知る基本が 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 を使う、というのが正しい使い分けです。
軽量イメージならではのつまずき
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段構えを身につけておけば、中身の見えないコンテナでも落ち着いて原因にたどり着けます。