メインコンテンツまでスキップ

第04章：プロジェクト名と“同居”の考え方🏙️🧩

この章はひとことで言うと—— **Composeの「プロジェクト名」＝同じPCに“別の街（環境）”を安全に並べて建てるための“住所（接頭辞）”**です🏙️✨

4-1. 「同居」ってなに？🤝🏠​

同じPCで、こういうことしたくなります👇

  • ふだん用（main）と、実験用（feature）を同時に起動したい🧪
  • A案件とB案件、どっちもDB付きで動かしたい🗄️
  • 同じ web / db というサービス名が複数あっても、衝突せずに並べたい🧩

そこで登場するのが「プロジェクト名」🎯 Composeはプロジェクト名を使って環境を分離します。(Docker Documentation)

4-2. プロジェクト名が効く場所（何が分離される？）🧱🔒​

Composeは起動するとき、だいたいこういう“共有物”を作ります👇

  • コンテナ名（例：myapp-web-1）
  • ネットワーク（例：myapp_default）
  • ボリューム（例：myapp_db-data）

しかも、デフォだとネットワークは {project}_default みたいな名前で作られます。(Docker Documentation) コンテナ名も {project}-{service}-1 みたいにプロジェクト名が先頭につきます。(Docker Documentation) ボリュームも通常は {project}_db-data のように“プロジェクト名がプレフィックスとして付く”挙動です。(Docker Documentation)

✅ だから、プロジェクト名さえ違えば、web と db が何個あっても基本は衝突しません😎✨

4-3. プロジェクト名はどう決まる？（超重要）🧠🗺️​

「どれが採用されるの？」の優先順位はこれです👇（上ほど強い）

  1. -p（コマンドの -p 名前）
  2. COMPOSE_PROJECT_NAME（環境変数）
  3. compose.yaml のトップレベル name:
  4. compose.yaml が置かれてるフォルダ名（= project directory の basename）
  5. Composeファイル未指定ならカレントフォルダ名

公式にこの順序で明記されています。(Docker Documentation)

さらに name: については、Compose仕様で「プロジェクト名として使う」とされています。(Docker Documentation)

4-4. いちばん安全な流儀：name: を書いて“住所”を固定する🏷️✨​

フォルダ名が変わると、プロジェクト名も変わってしまいがちです📁💦 だから、教材的には compose.yaml に name: を書いて固定がいちばん安定です👍

name: myapp
services:
  web:
    image: nginx:alpine
  db:
    image: postgres:18

この name: は「明示しない場合のプロジェクト名」として扱われます。(Docker Documentation)

4-5. “同居”の実戦：同じcomposeを2つ同時に立ち上げる🧪🏗️​

パターンA：フォルダを分ける（いちばん直感的）📁📁​

  • myapp-main/compose.yaml
  • myapp-feature/compose.yaml

それぞれのフォルダで docker compose up -d をすると、 **プロジェクト名（=フォルダ名）**が違うので、ネットワークも分かれます。(Docker Documentation)

確認コマンド（覚えとくと気持ちいい😆）

docker compose ls
docker ps
docker network ls
docker volume ls

パターンB：同じフォルダで“2棟建て”する（-p を使う）🏙️🏙️​

同じ compose.yaml を使って、別プロジェクトとして起動できます✨

docker compose -p myapp_a up -d
docker compose -p myapp_b up -d

この -p が最優先で採用されます。(Docker Documentation)

パターンC：環境変数で固定（COMPOSE_PROJECT_NAME）🧰🧪​

COMPOSE_PROJECT_NAME でプロジェクト名を指定できます。(Docker Documentation)

PowerShell例👇

$env:COMPOSE_PROJECT_NAME="myapp_a"
docker compose up -d

※ .env からも読み込めます（プロジェクトディレクトリに .env を探す挙動がデフォ）。(Docker Documentation)

4-6. ここだけは衝突する！“同居の落とし穴”🕳️💥​

プロジェクト名で分離できても、ホスト側の資源は共通なのでぶつかることがあります😇

① ホストのポート（ports:）🚪🔥​

同じ 5432:5432 を2つのプロジェクトでやると、ホスト側の 5432 が取り合いになります。

  • コンテナ間通信は **CONTAINER_PORT（右側）**を使う
  • 外から入るのが HOST_PORT（左側）

この区別は公式でも強調されています。(Docker Documentation)

例：片方だけホストポートを変える👇

services:
  db:
    image: postgres:18
    ports:
      - "15432:5432"

② container_name: を固定しちゃう😵‍💫​

container_name: db みたいに書くと、プロジェクト名の恩恵が消えて衝突しやすくなります。 （基本は避けるのが安全👍）

③ externalネットワーク／externalボリュームは“共有”になる🤝​

external: true を使うと、Composeは {project}_... を作らず、指定した“既存リソース名”を探して使う動きになります。

  • 外部ネットワーク例：[project]_default を作らず、指定名のネットワークへ参加する。(Docker Documentation)
  • 外部ボリューム例：{project}_db-data を作らず、db-data を探して使う。(Docker Documentation)

つまり external は「同居しても分離」じゃなくて、**意図的に“同居で共有”**したいときの道具です🧩✨

4-7. 片付け（プロジェクト単位で消せるのが気持ちいい）🧹✨​

同居してても、プロジェクト名が違えば別々に片付けできます👌

docker compose -p myapp_a down
docker compose -p myapp_b down

ボリュームまで消すなら👇（※データも消えるよ⚠️）

docker compose -p myapp_a down -v

あと地味に便利なのが、Composeが付けるラベルです。 ボリュームには com.docker.compose.project などのラベルが付くので、追跡がしやすいです。(Docker Documentation)

4-8. ミニ練習（5分で“同居マスター”）🎮✅​

練習1：同じ compose.yaml を -p で2つ起動してみよう🏙️🏙️

  • docker compose -p a up -d
  • docker compose -p b up -d → docker ps を見て、コンテナ名に a- / b- が付いてたら勝ち🎉(Docker Documentation)

練習2：ネットワーク名を確認しよう🕸️

  • docker network ls で a_default / b_default を探す🔎 （まさに公式例の myapp_default と同じ構造！）(Docker Documentation)

練習3：ポート衝突をわざと起こして理解する🔥

  • 両方で同じ ports: "5432:5432" にして起動 → 片方がコケたら「ホストポートは共有資源」の感覚が掴める😆(Docker Documentation)

4-9. AIに投げると速い“質問テンプレ”🤖💬​

GitHub Copilot や Codex に、こんな感じで聞くと強いです👇✨

  • 「この compose.yaml を、同居できるように -p 前提で衝突ポイント（host port / container_name / external）を洗い出して」
  • 「2プロジェクト同時起動したい。ポート衝突を避ける具体案を3つ出して」
  • 「name: を使ってプロジェクト名を安定化したい。命名規則案（短くて衝突しにくい）を提案して」

ここまで来たら、次の章（Windowsで詰まりがちなポイント🪟🧯）がめちゃ効いてきます🔥