Summary
この文書の要点
- 常時必要なサービスと必要時だけ起動するサービスを分ける。
- フロントエンドのホットリロードはボリューム設計の影響を受ける。
- 依存ディレクトリ、ビルド成果物、ソース同期を分け、ホストとコンテナのI/Oを減らす。
- 初回セットアップと日常起動を別コマンドにし、毎回重い処理を走らせない。
どこが設計の難所か
すべてのサービスを常に起動するDocker Composeは、便利な反面、メモリ消費や待ち時間が大きくなります。フロントエンドのファイル監視が遅い、DBが起動する前にAPIが落ちる、初期データが毎回壊れるといった問題も起きます。
開発者のOSやマシン性能は同じではありません。Docker上で完全に統一したい部分と、ホスト側で動かした方が速い部分を分ける判断が必要です。特にReactやViteの開発サーバーは、ホスト実行の方が快適な場合があります。
Docker Composeは環境差を減らせますが、何でもコンテナに入れると起動もテストも遅くなります。特にLaravel、React、MySQLの組み合わせでは、vendor、node_modules、DBデータ、Viteの監視が速度に影響します。
境界をどう切るか
Composeでは、DB、メール確認、ストレージ代替など共有したい依存サービスを中心に置きます。APIはコンテナ、フロントはホスト、または両方コンテナという選択肢をREADMEで明示し、プロファイルで重いサービスを分けます。
設計では、コンテナを本番に近づける部分と、開発体験を速くする部分を分けます。アプリコードは同期しつつ、依存ディレクトリはnamed volumeへ逃がし、DB初期化は明示コマンドにします。
実装で効く細部
Dockerfileでは依存インストールとアプリコードをレイヤー分離し、`node_modules`やvendorの扱いを明確にします。DBにはヘルスチェックを設定し、APIは準備完了を待って起動します。初期化SQL、マイグレーション、シードは別コマンドにします。
Compose定義では、PHP、Node、DB、メール確認、オブジェクトストレージなどを分け、日常的に必要なものだけを起動できるprofileを使います。Dockerfileは依存インストール層をキャッシュし、ソース変更で毎回再ビルドされないようにします。
- node_modulesやvendorをホスト同期対象から外し、コンテナ内volumeで保持する。
- DB migrationとseedは起動時自動ではなく、明示的なmake taskやnpm scriptにする。
- Viteやファイル監視はpolling設定を環境別に切り替え、CPU使用率を確認する。
壊れ方を観測する
検証では、クリーン環境での初回起動時間、2回目以降の起動時間、ホットリロード速度、DB再作成手順を確認します。新しい開発者がREADMEだけで起動できるかも重要なテストです。
検証では、初回セットアップ時間、2回目以降の起動時間、ホットリロード時間、テスト実行時間を測ります。感覚ではなく数値で見ると、どのvolumeや監視設定が効いているかを判断できます。
捨てた選択肢とトレードオフ
ホスト実行を許すと環境差は増えます。すべてコンテナ化すると再現性は上がりますが速度が落ちることがあります。チームの優先順位に合わせ、標準手順と高速手順を分けて用意するのが現実的です。
本番と完全に同じコンテナにすると安心感はありますが、開発速度が落ちることがあります。逆に速さを優先してホスト依存に寄せすぎると、環境差が戻ります。日常作業の速さと本番差分の小ささを別軸で調整する必要があります。
現場に残す判断軸
Docker Compose開発環境は、全部を閉じ込めることが目的ではありません。再現性が必要な依存サービスを固定し、日々触る部分は速く動く形を選ぶことで、継続的に使える環境になります。
Docker Compose開発環境は、動けば完成ではありません。起動、変更反映、テスト、リセットの速度を設計対象にすると、チームの日常的な摩擦を大きく減らせます。
