Docker Composeで複数コンテナ｜クラウドインフラ

🎓 レベル：標準　|　重要度：A（必須）

📎 前提：コンテナのネットワークとボリューム　|　関連：Dockerイメージとレイヤ・Pod・Deployment・ReplicaSet

要点（BLUF）

Docker Compose は、複数コンテナの構成（イメージ・ポート・ネットワーク・ボリューム・依存）を1つの compose.yaml に宣言し、docker compose up でまとめて起動する道具。
手で docker run を何度も打つ代わりに、構成をコードにする。チーム全員が同じ環境を1コマンドで再現できる。
主に開発・テスト環境向け。本番で多数のコンテナを束ねる調整は Kubernetes（Kubernetesの全体像（宣言的・調整ループ））へ。

概念 ── 構成を1ファイルに宣言する

実アプリは「Web ＋ DB ＋キャッシュ」のように複数コンテナで成り立ちます。これを docker run で個別に起動・接続するのは手間で間違いやすい。Compose は構成全体を1つの宣言ファイルにまとめ、依存・ネットワーク・ボリュームを自動で面倒みます。前トピック（コンテナのネットワークとボリューム）の手作業が、まるごと宣言に置き換わります。

flowchart TB
    file["compose.yaml（構成の宣言）"] --> up["docker compose up"]
    up --> web["web サービス（公開:8080）"]
    up --> db["db サービス（内部のみ）"]
    up --> net["専用ネットワーク（自動作成・名前解決）"]
    up --> vol["ボリューム（自動作成・db永続化）"]
    web -->|"ホスト db で接続"| db

仕組み ── compose.yaml の構造

# compose.yaml ── Web＋DB の最小構成
services:
  web:
    build: ./app              # ローカルの Dockerfile からビルド
    ports:
      - "8080:80"             # ホスト8080 → コンテナ80
    environment:
      DB_HOST: db             # サービス名で名前解決できる
    depends_on:
      - db                    # db を先に起動

  db:
    image: postgres:16        # タグ固定（latest を避ける）
    environment:
      POSTGRES_PASSWORD: example   # 開発用。本番は Secret で注入
    volumes:
      - pgdata:/var/lib/postgresql/data   # データを永続化
    # ports は書かない＝外に公開しない（内部のみ）

volumes:
  pgdata:                     # 名前付きボリュームの宣言

3要素が肝。services に各コンテナ、volumes に永続化領域、そしてサービス名がそのままホスト名になる（web から db で繋がる）。ネットワークは明示しなくても専用ネットワークが自動作成され、内蔵DNSで名前解決されます。

動く例 ── ライフサイクル

# ビルドして全部まとめて起動（-d はバックグラウンド）
docker compose up -d --build
# 状態を見る
docker compose ps
# web のログだけ追う
docker compose logs -f web
# まとめて停止・削除（-v でボリュームも消す＝データも消える点に注意）
docker compose down

up 一発で「ビルド → ネットワーク作成 → ボリューム作成 → 依存順に起動」まで自動。down で後片付けも一括。開発環境を捨てて作り直すのが一瞬になります。

なぜ Compose なのか

環境の再現性のため：compose.yaml を git に置けば、新メンバーも up 一発で同じ環境。「自分のPCでは動く」が消える。
構成をコードにするため：手順書（暗黙知）でなくファイル（明示）になる。差分が git で追え、レビューもできる（IaCとは・宣言的構成と同じ思想）。
本番への橋渡し：サービス・依存・ボリュームという考え方は、そのまま Kubernetes（Pod・Deployment・ReplicaSet）の Pod・Deployment に対応する。Compose は「本番の縮図」を手元で回す練習でもある。

⚠️ よくある誤解・落とし穴

「Compose を本番のオーケストレータに使う」→ Compose は単一ホスト向けで、自動復旧・スケール・ローリング更新は弱い。本番の多ホスト運用は Kubernetes（Kubernetesの全体像（宣言的・調整ループ））。
「docker compose down -v を本番感覚で叩く」→ -v はボリュームごと削除＝データ消滅。普段の停止は down（ボリューム保持）。
「パスワードを compose.yaml に平文」→ 開発はともかく本番は厳禁。.env やシークレット管理へ（ConfigMap・Secret・ボリューム）。
「depends_on で起動順を保証したから接続も保証」→ depends_on は起動順だけで「DBが受付可能になるまで待つ」わけではない。アプリ側にリトライ/ヘルスチェックを。
「image: postgres（latestのまま）」→ 再現性が壊れる。タグを固定する（Dockerイメージとレイヤ）。

対応ラボ

cloud-infra-study/labs/03-04_compose.yaml ＋ 03-04_app/（web＋db を1コマンドで起動。up -d → ブラウザ確認 → down のライフサイクルを観察）。