【ITニュース解説】Get a debug console on failing docker container launches.

システム開発の現場では、ソフトウェアを動かす環境をコンテナ化することが一般的になっている。特にDockerは、アプリケーションとその実行に必要なものをパッケージ化し、どの環境でも同じように動かせる強力なツールだ。しかし、この便利なDockerコンテナも常にスムーズに動くわけではない。時には、せっかく準備したコンテナが期待通りに起動せず、すぐに停止してしまうことがある。このような状況に遭遇したとき、何が原因でコンテナが動かないのか、その内部に何が起きているのかを把握する必要がある。今回の解説では、起動に失敗したDockerコンテナの内部にアクセスし、問題の原因を突き止めるためのデバッグ手法を、システムエンジニアを目指す初心者にも理解できるよう詳しく解説する。

アプリケーションを動かすために docker compose build や docker build コマンドでコンテナイメージを作成し、docker compose up -d のようなコマンドでそのイメージからコンテナを起動しようとすることが多いだろう。しかし、起動後すぐにコンテナが停止し、期待通りに動作しない場合がある。例えば、docker ps -a コマンドを実行すると、現在システム上にある全てのコンテナ（停止中のものも含む）の一覧が表示される。この一覧の中に、Exited (127) のようなステータスで停止しているコンテナが見つかることがある。これは、コンテナが正常に起動せず、何らかのエラーコード（この場合は127）を返して終了したことを意味する。正常に動いているコンテナはUpというステータスになっているため、Exitedと表示されているコンテナが問題の原因だとすぐにわかるだろう。この状況では、なぜコンテナが終了してしまったのか、その詳細な原因を突き止める必要がある。

通常のコンテナ起動では、定義されたエントリポイント（コンテナが起動したときに最初に実行されるコマンドやスクリプト）が実行され、それがエラーで終了するとコンテナ全体も停止してしまうため、その内部に直接アクセスして操作することは難しい。しかし、問題解決にはコンテナ内部のファイルシステムを確認したり、ログファイルを読み込んだり、特定のコマンドを実行して状態をチェックしたりする必要がある。そこで登場するのが、起動に失敗したコンテナをデバッグモードで動かすための特別な手法だ。この手法を使えば、コンテナが停止した状態から、その内部にインタラクティブなシェル環境を作り出し、自由にコマンドを実行できるようになる。

まず行うのは、起動に失敗して停止しているコンテナの状態を、あたかも新しいスナップショットとして保存する作業だ。これは docker commit コマンドを使って実現できる。具体的には、docker commit <停止中のコンテナIDまたは名前> <新しいイメージ名> という形式でコマンドを実行する。例えば、docker commit blog-testprod-django-testprod-1 debug-image とすれば、blog-testprod-django-testprod-1 という名前の停止中のコンテナの状態が debug-image という新しいDockerイメージとして保存される。この操作により、エラーで停止した時点のコンテナ内部の状態を、変更されることなく、いつでも再利用できる「一時的なイメージ」として手元に残せる。

次に、この新しく作成した debug-image を使って、デバッグ目的の特別な方法でコンテナを起動する。ここで使うのが docker run コマンドだ。このコマンドにはいくつかの重要なオプションを付与する。まず、-it オプションは、コンテナとインタラクティブにやり取りするためのターミナルを割り当て、標準入力を開いた状態にする。これにより、コンテナ内部でキーボードからの入力を受け付け、その出力を画面に表示できるようになる。次に、--rm オプションは、このデバッグ用コンテナが終了した際に、自動的にそのコンテナを削除してくれるため、一時的なデバッグ用途に適している。そして最も重要なのが --entrypoint オプションだ。これは、コンテナが起動したときに最初に実行するコマンド（エントリポイント）を上書きするためのものだ。ここではそれを無視し、--entrypoint /bin/bash もしくは --entrypoint /bin/sh と指定する。/bin/bash や /bin/sh は、どちらもコンテナ内でコマンドを実行するためのシェルプログラムだ。例えば、docker run -it --rm --entrypoint /bin/bash debug-image のようにコマンドを実行すると、debug-image から起動されたコンテナの内部でシェルが立ち上がり、あなたはまるでコンテナの中にいるかのように、自由にコマンドを実行できるようになる。もし /bin/bash が利用できないイメージの場合は、より基本的な /bin/sh を代わりに指定すれば良い。

このようにして取得したデバッグコンソールでは、コンテナ内部で発生している問題を診断するために必要なあらゆるコマンドを実行できる。例えば、アプリケーションのログファイルを確認したり、必要なファイルが存在するかどうかを検証したり、ネットワーク設定をチェックしたりと、問題に応じた様々な調査が可能となる。このインタラクティブなシェル環境があれば、原因究明のための大きな手がかりを得られるはずだ。このデバッグ手法は、Dockerコンテナが予期せず停止してしまい、その内部原因がわからない場合に非常に強力なツールとなる。システムエンジニアにとって、問題が発生した際にその原因を迅速に特定し、解決に導く能力は不可欠であり、この方法を習得することで、コンテナ環境でのトラブルシューティングスキルを大きく向上させることができるだろう。