004 - Service Startup Strategy (Healthchecks)

Context

本プロジェクトをVirtualBox（特に古いハードウェアやI/Oが遅い環境）で実行する際、以下の問題が頻発しています。

1. Race Condition: docker-compose up 実行時、MariaDBコンテナが Running 状態になっても、内部での初期化（mysql_install_db等）が完了しておらず、接続を受け付けられない。
2. Restart Loop: WordPressコンテナが即座にデータベース接続を試みて失敗し、終了（Crash）と再起動を繰り返す。

これまで srcs/requirements/wordpress/tools/setup.sh 内で sleep 10 などを入れて対策していましたが、環境依存性が高く、確実な解決策ではありませんでした。

Decision

Docker Composeの Healthcheck機能 を導入し、依存関係制御を厳格化します。

変更点

1. MariaDB / Redis: healthcheck ブロックを追加し、サービスが実際にリクエストを処理できるかを定期的に監視する。
2. WordPress: depends_on に condition: service_healthy を指定し、データベースが "Healthy" になるまでコンテナ起動（Entrypoint実行）を待機させる。

概念図 (Startup Sequence)

Before (Race Condition)

MariaDBの起動中(Init)にWordPressが接続しに行き、失敗する。

After (Healthcheck Strategy)

DockerがMariaDBの準備完了を確認してからWordPressを起動する。

Alternatives Considered

案	内容	理由 (Why not)
Fixed Sleep	起動スクリプトで sleep 20 する	環境によって待ち時間が不足したり過剰だったりする。スマートではない。
Wait-for-it	wait-for-it.sh 等のツールを使う	別途スクリプトのインストールが必要。Docker Infrastructureの「最小構成」の美学に反する。
App Retry	アプリ側で接続エラーを捕捉しリトライ	各アプリケーション（WordPress, Adminer等）ごとの対応が必要で保守性が低い。

Consequences

• メリット: 環境に依存せず、常に「正しい順序」でサービスが立ち上がるようになる。再起動ループがなくなる。
• デメリット: docker-compose.yml の記述量が増える。初回起動時、WordPressが立ち上がるまでの「見かけ上の待ち時間」が増える（裏でDBを待っているため）。

Production Notes

本番環境（Kubernetes等）では、これに相当する Liveness Probe (死活監視) と Readiness Probe (準備完了監視) が標準的に使用されます。今回のHealthcheck導入は、それに準じたモダンな設計思想です。