Dockerコンテナのトラブルシューティング：一般的な起動の問題と解決策

Dockerコンテナの起動は、理想的にはスムーズに進むはずですが、現実はしばしば障害にぶつかります。コンテナ化の初心者であっても、経験豊富な開発者であっても、起動しない、すぐに終了する、または予期しない動作をするコンテナに直面するのはよくある課題です。このガイドは、Dockerアプリケーションの実行中に遭遇する最も頻繁な起動障害を診断し、解決するための技術的なプレイブックとして役立ちます。

コンテナが失敗する理由を理解することが、それを修正するための第一歩です。ポートの競合、不正なコマンド実行、依存関係の欠落、ボリュームやネットワークに関連する問題など、一般的な原因を体系的に探求し、スムーズなコンテナ操作を復元するために不可欠なコマンドとロジックを提供します。

必須の最初のステップ：診断

特定のエラータイプに飛び込む前に、基本的な診断コマンドを習得することが重要です。これらのツールは、問題を特定するために必要な即時の証拠を提供します。

1. コンテナステータスの確認

常に、docker ps（実行中のコンテナ用）またはdocker ps -a（停止中のコンテナを含むすべてのコンテナ用）を使用して、コンテナの現在の状態を確認することから始めます。コンテナがExitedステータスを表示している場合、コンテナ内のプロセスが起動直後に終了したことを意味します。

docker ps -a
# STATUS列とPORTS列を確認する

2. コンテナログの確認

すぐに終了するコンテナの場合、ログに原因があることがほとんどです。docker logsコマンドは、コンテナのメインプロセスからの標準出力と標準エラー出力を取得します。

# <container_id_or_name> を実際のIDまたは名前に置き換えてください
docker logs <container_id_or_name>

# ライブログを追跡するには -f を、最後のN行を表示するには --tail N を使用します
docker logs --tail 50 <container_id_or_name>

3. コンテナ詳細の検査

docker inspectコマンドは、Stateオブジェクト、設定詳細、最後の終了コードなど、多数の低レベル情報を提供します。

docker inspect <container_id_or_name> | grep -A 10 State

ゼロ以外の終了コード（例：OOMキルではExitCode: 137、アプリケーションエラーではExitCode: 1）は、根本的な問題に直接つながることがよくあります。

一般的な起動問題1：ポートの競合

これは、ホストポートをコンテナポートにマッピングする（-pフラグ）際に最も頻繁に発生するエラーかもしれません。

問題

ホストのポート8080をコンテナのポート80にマッピングしてコンテナを起動しようとしたときに、別のサービス（別のコンテナまたはローカルアプリケーション）がすでにホストポート8080を使用している場合、Dockerはそのポートをバインドできず、コンテナは終了するか、起動に失敗する可能性があります。

診断

これが発生すると、起動コマンドは通常すぐに失敗し、ログにはバインドエラーまたはアドレスが既に使用されていますといったメッセージが表示されることがあります。

解決策

ホストポートの変更： コンテナポートを、ホストマシン上の別の未使用ポートにマッピングします。
```bash
# 元の（失敗した）コマンド：
docker run -d -p 8080:80 my-web-app

解決策（代わりに8081を使用）：

docker run -d -p 8081:80 my-web-app
`` 2. **競合の特定：** オペレーティングシステムのツールを使用して、どのプロセスがポートを使用しているかを見つけます。 * **Linux/macOS：**sudo lsof -i :8080またはsudo netstat -tuln | grep 8080* **Windows (PowerShell)：**Get-NetTCPConnection -LocalPort 8080`

一般的な起動問題2：ENTRYPOINTまたはCMDの誤り

コンテナは、DockerfileのENTRYPOINTとCMDで定義された特定のフォアグラウンドプロセスを実行するように設計されています。このコマンドが間違っていると、コンテナはすぐに終了します。

問題

イメージで指定された実行可能ファイルがスペルミスされているか、存在しない。
シェルスクリプトの依存関係が欠落している（例：イメージにPythonがインストールされていないのにPythonスクリプトを実行しようとしている）。
コマンドに必要な引数が提供されなかった。

診断

docker logsを確認します。多くの場合、command not found、No such file or directory、または特定のアプケーション起動例外のようなエラーが表示されます。

解決策

インタラクティブモードでのテスト： デフォルトのコマンドをオーバーライドして、コンテナ内でシェルセッションを実行し、実行パスを手動でテストします。
```bash
# bashのような既知のシェルを使用して、イメージをインタラクティブに実行します
docker run -it --entrypoint /bin/bash my-failing-image

コンテナ内に入ったら、パスを確認し、目的の起動コマンドを手動で実行します。

`` 2. **Dockerfileの確認：** イメージのDockerfileのCMDおよびENTRYPOINT行を確認します。必要に応じてパスが絶対パスであることを確認するか、正しいexec形式（["executable", "param1"]`）を使用していることを確認します。

ベストプラクティス： 存続させる必要があるコンテナ（Webサーバーなど）を実行する場合、実行するコマンドがフォアグラウンドで実行されることを確認してください。プロセスがすぐにバックグラウンド（デーモン化）にフォークする場合、Dockerはそのコンテナの主なタスクが完了したとみなし、停止します。

一般的な起動問題3：ボリュームマウントエラー

永続データは通常、Dockerボリュームまたはバインドマウント（-vフラグ）を介して処理されます。アプリケーションがそのデータに大きく依存している場合、ここでの設定ミスは起動を妨げる可能性があります。

問題

バインドマウントの権限： コンテナ内のユーザーが、ホストからマウントされているディレクトリに対する読み取り/書き込み権限を持っていない。
ホストディレクトリの欠落（バインドマウント）： バインドマウントを使用する際に、ホスト上のソースディレクトリが存在しない場合、Dockerはサイレントに失敗するか、予期しない動作をすることがあります（ただし、名前付きボリュームは作成をよりうまく処理します）。

診断

ログにI/Oエラーや権限拒否エラーが表示される場合、ボリュームの問題を疑ってください。

解決策

権限の確認： コンテナ内でプロセスを実行しているUID/GIDが、ホスト上のマウントされたディレクトリの所有権と一致していることを確認するか、ディレクトリに世界読み取り/書き込み権限があることを確認します（例：chmod 777 /path/on/host）。
名前付きボリュームの使用： ホストファイルシステムへの直接アクセスを必要としない永続データについては、名前付きボリュームの方が一般的に安全でポータブルです。
bash docker volume create my_app_data docker run -d -v my_app_data:/var/lib/app my-app

一般的な起動問題4：イメージのプルまたはビルドの失敗

イメージ自体が利用できないか破損しているためにコンテナがまったく起動しない場合。

問題

指定されたイメージ名またはタグがレジストリ（例：Docker Hub）に存在しない。
ネットワーク接続の問題により、イメージのプルができない。
ビルドプロセスが失敗し、不完全またはタグ付けされていないローカルイメージが生成された。

解決策

タグの確認： スペルとタグのバージョン（myimage:latestとmyimage:v1.0）を再確認します。
明示的にプル： ネットワーク/レジストリの問題を分離するために、手動でイメージをプルしてみます。
bash docker pull myimage:mytag
ビルドログの確認： カスタムイメージを使用している場合は、docker build .を実行し、エラーなしで正常に完了することを確認してから実行を試みます。

高度なトラブルシューティング：リソース制限

コンテナが起動してすぐに停止する場合、特に高負荷下では、リソース不足のためにキルされた可能性があります。

OOM Killer

最も一般的なリソース制限による終了は、Out-Of-Memory（OOM）キラーです。コンテナが（--memoryで明示的に設定されたか、ホストシステムの制約によって暗黙的に制限された）割り当てられたメモリよりも多くのRAMを使用しようとすると、カーネルがそれを終了させることがあります。

診断： docker inspectを介してコンテナの終了コードを確認します。終了コード137は、コンテナが外部から（通常はOOMにより）キルされたことを強く示唆します。

解決策： Docker Desktopに割り当てられたメモリを増やすか、可能であればコンテナのメモリ使用量を明示的に制限して、ホスト上の利用可能なリソースを超えないようにします。

# この特定のコンテナに1ギガバイトのRAMを割り当てます
docker run -d --memory="1g" my-heavy-app

まとめと次のステップ

Dockerの起動問題のトラブルシューティングは、明確な診断パスに従います：ステータスチェック -> ログレビュー -> 検査 -> 分離。 ほとんどの失敗は、環境の不一致（ポート、権限）または不正なプロセス実行（CMD/ENTRYPOINT）に起因します。docker ps -a、docker logs、docker inspectを体系的に使用することで、起動失敗から解決されたコンテナまでを迅速にナビゲートできます。

それでも解決しない場合は、コンテナを完全に削除（docker rm）し、コマンドを再度実行してみてください。必要であれば、複雑さを軽減（ボリュームやネットワーク設定の削除など）して、ベースイメージが正しく機能することを確認することから始めると良いでしょう。