はじめに
第2回では、Dockerの基本要素（イメージ／コンテナ／ボリューム／ネットワーク）を運用目線で整理しました。
ここまで理解できると、次に現場で必ず直面するのが「複数コンテナの管理」です。
実際の業務システムは、単体のコンテナだけで完結することはほとんどありません。典型例は次のような構成です。
- Web（Nginx）
- App（PHP, Node.js, Javaなど）
- DB（MySQL, MariaDB, PostgreSQLなど）
- キャッシュ（Redis）
- 検索（Elasticsearch）
この複数要素を、コマンドを打ちながら手動で起動・停止していたら、運用は破綻します。
そこで登場するのが Docker Composeです。
Composeは単なる便利ツールではなく、複数コンテナ構成を「設計」として管理するための仕組みです。
Docker Composeとは何か
Docker Composeとは、複数コンテナをまとめて定義し、まとめて起動・停止できる仕組みです。
中心となるのは docker-compose.yml という設定ファイルです。
Composeが運用にもたらす3つの価値
Composeが導入されると、運用の現場では次のメリットが生まれます。
- 構成がファイルに残る（＝引継ぎできる）
- 再現性が高い（＝環境差異が減る）
- 起動・停止が統一される（＝運用手順が簡単になる）
これは情シス視点では特に重要です。
担当者が変わっても、docker-compose.ymlが残っていれば、最低限「同じ構成で起動できる」状態が維持できます。
docker-compose.ymlは「設計書」である
Composeはしばしば「開発者がローカルで使うもの」と誤解されます。
しかし業務利用では、docker-compose.ymlは設計書そのものです。
Composeで定義しているのは何か
docker-compose.ymlでは、次のような情報をコードとして残せます。
- どのコンテナが必要か（サービス定義）
- どのイメージを使うか
- 環境変数（DB接続情報など）
- ポート公開
- ボリューム（永続化）
- ネットワーク（内部通信）
- 起動順序の考慮
これらは従来、Excelの構成表や、口頭の引継ぎで共有されがちでした。
Composeを採用することで、「実際に動く設計」が残るようになります。
serviceとは何か：システムの「部品」を定義する
Composeの中心は services です。 これは「このシステムはどんな部品で構成されるか」を宣言する部分です。
典型例：Web＋App＋DB
業務で最も多いのは、次のような3層構成です。
- web：Nginx
- app：PHP-FPM / Node / Java
- db：MySQL / MariaDB
この3つを、Composeでは「3つのサービス」として定義します。
運用担当が見るべきポイントは、サービスが増えるほど「責任分界」が明確になる点です。
たとえば障害時に「Webが落ちたのか」「DBが落ちたのか」を切り分けしやすくなります。
環境変数の設計：本番運用で最も事故が起きやすい
Composeでは、DBパスワードや接続先などを環境変数で渡すことが多くなります。
ここは便利な反面、運用事故が起きやすい領域です。
よくある失敗例
- パスワードをymlに直書きしてGitに上げてしまう
- 開発環境の設定が本番に混ざる
- 環境変数が多すぎて意味が分からなくなる
運用目線のベストプラクティス
次の方針を守ると、引継ぎと保守が楽になります。
- 環境変数は .env に分離する
- ymlには変数名だけを書き、値は外に出す
- 変数名の命名規則を揃える（DB_HOST, DB_USERなど）
情シス視点では、.envは「設定台帳」に近い役割になります。
このファイルの管理方針（誰が編集するか、バックアップするか）が、そのまま運用品質になります。
ボリューム設計：DB永続化とファイル管理
第2回で述べた通り、業務システムで最も重要なのはデータです。
Composeでも、ボリューム設計は最重要ポイントになります。
DBは必ずボリュームに置く
DBコンテナは、コンテナ削除で消えると致命的です。
ComposeでDBを扱う場合は、必ずvolumeで永続化します。
ここを曖昧にすると、次のような事故が起きます。
- 障害対応でコンテナを作り直したらデータが消えた
- バックアップ対象が分からず復旧できない
アップロードファイルの置き場所を決める
業務システムでは、次のようなファイルが必ず発生します。
- 見積書・請求書PDF
- 画像ファイル
- 添付ファイル
これをコンテナ内に置いてしまうと、コンテナ更新で消えます。
「DBだけボリューム」「ファイルは放置」が非常に多いので注意が必要です。
ネットワーク設計：外に出すもの／出さないもの
Composeを使うと、デフォルトで内部ネットワークが作られます。 この仕組みは、運用にとって非常に重要です。
DBは内部ネットワークに閉じる
運用事故の典型として、DBポートをホストに公開してしまい、外部からアクセス可能になっているケースがあります。
本番運用では原則として、
- 外部公開するのはWebのみ
- DBは公開しない
を徹底するのが基本です。
起動順序の誤解：depends_onは万能ではない
Composeを使うと、depends_onで起動順序を指定できます。
ただしここで重要な誤解があります。
depends_onは「起動順」であり「準備完了」ではない
depends_onは、コンテナを起動する順番を制御するだけです。
DBが「起動して接続可能」になる前に、アプリがDBに接続しにいって失敗することがあります。
これが、Composeでよくある「起動したのにアプリが動かない」問題の原因です。
healthcheckを使うべき理由
運用で安定させるなら、healthcheckで「準備完了」を判定する設計が必要です。
この設計があるだけで、再起動時の不安定さが大きく減ります。
運用で重要なComposeコマンド
Composeを運用で扱うなら、次のコマンドは必須です。
起動：docker compose up
- 開発ではup -d（バックグラウンド）を多用
- 障害調査では-dなしでログを見ながら起動
ログ確認：docker compose logs
障害時に「どのコンテナが原因か」を切り分けるには、logsが最初の一手になります。
停止：docker compose down
downはコンテナを削除します。
この時に「ボリュームも消す」オプションを使うとデータが消えるため、本番では慎重に扱う必要があります。
次回予告
次回は、Docker/Composeを「動かす」から一段上げて、 本番運用で必須となる設計を扱います。
具体的には、
- ログ設計（どこに出すか／どう集めるか）
- バックアップ設計（DB・ファイル・設定）
- 監視設計（死活監視・リソース・アラート）
といった、情シス・運用担当が最も困りやすいポイントを中心に解説します。
