はじめに
前回の連載「現場で使うDocker実践入門（全5回）」では、Dockerの基本からDockerfile、Docker Composeの基礎、そして運用の最初の一歩までを整理しました。
これで「とりあえず動かせる」状態にはなったはずです。
ただ、業務でDockerを使う場合はここからが本番です。
Dockerは便利な反面、最初の設計が雑なまま進めると、運用フェーズで一気に苦しくなります。
そこで今回から、続編として「現場で困らないDocker ― 設計・運用の実務ガイド」を全5回でお届けします。
このシリーズでは、Docker Composeを中心に、開発環境・検証環境・本番環境を破綻させないための考え方と、現場で役立つ運用の型を整理していきます。
第1回となる今回は、最初に押さえるべきテーマとして「Docker Compose設計の基本（dev/prodの分け方）」を扱います。
Docker Composeは「開発用ツール」なのか？
Docker Composeは、もともと開発環境で使われることが多い仕組みです。
ただし最近では、次のような用途でもよく使われます。
- 小規模システムの本番運用
- 検証環境（ステージング）
- 社内向けシステムの運用
- オンプレミス環境での安定稼働
つまりComposeは「開発専用」ではありません。
ただし、本番で使うなら、最低限の整理が必要です。
その整理をせずに進めると、運用フェーズで確実に困ります。
よくある失敗：docker-compose.ymlが1つだけで肥大化する
Dockerを始めたばかりの段階では、たいてい以下のようになります。
- docker-compose.yml が1つ
- その中に全部書く
- 動いたのでそのまま運用へ
しかしこの形は、後からほぼ確実に破綻します。
なぜなら、開発環境と本番環境では「求めるもの」が違うからです。
例えば、開発環境では
- ソースコードをホストからマウントしたい
- デバッグログを多めに出したい
- DBを簡単に初期化したい
一方、本番環境では
- ソースコードをマウントしない（事故の原因）
- ログは必要十分に抑える
- DBは絶対に消えない設計にする
つまり、同じComposeファイルに両方を詰め込むと、どちらにも中途半端になります。
結論：Composeは「基本＋差分」で設計する
実務でおすすめの型は、以下です。
docker-compose.yml は「共通の基本」だけを書く
環境差分は別ファイルに分ける
代表的には次のように分けます。
- docker-compose.yml（共通）
- docker-compose.dev.yml（開発用の差分）
- docker-compose.prod.yml（本番用の差分）
こうすると、用途に応じて次のように起動できます。
起動コマンドの型（これだけ覚えればOK）
開発環境の起動
docker compose -f docker-compose.yml -f docker-compose.dev.yml up -d
本番環境の起動
docker compose -f docker-compose.yml -f docker-compose.prod.yml up -dComposeは、後ろに指定したファイルが「上書き」になります。
この仕組みを使うと、共通部分と差分をきれいに分けられます。
共通ファイル（docker-compose.yml）に書くべき内容
共通ファイルには、次のような「どの環境でも変わらないもの」だけを書きます。
- サービス構成（web/dbなど）
- コンテナ名（必要なら）
- イメージやビルド定義
- ネットワーク
- 永続化すべきボリューム
ここでのポイントは、「開発専用の設定は書かない」です。
開発用ファイル（docker-compose.dev.yml）に書く内容
開発用ファイルに書くべき内容は、主に以下です。
- ソースコードのマウント（volumes）
- 開発用ポート公開
- デバッグ設定
- 開発用の追加ツール（phpMyAdminなど）
例えば、開発では「編集したソースが即反映される」ことが重要です。
そのため、ホスト側のフォルダをコンテナにマウントします。
本番用ファイル（docker-compose.prod.yml）に書く内容
本番用ファイルに書くべき内容は、次のようなものです。
- 不要なポート公開をしない
- マウントを減らす（基本はしない）
- restartポリシーを設定する
- ログの保存方法を整理する
本番で重要なのは、便利さよりも「事故を防ぐこと」です。
たとえば開発ではDBを外部公開しても問題になりにくいですが、本番で3306を公開するとリスクになります。
環境変数（.env）の整理は必須
Compose運用でよくある混乱が、環境変数の管理です。
- docker-compose.yml の中に直書き
- サービスごとにバラバラ
- どこで設定したかわからない
こうなると、運用担当者が交代したときに引き継ぎが破綻します。
そこで、Composeでは.envファイルを使うのが基本です。
例えば以下のようにします。
- .env（共通）
- .env.dev（開発）
- .env.prod（本番）
そして本番用はGitに入れない（事故防止）という運用が一般的です。
「運用で困らない」ための最低限チェック
最後に、Compose設計の段階で押さえておくべき最低限のポイントをまとめます。
DBのボリュームは必ず分離する
DBはコンテナを消したら終わりです。
必ずボリュームを切り、データが残る設計にします。
本番で不要なポート公開をしない
開発では便利でも、本番ではリスクになります。
restart設定を入れる
本番では、サーバ再起動後に自動で復帰できる形が重要です。
起動手順を固定する
「人によって起動方法が違う」状態は、トラブルの元です。
コマンドは決め打ちで統一します。
次回予告
次回（実務編 第2回）は、より具体的に踏み込みます。
PHP＋Nginx＋MariaDB構成を、業務で使える最小の正解として整理します。
特に、実務では以下が重要です。
- PHPの拡張モジュール
- Nginx設定の置き方
- DB接続設定の持ち方
- ボリュームの整理
「とりあえず動く」ではなく、「引き継げる形」を目指します。
