先に要点
- Docker Composeは、小規模な単一サーバー運用なら本番でも選択肢になります。ただし、雑に 「開発用のcompose.yamlをそのまま本番へ置く」 のは危険です。
- 判断基準は、単一サーバーで足りるか、止まったときに手動復旧で許されるか、バックアップとログを外に逃がせるか、更新手順を再現できるかです。
- 高可用性、オートスケール、複数台ローリング更新、厳しいSLAが必要なら、ComposeよりECS、Kubernetes、PaaS、マネージドDBを検討した方がよいです。
Docker Composeは、ローカル開発ではかなり便利です。
web、app、db、redis、nginx のような複数コンテナを、1つのYAMLでまとめて起動できます。
では、これを本番環境で使ってよいのでしょうか。結論から言うと、小規模サービスや社内向けツールなら、条件付きで使ってよいです。ただし、開発環境の延長のまま本番へ持ち込むのではなく、バックアップ、ログ、更新、復旧、セキュリティの運用を決めてから使う必要があります。
Docker公式ドキュメントでも、Compose定義をCI、ステージング、本番などの異なる環境で使えるとしつつ、本番向けには追加のComposeファイルで設定を分ける考え方が示されています。
この記事では、Docker Composeを本番で使うべきかを、小規模運用の現実に寄せて整理します。
コンテナそのものの基本から確認したい場合は、コンテナ、Docker、Dockerfile の用語ページもあわせて読むとつながりやすいです。
まず結論：単一サーバー前提なら選択肢になる
Docker Composeが向いているのは、左側のような運用です。逆に、右側のような場合はComposeだけで本番運用するのは苦しくなります。
Composeで本番運用できるか
Composeが向いている
Composeだけでは苦しい
そう考えると判断しやすいです。小さく始めるには強いですが、クラスタ管理や高可用性の仕組みを全部持っているわけではありません。厳しい要件の目安は SLA です。
Docker Composeで本番運用するメリット
小規模運用でComposeを使うメリットは、かなり分かりやすいです。
構成をファイルで残せる
どのサービスを、どのポートで、どの環境変数で動かすかをcompose.yamlにまとめられます。
再現しやすい
別サーバーやステージング環境でも、近い構成を作りやすくなります。
依存サービスをまとめやすい
小規模では学習コストが低い
KubernetesやECSより、単一サーバー運用の理解に集中しやすいです。
特に、受託開発や小規模サービスでは「サーバーに何が入っているか分からない」状態になりがちです。
Composeでサービス構成を明文化しておくと、引き継ぎや復旧のときに助かります。
Laravelアプリなら、Nginx、PHP-FPM、queue worker、scheduler、Redis、MySQLをComposeでまとめることがあります。ただし、MySQLまで同じサーバーのコンテナに入れるかは別問題です。データの重要度が高いなら、マネージドDBや外部DBを検討した方が安全な場面もあります。
本番で危険になるパターン
Docker Composeそのものが危険というより、開発用のノリを本番へ持ち込むと危険です。
| 危険な使い方 | 起きやすい問題 |
|---|---|
| ソースコードをbind mountする | 本番コードがホスト側から直接変わり、再現性や権限管理が崩れる |
| latestタグを使う | 再起動やpullのたびに別バージョンが動く可能性がある |
| .envを雑に置く | DBパスワード、APIキー、秘密鍵が漏えいしやすい |
| DBデータをコンテナ内だけに置く | コンテナ再作成や操作ミスでデータ消失につながる |
| ログをコンテナ内だけに残す | 障害調査や監査に必要なログが消える |
| 更新手順が手作業だけ | 誰が実行するかで結果が変わり、戻し方も曖昧になる |
| restart任せにする | 落ちては起きるだけで、原因調査や通知につながらない |
Docker公式の本番利用ガイドでも、本番向けにはアプリコードのvolume bindingを外す、ホスト側のポートを変える、ログの詳細度や外部サービス向け環境変数を変える、といった調整が必要だと整理されています。つまり、Composeを使うとしても、開発用と本番用の設定は分ける前提です。
小規模運用での判断基準
Docker Composeを本番で使うか迷ったら、次の質問に答えてみると判断しやすいです。
| 質問 | Composeで進めやすい答え | 別構成を考えたい答え |
|---|---|---|
| サーバーは何台必要？ | 1台で足りる | 複数台、冗長化、リージョン分散が必要 |
| 停止許容は？ | 短時間の手動復旧が許される | 停止が売上や契約違反に直結する |
| デプロイ頻度は？ | 週数回から月数回程度 | 1日に何度も無停止で出したい |
| DBはどこに置く？ | 外部DB、またはバックアップ設計済み | 重要データを無計画にローカルvolumeへ置く |
| 監視はある？ | 死活監視、ログ確認、通知がある | 落ちたら誰かが気づくまで放置 |
| 運用担当は？ | 少人数で構成を理解できる | 複数チームで権限や承認が必要 |
左側が多い
Compose本番運用は現実的
この表で左側が多ければ、Compose本番運用は現実的です。
右側が多い
別の構成へ寄せる
Composeで頑張るより、AWS ECS（手軽に始めるならECS Express Mode）、Kubernetes、Render、Fly.io、PaaS、マネージドDBなどへ寄せた方が楽になる可能性があります。
AWSで小さなサービスを複数動かす構成は、AWSで小さなWebサービスを複数運用するときの構成パターン でも整理しています。
本番用Composeで最低限分けたいこと
本番では、開発用Composeと同じファイルをそのまま使わない方が安全です。
よくある形は、共通設定に加えて本番用のoverrideを重ねる方法です。
docker compose -f compose.yaml -f compose.production.yaml up -d
本番用ファイルでは、少なくとも次を分けます。
- buildではなく、レジストリにpush済みのイメージを使う
- イメージタグを固定する
- アプリコードのbind mountを外す
- デバッグモードを無効にする
- 本番用の環境変数を使う
- 公開ポートを最小限にする
- restart policyを設定する
- ログの出し方とローテーションを決める
- 永続データのvolumeを明示する
- secretsや機密情報の扱いを分ける
楽ですが、長期運用では事故が出やすいです。ビルド済みイメージをレジストリに置き、本番ではそのタグをpullする形にすると、どのバージョンが動いているか説明しやすくなります。
volumeの基本やデータベースのデータを消さないための考え方は、Dockerのvolumeとは？DBデータを消さないための永続化の基本 で詳しく整理しています。
データベースをComposeに入れてよいか
小規模運用で一番悩むのが、DBを同じComposeに入れるかどうかです。
個人開発、検証環境、小さな社内ツールなら、MySQLやPostgreSQLを同じサーバーのComposeで動かすこともあります。
ただし、本番データを扱うなら、次を決めないまま始めるのは危険です。
売上、顧客情報、契約情報、決済状態、予約情報のような重要データを扱うなら、DBだけはマネージドサービスに逃がす判断もかなり現実的です。
Composeはアプリとワーカーをまとめるために使い、DBはRDSやCloud SQLのような外部サービスにする、という分け方です。
本番DBの扱いは、AI文脈の記事ですが 本番DBをAIに触らせていい？読み取り専用から始める判断基準 でも「本番データの影響が大きい場所」として整理しています。
デプロイ手順をどう作るか
Compose本番運用では、デプロイ手順を短く、戻しやすくするのが大事です。
たとえば、最低限は次のような流れにします。
Compose本番運用の最低限のデプロイ手順
- 1
- 2テストを通す
- 3コンテナレジストリへタグ付きでpushする
- 4本番サーバーで新しいタグをpullする
- 5docker compose config で設定を確認する
- 6docker compose up -d で反映する
- 7ヘルスチェック、ログ、主要画面を確認する
- 8問題があれば前のタグへ戻す
ビルドはCI側
本番はpullして起動だけ
本番サーバー上で直接ビルドすると、サーバーのCPUやメモリを使います。小さなVPSではビルド中にアプリが重くなったり、OOMが起きたりすることがあります。ビルドはCI側、本番はpullして起動だけ、という分け方の方が安定します。
注意
docker compose down を気軽に使わない
ネットワークやコンテナを落とすだけでなく、オプションや構成によっては思わぬ影響が出ます。データvolumeや永続化の扱いを理解しないまま実行すると危険です。
監視とログはComposeの外側にも置く
Composeでコンテナを起動できても、運用はそこで終わりではありません。
本番では、少なくとも次を確認できるようにします。
restart: always を設定しておけば安心、ではない
再起動して一時的に戻ることはありますが、原因が消えるわけではないからです。再起動回数、アプリログ、ホストのメトリクスを見られる状態にします。
CloudflareやCDNの前段を使う場合は、Cloudflareとは？DNS・CDN・WAFをどう使い分ける？ のように、DNS、CDN、WAF、オリジンサーバーの責任分担も見ておくと安心です。
セキュリティで見るポイント
Compose本番運用で見たいセキュリティ項目は、派手ではありません。
むしろ、基本を外さないことが大事です。
Composeはアプリを分けやすくしますが、コンテナに入れたから安全になるわけではありません。ホストOS、Docker Engine、コンテナイメージ、アプリ、ネットワーク、秘密情報の管理まで含めて本番運用です。
Composeをやめた方がいいサイン
最初はComposeでよくても、途中で限界が来ることがあります。
次のサインが増えてきたら、別の運用方式を検討します。
ここまで来たら、Composeが悪いのではなく、サービスの段階が変わったということです。ECS、Kubernetes、PaaS、マネージドDB、オブジェクトストレージ、CDN、監視サービスなどへ役割を分ける方が、結果的に運用が楽になることがあります。
よくある誤解
禁止ではありません
Docker Composeは本番禁止？
Docker公式にも本番でComposeを使うガイドがあります。ただし、本番向けの設定分離、永続データ、ログ、更新手順、セキュリティを考えずに使うのは危険です。
そうとも限りません
Kubernetesを使えば必ず本番向き？
Kubernetesは強力ですが、学習コスト、監視、アップグレード、マニフェスト管理、権限管理が増えます。小規模サービスでは、Kubernetesを入れたことで運用が重くなることもあります。
いります
コンテナならバックアップはいらない？
コンテナイメージは作り直せても、DBデータ、アップロードファイル、設定、秘密情報、ログは別です。何を再生成できて、何を失うと困るのかを分けて考えます。
十分ではありません
compose.yamlがあれば引き継ぎは十分？
起動方法は分かっても、バックアップ、復旧、デプロイ、障害時連絡、外部サービス契約、DNS、証明書、環境変数の意味までは分かりません。運用手順書も必要です。
小規模本番運用チェックリスト
最後に、Docker Composeを本番で使う前のチェックリストをまとめます。
このチェックを通せるなら、小規模な本番運用でDocker Composeを使うのは十分現実的です。 逆に、バックアップ、復旧、監視、更新のどれかを説明できないなら、Composeかどうか以前に本番運用の準備が足りません。
Docker Compose本番運用のよくある質問
Q. 公式は本番利用を非推奨にしていますか？
A. 明確な非推奨ではありませんが、本番では Swarm モードや Kubernetes が推奨 と案内されています。単一サーバーで完結する小規模サービス なら Compose も十分という見方です。
Q. どんなサービス規模までなら Compose で大丈夫ですか？
A. 単一サーバー、トラフィック中程度、ユーザー数千〜数万、無停止デプロイ不要 のサービスなら Compose で十分です。複数サーバーが必要、無停止デプロイ必須、になったら Kubernetes や ECS に移行します。
Q. データベースを Compose に入れて良いですか？
A. 個人開発・検証なら OK、業務本番なら推奨しません。データのバックアップ・冗長化・パフォーマンス は専用 DB サービス(RDS、Cloud SQL、Aurora)の方が安心です。
Q. Compose で無停止デプロイは可能ですか？
A. 標準では難しいです。ローリングデプロイ、Blue/Green、CDN フェイルオーバー などの工夫が必要で、Kubernetes や ECS が標準でサポートする機能を自前で実装する必要があります。
Q. 監視はどうしますか？
A. Compose の外側に Datadog、Grafana、UptimeRobot などを置きます。コンテナ内ログを stdout に出力 → host で Fluentd や Promtail で収集 → Loki や CloudWatch へ集約 が定番です。
Q. Compose から Kubernetes に移行するコストは？
A. 学習に2〜4週間、移行作業に1〜3か月が目安です。Helm Chart の作成、ネットワーク設計、Ingress 設定、永続ストレージ、シークレット管理、などを段階的に進めます。
Q. 個人開発で Kubernetes より Compose を選ぶ理由は？
A. 学習コストが圧倒的に低い、運用負荷が小さい、コストも低い、動かす ことに集中できる、です。Kubernetes が本当に必要になってから学ぶ 戦略は、個人開発では合理的です。
まとめ
Docker Composeは、本番で絶対に使ってはいけない道具ではありません。
小規模サービス、単一サーバー、手動復旧が許される範囲、構成をシンプルに保ちたい場面では、かなり実用的な選択肢になります。
ただし、Composeは高可用性クラスタやフルマネージド運用の代わりではありません。
本番で使うなら、開発用設定をそのまま持ち込まず、イメージ固定、設定分離、バックアップ、ログ、監視、デプロイ手順、ロールバックを先に決めます。
判断の軸は、「Docker Composeが本番向きか」ではなく、「このサービスの停止許容、データ重要度、運用体制にComposeが合っているか」です。
小さく始めるならCompose、止められない・増やしたい・任せたいならECSやKubernetes、PaaS、マネージドDBへ寄せる。そう分けて考えると、かなり迷いにくくなります。
参考情報
- Docker Docs: Use Compose in production
- Docker Docs: Docker Compose
- Docker Docs: Why use Compose?