Docker Composeは本番で使っていい？小規模運用の判断基準と注意点

Docker Composeは、ローカル開発ではかなり便利です。
web、app、db、redis、nginx のような複数コンテナを、1つのYAMLでまとめて起動できます。

では、これを本番環境で使ってよいのでしょうか。
結論から言うと、小規模サービスや社内向けツールなら、条件付きで使ってよいです。ただし、開発環境の延長のまま本番へ持ち込むのではなく、バックアップ、ログ、更新、復旧、セキュリティの運用を決めてから使う必要があります。

Docker公式ドキュメントでも、Compose定義をCI、ステージング、本番などの異なる環境で使えるとしつつ、本番向けには追加のComposeファイルで設定を分ける考え方が示されています。
この記事では、Docker Composeを本番で使うべきかを、小規模運用の現実に寄せて整理します。

コンテナそのものの基本から確認したい場合は、コンテナ、Docker、Dockerfile の用語ページもあわせて読むとつながりやすいです。

まず結論：単一サーバー前提なら選択肢になる

Docker Composeが向いているのは、次のような運用です。

• 1台のVPSや専用サーバーで動かす小規模Webサービス
• 個人開発や小さな社内ツール
• アクセスが急増しにくい業務システム
• 停止時に数分から数十分の手動対応が許されるサービス
• インフラ担当者が少なく、Kubernetesを運用するほどではない案件
• アプリ、Nginx、Redis、ジョブワーカーなどを同じサーバーで管理したい案件

逆に、次のような場合はComposeだけで本番運用するのは苦しくなります。

• 複数台構成が前提
• 自動スケールが必要
• 無停止デプロイやローリング更新が必須
• 障害時に自動で別ノードへ逃がしたい
• 24時間365日の厳しいSLAがある
• データベースの高可用性や自動バックアップが契約上重要
• チームで権限、監査、リリース承認を細かく管理したい

Composeは「複数コンテナを1台で分かりやすく動かす道具」と考えると判断しやすいです。
小さく始めるには強いですが、クラスタ管理や高可用性の仕組みを全部持っているわけではありません。

Docker Composeで本番運用するメリット

小規模運用でComposeを使うメリットは、かなり分かりやすいです。

特に、受託開発や小規模サービスでは「サーバーに何が入っているか分からない」状態になりがちです。
Composeでサービス構成を明文化しておくと、引き継ぎや復旧のときに助かります。

たとえば、Laravelアプリなら、Nginx、PHP-FPM、queue worker、scheduler、Redis、MySQLをComposeでまとめることがあります。
ただし、MySQLまで同じサーバーのコンテナに入れるかは別問題です。データの重要度が高いなら、マネージドDBや外部DBを検討した方が安全な場面もあります。

本番で危険になるパターン

Docker Composeそのものが危険というより、開発用のノリを本番へ持ち込むと危険です。

Docker公式の本番利用ガイドでも、本番向けにはアプリコードのvolume bindingを外す、ホスト側のポートを変える、ログの詳細度や外部サービス向け環境変数を変える、といった調整が必要だと整理されています。
つまり、Composeを使うとしても、開発用と本番用の設定は分ける前提です。

小規模運用での判断基準

Docker Composeを本番で使うか迷ったら、次の質問に答えてみると判断しやすいです。

この表で左側が多ければ、Compose本番運用は現実的です。
右側が多いなら、Composeで頑張るより、AWS ECS、Kubernetes、App Runner、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や機密情報の扱いを分ける

「サーバー上でgit pullして、そのままdocker compose up -d」は楽ですが、長期運用では事故が出やすいです。
ビルド済みイメージをレジストリに置き、本番ではそのタグをpullする形にすると、どのバージョンが動いているか説明しやすくなります。

volumeの基本やデータベースのデータを消さないための考え方は、Dockerのvolumeとは？DBデータを消さないための永続化の基本 で詳しく整理しています。

データベースをComposeに入れてよいか

小規模運用で一番悩むのが、DBを同じComposeに入れるかどうかです。

個人開発、検証環境、小さな社内ツールなら、MySQLやPostgreSQLを同じサーバーのComposeで動かすこともあります。
ただし、本番データを扱うなら、次を決めないまま始めるのは危険です。

• データvolumeはどこに置くか
• バックアップはいつ、どこへ、何世代残すか
• 復元テストをしたことがあるか
• サーバーごと壊れたとき、別サーバーへ戻せるか
• DBのメジャーアップデートをどう行うか
• ディスク容量不足をどう検知するか
• DBパスワードや接続情報をどう管理するか

売上、顧客情報、契約情報、決済状態、予約情報のような重要データを扱うなら、DBだけはマネージドサービスに逃がす判断もかなり現実的です。
Composeはアプリとワーカーをまとめるために使い、DBはRDSやCloud SQLのような外部サービスにする、という分け方です。

本番DBの扱いは、AI文脈の記事ですが 本番DBをAIに触らせていい？読み取り専用から始める判断基準 でも「本番データの影響が大きい場所」として整理しています。

デプロイ手順をどう作るか

Compose本番運用では、デプロイ手順を短く、戻しやすくするのが大事です。

たとえば、最低限は次のような流れにします。

1. CIでDockerイメージをビルドする
2. テストを通す
3. コンテナレジストリへタグ付きでpushする
4. 本番サーバーで新しいタグをpullする
5. docker compose config で設定を確認する
6. docker compose up -d で反映する
7. ヘルスチェック、ログ、主要画面を確認する
8. 問題があれば前のタグへ戻す

本番サーバー上で直接ビルドすると、サーバーのCPUやメモリを使います。
小さなVPSではビルド中にアプリが重くなったり、OOMが起きたりすることがあります。ビルドはCI側、本番はpullして起動だけ、という分け方の方が安定します。

また、docker compose down を気軽に使うのも注意です。
ネットワークやコンテナを落とすだけでなく、オプションや構成によっては思わぬ影響が出ます。データvolumeや永続化の扱いを理解しないまま実行すると危険です。

監視とログはComposeの外側にも置く

Composeでコンテナを起動できても、運用はそこで終わりではありません。
本番では、少なくとも次を確認できるようにします。

• サイトが外から見えるか
• コンテナが再起動を繰り返していないか
• ディスク容量が足りているか
• メモリ不足やOOMが起きていないか
• アプリのエラーログを追えるか
• バックアップが成功しているか
• 証明書やドメインの期限が近づいていないか
• 外部API、メール、決済の障害を切り分けられるか

restart: always を設定しておけば安心、ではありません。
再起動して一時的に戻ることはありますが、原因が消えるわけではないからです。再起動回数、アプリログ、ホストのメトリクスを見られる状態にします。

CloudflareやCDNの前段を使う場合は、Cloudflareとは？DNS・CDN・WAFをどう使い分ける？ のように、DNS、CDN、WAF、オリジンサーバーの責任分担も見ておくと安心です。

セキュリティで見るポイント

Compose本番運用で見たいセキュリティ項目は、派手ではありません。
むしろ、基本を外さないことが大事です。

• 不要なポートを公開しない
• DBやRedisをインターネットへ直接公開しない
• rootユーザーで動かす必要があるか確認する
• .env や秘密鍵をGitに入れない
• イメージタグを固定する
• 公式イメージや信頼できるイメージを使う
• ベースイメージやライブラリを更新する
• ホストOSも更新する
• 管理用SSHにMFAや鍵認証、IP制限を入れる
• バックアップに本番と同じ秘密情報を雑に置かない

Composeはアプリを分けやすくしますが、コンテナに入れたから安全になるわけではありません。
ホストOS、Docker Engine、コンテナイメージ、アプリ、ネットワーク、秘密情報の管理まで含めて本番運用です。

Composeをやめた方がいいサイン

最初はComposeでよくても、途中で限界が来ることがあります。
次のサインが増えてきたら、別の運用方式を検討します。

• 1台ではCPUやメモリが足りない
• デプロイのたびに数分以上止められない
• 障害時に手動SSH対応がつらい
• DBやファイルのバックアップ運用が重くなってきた
• 複数人でリリース承認や監査ログが必要になった
• ステージングと本番の差分管理がつらい
• 夜間休日の障害対応が契約上必要になった
• サーバー障害時の復旧時間が許容できなくなった

ここまで来たら、Composeが悪いのではなく、サービスの段階が変わったということです。
ECS、Kubernetes、PaaS、マネージドDB、オブジェクトストレージ、CDN、監視サービスなどへ役割を分ける方が、結果的に運用が楽になることがあります。

よくある誤解

Docker Composeは本番禁止？

禁止ではありません。
Docker公式にも本番でComposeを使うガイドがあります。ただし、本番向けの設定分離、永続データ、ログ、更新手順、セキュリティを考えずに使うのは危険です。

Kubernetesを使えば必ず本番向き？

そうとも限りません。
Kubernetesは強力ですが、学習コスト、監視、アップグレード、マニフェスト管理、権限管理が増えます。小規模サービスでは、Kubernetesを入れたことで運用が重くなることもあります。

コンテナならバックアップはいらない？

いります。
コンテナイメージは作り直せても、DBデータ、アップロードファイル、設定、秘密情報、ログは別です。何を再生成できて、何を失うと困るのかを分けて考えます。

compose.yamlがあれば引き継ぎは十分？

十分ではありません。
起動方法は分かっても、バックアップ、復旧、デプロイ、障害時連絡、外部サービス契約、DNS、証明書、環境変数の意味までは分かりません。運用手順書も必要です。

小規模本番運用チェックリスト

最後に、Docker Composeを本番で使う前のチェックリストをまとめます。

• 本番用のComposeファイルを分けた
• アプリコードのbind mountを外した
• イメージタグを固定した
• .env や秘密情報の保管方法を決めた
• DBやRedisを外部公開していない
• 永続volumeとバックアップ先を決めた
• 復元テストを一度は実施した
• ログの保存場所と確認方法を決めた
• ディスク、メモリ、死活監視を入れた
• デプロイ手順とロールバック手順を残した
• ステージング環境で同じ手順を試した
• ホストOSとDocker Engineの更新方針を決めた
• 障害時に誰が何を見るか決めた

このチェックを通せるなら、小規模な本番運用でDocker Composeを使うのは十分現実的です。
逆に、バックアップ、復旧、監視、更新のどれかを説明できないなら、Composeかどうか以前に本番運用の準備が足りません。

まとめ

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?