Docker Composeで環境変数を使用するにはどうすればいいですか？

インラインの値には'environment'キーを使用するか、.envファイルから読み込むには'env_file'を使用します。例：environment: - DATABASE_URL=postgres://user:pass@db:5432/mydb。composeファイル内で${VARIABLE_NAME}構文を使用してホスト環境変数を参照することもできます。機密値はコミットせず、.envファイルを使用して.gitignoreに追加してください。

アプリのコンテナにデータベースの準備完了を待たせるにはどうすればいいですか？

'depends_on'と'condition: service_healthy'をデータベースサービスのヘルスチェックと組み合わせて使用します。PostgreSQLの例：healthcheck: { test: ['CMD-SHELL', 'pg_isready -U postgres'], interval: 5s, timeout: 5s, retries: 5 }。これにより、データベースが完全に初期化される前にアプリが起動した際の接続エラーを防止します。

Docker Composeジェネレーター — 無料オンラインツール

サービスを選択

プロジェクト名

ネットワーク名

Docker Composeとは？

Docker Composeは、マルチコンテナアプリケーションを定義し実行するためのツールです。単一の docker-compose.yml ファイルで、Webサーバー、データベース、キャッシュなどのサービスと、それらの接続・通信方法を含むアプリケーションスタック全体を定義します。docker-compose up コマンド一つですべてが起動します。

Docker Composeはローカル開発環境、CI/CDパイプライン、さらには小規模な本番デプロイメントに最適です。すべての開発者が同じ環境設定を使用することを保証し、「自分のマシンでは動く」問題を解消します。

一般的なDocker Composeスタック

Node.js + PostgreSQL + Redis： リレーショナルストレージとキャッシングを備えた典型的なREST APIバックエンド
Python + MySQL： DjangoまたはFlask Webアプリケーションによく使用
Nginx + Node.js： Node.jsアプリケーションの前にNginxをリバースプロキシとして配置
フルスタック：Nginx + Node.js + PostgreSQL + Redis： リバースプロキシ、API、データベース、キャッシュを備えた本番環境に近いセットアップ

Docker Composeのボリュームとネットワークのヒント

コンテナの再起動間でデータを保持するために、データベースデータには常に名前付きボリュームを使用する
サービス間通信にはカスタムブリッジネットワークを使用 — サービスはサービス名で互いに到達可能
機密情報（パスワード、APIキー）にはcomposeファイルにハードコーディングせず、.env ファイルを使用
本番サービスには障害時の自動再起動のために restart: unless-stopped を設定
データベースの準備完了まで依存サービスを遅延させるには healthcheck を使用

本番環境のためのDocker Composeベストプラクティス

Docker Composeはローカル開発やシンプルなデプロイメントには優れていますが、開発から本番に移行するにはセキュリティ、パフォーマンス、信頼性の慎重な検討が必要です。

セキュリティ強化

シークレットのハードコーディング禁止： docker-compose.ymlに直接パスワードを入れる代わりに、env_fileやDockerシークレットを使用してください。composeファイルは通常Gitにコミットされるため、ハードコードされたすべての認証情報が露出します。
イメージバージョンの固定： node:latestの代わりにnode:20.11-alpineを使用してください。latestタグは予期せず変更され、ビルドが壊れたり脆弱性が導入される可能性があります。
読み取り専用ファイルシステム： ディスクに書き込む必要がないコンテナにはread_only: trueを追加してください。コンテナ侵害の影響範囲を制限します。
ケイパビリティの削除： cap_drop: [ALL]を使用し、cap_addで必要なケイパビリティのみを選択的に追加してください。

パフォーマンスと信頼性

リソース制限： 単一のコンテナがすべてのホストリソースを消費するのを防ぐため、常にmem_limitとcpusを設定してください。制限のないメモリリークのあるコンテナはサーバー全体をクラッシュさせる可能性があります。
ヘルスチェック： Dockerが異常なコンテナを自動的に検出して再起動できるように、各サービスにhealthcheckを定義してください。
再起動ポリシー： 本番サービスにはrestart: unless-stoppedを使用してください。サーバーの再起動に耐えながら、メンテナンスのための手動停止も可能です。
ログ設定： コンテナログがディスクスペースを使い果たすのを防ぐため、logging.options.max-sizeとmax-fileを設定してください。

Docker Composeに関するよくある質問

docker compose upとdocker compose startの違いは何ですか？

docker compose up はコンテナをゼロから作成して起動し、必要に応じてイメージをプルまたはビルドします。docker compose start は以前作成されて停止されたコンテナのみを再起動します — 新しいコンテナは作成できません。バックグラウンドモードで起動するには docker compose up -d を使用します。Dockerfileが変更された場合にイメージの再ビルドを強制するには --build を追加します。

Docker Composeでサービス同士はどのように通信しますか？

同じDocker Composeネットワーク上のサービスは、サービス名をホスト名として使用して互いに到達できます。データベースサービスの名前が db の場合、アプリケーションは localhost:5432 の代わりに db:5432 に接続します。Docker Composeは同じcomposeファイルで定義されたすべてのサービスに対して、デフォルトのブリッジネットワークを自動的に作成します。より詳細な制御のためにカスタム名前付きネットワークを作成することもできます。

コンテナの再起動間でデータベースデータを保持するにはどうすればいいですか？

composeファイルで名前付きボリュームを使用します。ボリュームがない場合、コンテナ内のすべてのデータはコンテナが停止すると失われます。サービスの下にボリュームを定義します：volumes: - postgres_data:/var/lib/postgresql/data、次にトップレベルで宣言します：volumes: postgres_data:。名前付きボリュームはDockerによって管理され、docker compose down でも保持されます — docker compose down -v のみがボリュームを削除します。

Docker Composeのrestart: unless-stoppedとはどういう意味ですか？

restart: unless-stopped は、コンテナがクラッシュした場合やDockerデーモンが再起動した場合（サーバーのリブート後など）にDockerが自動的にコンテナを再起動しますが、docker compose stop で明示的に停止したコンテナは再起動しないことを意味します。これは本番サービスに推奨される設定です。その他のオプション：no（再起動しない）、always（明示的な停止後も常に再起動）、on-failure（非ゼロの終了コード時のみ再起動）。