章: 第2章: Docker Compose実践
docker compose up したら「DB接続失敗」でアプリがクラッシュした経験はありませんか?
これはよくあるトラブルです。depends_on: db を設定していても、DBのプロセスが起動しただけで「接続を受け付けられる状態」にはなっていない、という状況で起きます。
ヘルスチェックと condition: service_healthy を使うことで、DBが本当に接続を受け付けられる状態になってからアプリを起動できるようになります。
depends_onだけでは足りない理由
depends_on はコンテナの「起動順序」を制御しますが、「サービスが準備完了かどうか」は判定しません。MySQLはプロセスが起動してから実際に接続できるまでに数秒かかります。
ヘルスチェックを定義すると、Dockerがそのサービスの「健全性」を定期的に確認します。condition: service_healthy を組み合わせると、ヘルスチェックが成功してから依存サービスを起動できます。
depends_on の condition の違い
| condition | 意味 | 用途 |
service_started |
コンテナが起動した（デフォルト） | 起動順だけ制御したい場合 |
service_healthy |
ヘルスチェックが成功した | DBやAPIの準備完了を待つ場合 |
service_completed_successfully |
コンテナが正常終了した | 初期化スクリプトの完了を待つ場合 |
チェックポイント: DBへの接続が必要なサービスには
condition: service_healthyを使いましょう。service_startedだけでは接続タイミングの問題は解決しません。
実際の設定サンプル
services:
db:
image: mysql:8.4
healthcheck:
test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
interval: 10s
timeout: 5s
retries: 5
app:
depends_on:
db:
condition: service_healthy
interval: 10s で10秒ごとに確認し、retries: 5 で5回失敗するまで待機します。docker compose ps でヘルスチェックの状態（healthy/unhealthy/starting）を確認できます。
まとめ & 次のステップ
depends_onだけでは「サービスが準備完了か」は判定できないhealthcheckでサービスの準備状態を定期確認するcondition: service_healthyで健全性が確認できてから起動順を制御するdocker compose psでヘルスチェック状態を確認する
次回は「開発用と本番用の分離」を学びます。同じCompose設定を開発と本番で使い回すリスクと、安全に分離する方法を整理します。
