HOME > 技術ドキュメント > Docker Composeで作る本番向けWebアプリ環境

Docker Composeで作る本番向けWebアプリ環境

執筆：株式会社エスロジカル（Webシステム受託開発・インフラ構築・運用改善）

Docker Compose は開発環境だけでなく、小〜中規模の本番環境にも十分活用できます。 Kubernetes の前段として使うことも多く、「まず Compose で動かして、必要になったら Kubernetes へ」 という段階的なアプローチが実務では効果的です。
本記事では、開発環境と本番環境の違いを踏まえた Docker Compose 本番設計のポイントを解説します。

1. 開発環境と本番環境の設計の差

項目	開発環境	本番環境
コードのマウント	ホストのソースをコンテナにバインドマウント（ホットリロード）	イメージにコードを COPY（イミュータブル）
DB パスワード	環境変数に直書きでも可	Docker Secrets または安全な手段で渡す
SSL/TLS	なし / mkcert でローカル証明書	本番証明書が必須
リスタートポリシー	なし（手動再起動）	restart: unless-stopped または on-failure
リソース制限	不要	CPU・メモリ上限を設定（暴走防止）
ログ	コンソール出力をそのまま確認	ログドライバー設定・ローテーション必須

2. 本番向け compose.yaml の設計原則

• イメージは固定タグを指定：image: myapp:latest ではなく image: myapp:v1.2.3 のようにバージョンを固定し、意図しない更新を防ぐ。
• 複数ファイルで環境を分ける：compose.yaml（共通）と compose.prod.yaml（本番上書き）に分割し、docker compose -f compose.yaml -f compose.prod.yaml up で起動する。
• リスタートポリシー：全サービスに restart: unless-stopped を設定し、サーバー再起動後に自動で起動するようにする。
• ネットワーク分離：フロントエンド（Nginx）は外部ネットワーク接続を許可し、DB・内部サービスは内部ネットワークのみに隔離する。

3. シークレット管理

本番での安全なシークレット管理方法：

• Docker Secrets（Swarm モード）：シークレットを暗号化して保存・コンテナに安全に渡す。Swarm クラスタでの利用が前提。
• .env ファイルをサーバー上にのみ配置：Git には .env.example のみコミットし、実際の値はサーバー上の .env ファイルに記述する。.gitignore に .env を追加することを忘れずに。
• クラウドのシークレット管理サービス：AWS Secrets Manager・Azure Key Vault などを利用して、アプリ起動時に取得する方法も有効。

4. SSL/TLS 設定：Nginx + 証明書の組み合わせ

Docker Compose 構成で HTTPS を提供する場合、Nginx コンテナで SSL ターミネーションを行うのが一般的です。

• 証明書ファイルのマウント：SSL 証明書と秘密鍵をホストのボリュームとして Nginx コンテナにマウントする（volumes: - /etc/ssl/myapp:/etc/nginx/ssl:ro）。
• Certbot + Nginx の組み合わせ：certbot コンテナを定期実行して Let's Encrypt 証明書を自動更新する構成も一般的。ただし有効期間 47 日化に伴い、更新失敗の監視が重要になります。
• 有料 SSL 証明書の利用：企業サイト・EC・OV/EV 証明書が必要な場合は有料証明書を取得してマウントする。CSR 作成・インストール手順を参照。

SSL証明書の一覧・購入はこちら /  SSL証明書 FAQ

5. ヘルスチェック設計

Docker の healthcheck を設定することで、コンテナが起動していてもアプリが正常でない状態を検知できます。 また、依存サービス（DB）の起動完了を待ってアプリを起動するために使えます。

• DB のヘルスチェック：mysqladmin ping または pg_isready を healthcheck に設定する。
• アプリのヘルスチェック：アプリ内に /health エンドポイントを用意し、curl -f http://localhost:8080/health を healthcheck にする。
• depends_on の condition：depends_on: db: condition: service_healthy で DB ヘルスチェック完了を待ってアプリを起動する。

6. ログ設計

• ログドライバー：デフォルトの json-file ドライバーを使い、max-size: "50m"・max-file: "5" でローテーションを設定する。設定なしではログがディスクを圧迫します。
• アプリは stdout/stderr に出力：コンテナは標準出力にログを書き、Docker がファイル管理する。ファイルパスをハードコードしない。
• 外部ログ集約：規模が大きくなったら fluentd や Loki にログを転送し、Grafana で可視化する。

7. リソース制限とセキュリティ強化

• CPU・メモリ上限：1 つのコンテナが暴走してホスト全体に影響しないよう、deploy.resources.limits でリソース上限を設定する。
• read_only ファイルシステム：可能なコンテナは read_only: true にし、不正な書き込みを防ぐ。
• capabilities の削減：cap_drop: [ALL] で不要な Linux ケーパビリティを削除する。
• 非 root ユーザーで実行：Dockerfile で USER appuser を指定し、root での実行を避ける。
• イメージのスキャン：Trivy などのツールで本番使用イメージの CVE スキャンを CI に組み込む。

8. Docker Compose vs Kubernetes：移行の判断

条件	推奨
単一サーバーで動かしている	Docker Compose で十分
複数サーバーへのスケールが必要	Kubernetes または Docker Swarm を検討
ローリングアップデートが必要	Kubernetes を検討（Compose でも工夫次第で可能）
運用チームが小さい（1〜3人）	Kubernetes のオーバーヘッドは大きい。Compose の方が現実的
クラウドのマネージド Kubernetes（EKS / AKS）を使える	インフラ管理の負荷を軽減できる場合は Kubernetes も選択肢に

本番用 Docker Compose 設計チェックリスト

• □ イメージに固定バージョンタグを使用している
• □ シークレット（パスワード・API キー）を Git にコミットしていない
• □ 全サービスに restart ポリシーを設定している
• □ SSL/TLS を Nginx コンテナで終端している
• □ DB にヘルスチェックを設定している
• □ ログのローテーション設定がある
• □ リソース制限（CPU・メモリ）を設定している
• □ 非 root ユーザーでコンテナを実行している

関連ドキュメント

• Docker 入門（Ubuntu 24.04 LTS）
• Docker Compose 実践（Nginx + PHP-FPM + MySQL 構成）
• Kubernetes 入門（k3s / Ubuntu 24.04 LTS）

← 技術ドキュメント一覧へ戻る