docker composeでコンテナが起動しない：ログの読み方

レン

コンテナを起動したのに、すぐ止まってしまう。エラーも見えないんだけど…

プロクラ

すぐ止まるということは、起動はしたけれど中のプログラムが終了したということだよ。理由は必ずログに残っている。まず、そこを読むところから始めよう。

状態とログを見る

起動しないときは、まず状態とログを見ます。設定を読み直す前にここを見る理由は、失敗の理由がほぼ必ず記録されているからです。推測で設定を触り始めると、正しかった箇所まで壊すことがあります。

• docker compose ps で、状態と終了コードを見る
• docker compose logs でログを見る（止まったコンテナの分も残っている）
• サービス名を指定すれば、そのコンテナのログだけに絞れる
• 起動直後の数行に、原因が書かれていることが多い

プロクラ

終了コードも手掛かりになるよ。0なら正常終了、それ以外なら異常。特定の値には決まった意味があるものもあるので、ログと合わせて見よう。

型1：設定ファイルの誤り

• 書式の誤りがあれば、起動する前にエラーが出る
• インデントのずれが原因のことが多い（空白とタブの混在に注意）
• 設定の内容を確認するコマンドで、解釈された結果を表示できる
• 変数が展開された後の姿を見ると、思い違いに気づける

プロクラ

3つめが便利だよ。自分が書いたつもりの設定と、実際に解釈された設定を比べられる。環境変数が空のまま渡っていた、というのはここで見つかる。

型2：ポートの衝突

プロクラ

「address already in use」が出たら、そのポートを既に何かが使っている。ホスト側で動いているWebサーバーと、コンテナが同じ番号を取り合う、というのが定番だね。

• ss -tulpn で、そのポートを誰が使っているか確認する
• 以前のコンテナが残っている場合もある
• 公開するポート番号を変えるか、既存のものを止める
• 前段で振り分ける構成にすれば、衝突自体を避けられる

型3：権限とファイル

• ホストのディレクトリを共有している場合、その所有者が合っていない
• コンテナの中のユーザーと、ホスト側の所有者の対応を確認する
• 共有元のディレクトリが存在しないと、勝手に作られて空になることがある
• 設定ファイルを1ファイルだけ共有する場合、パスの書き間違いに注意

型4：依存するものが準備できていない

プロクラ

アプリがデータベースより先に起動して、接続に失敗して終了する。これは非常に多い型だよ。起動の順序を指定しても、相手が「受け付けられる状態」になったかまでは保証されない。

• 起動順の指定は、あくまで開始の順序でしかない
• 相手の準備完了を判定する仕組みを併用する
• アプリ側で、接続に失敗したら少し待って再試行する作りにする
• 後者のほうが確実で、本番でも扱いやすい

レン

すぐ止まる＝中身が終了した、なんだね。まずログを読む。