feat: Compose の profiles で、dev に触れずに付随サービス群を後から起動・停止できるようにする

[takemi-ohama]

何をしたいか

dev のほかに app / db などのサービスを抱えるプロジェクトで、次の 2 つを両立させたい。

1. devbase up の既定では dev コンテナだけ を起動する
2. テスト用のサービス群は 後から起動・停止できる。そのとき dev コンテナは再作成も再起動もされない

Compose の profiles を使えば、プロジェクト側の compose.yml はほぼ書き換えるだけで済みます。ただし devbase が profiles を前提にしていないため、プロジェクト側だけでは片付かない穴が 3 つあります（下の「devbase 側で起きること」）。この issue ではその穴を塞ぎ、後から起動・停止するコマンドを devbase に用意します。

想定するプロジェクト側の書き方

services:
  dev:
    # dev から app への依存は外すか required: false にする
    depends_on:
      app:
        condition: service_started
        required: false
  app:
    profiles: [test]
    depends_on:
      mysql:
        condition: service_healthy
  mysql:
    profiles: [test]

required: false を付けないと、既定の up は service "dev" depends on undefined service "app": invalid compose project で止まります（下の検証 1）。

devbase 側で起きること

Docker Compose v5.1.4 で、profiles 付きの最小構成（dev / app / mysql、いずれも alpine:3）を作って確かめました。

#	操作	結果	devbase への影響
1	required: false なしで docker compose up -d	invalid compose project で失敗	プロジェクト側で書けば済む（ドキュメントで案内）
2	--profile test up -d の後に、profile なしで docker compose down	dev だけ消え、app / mysql は 動いたまま。network が Resource is still in use で消せず rc=1	devbase down と、devbase up 冒頭の停止（_previous_scale_compose → docker_compose_down）でテスト用サービスが孤児になる。rc=1 は警告に丸められて気づけない
3	docker compose --profile test up -d app mysql / stop app mysql / down app mysql	dev の稼働は続く（再作成も再起動もされない）	後から起動・停止する操作は サービス名を明示すれば dev に触れずに済む
4	profile なしで docker compose ps	動いている app も表示される	devbase ps はそのままでよい
5	docker compose --profile '*' down	全サービスが消える	停止時はこれを使えばよい

もう 1 点、検証 3 で サービス名を省いて --profile test up -d とすると、dev も reconcile の対象になります。devbase は機密を名前だけ（- GH_TOKEN など）で .docker-compose.scale.yml に書き、値は _inject_secrets が実行時の環境へ載せます。素の docker compose を手で叩くと値が空のまま構成のハッシュが変わり、dev が再作成されうるので、後から起動する操作も devbase を通して機密を注入した状態で、対象サービスを明示して呼ぶ必要があります。

イメージの確認にも影響があります。_ensure_images / _resolve_dev_service は profile なしの docker compose config を読むので、テスト用サービスのイメージは devbase up の時点ではビルドされません。これは狙いどおりの挙動ですが、後から起動するときにビルドが走る（初回は時間がかかる）ことを案内に書く必要があります。

やること（案）

1. 停止を全 profile に効かせる

• docker_compose_down を --profile '*' 付きで呼ぶ（devbase down と devbase up 冒頭の停止の両方）
• devbase up の冒頭停止でテスト用サービスまで止めてよいかは要判断。止めない場合は「dev-N だけ down → up」に変える必要があり、network の扱いが絡む

2. 後から起動・停止するコマンド

名前は仮です。top-level の位置引数はプロジェクト名に吸われるので、container / project のサブコマンドとして生やす。

devbase container profile up <profile>     # そのプロファイルのサービスを起動
devbase container profile down <profile>   # 停止して削除（dev は残す）
devbase container profile list             # compose.yml に書かれたプロファイルと稼働状況
devbase project profile up <name> <profile>  # CWD 非依存版

実装の骨子:

1. _prepare_compose で context 反映と機密注入を済ませる
2. 対象サービスを docker compose --profile <p> config --services と profile なしの config --services の差で求める
3. docker compose -f .docker-compose.scale.yml --profile <p> up -d <services...>（停止は down <services...>）
4. 起動後にプロジェクトのフックを呼ぶ（下の 3）

.docker-compose.scale.yml が無い（devbase up 前）ときはエラーにして devbase up を促す。

3. フックへ「どのプロファイルが立っているか」を渡す

既存の ./deploy はインスタンスごとに呼ばれ、テスト用サービスが立っている前提で DB 初期化などを行うプロジェクトがあります。既定で立たなくなると、deploy が app の healthy を待ち続けて timeout で up ごと失敗します。

• hook_env に DEVBASE_ACTIVE_PROFILES（カンマ区切り、無ければ空）を足す
• profile up の後にフックを呼ぶ。新しいフック名（例: ./post-profile-up）にするか、./deploy を DEVBASE_ACTIVE_PROFILES 付きで呼び直すかは設計で決める

4. 既定で立てるプロファイルを project.yml で選べるようにする（任意）

「うちは全部立てたい」プロジェクトのために、次のような指定を受ける。

compose:
  profiles: [test]   # devbase up で既定で有効にするプロファイル

5. ドキュメント

• プロジェクト作者向けに、profiles の付け方と depends_on.required: false の必要性
• 素の docker compose で起動すると dev が再作成されうるので devbase を通すこと

受け入れ条件

• profiles を付けたサービスは devbase up で起動しない
• devbase container profile up <p> で対象サービスだけが起動し、dev-N の Container ID と起動時刻が変わらない
• devbase container profile down <p> で対象サービスだけが消え、dev-N の Container ID と起動時刻が変わらない
• devbase down でテスト用サービスを含む全サービスと network が消える（rc=0）
• profile up の後にフックが DEVBASE_ACTIVE_PROFILES 付きで呼ばれる
• profiles を使っていない既存プロジェクトの up / down / scale の挙動が変わらない（テストで固定）

範囲外

• scale 時にテスト用サービスをインスタンスごとに複製すること（現状どおり 1 組を共有）

進行

モード: standard / 作業ツリー: .worktrees/feat/issue-189 / 計画: issues/PLAN58_compose-profiles-impl.md

• 要求と受け入れ条件 — 2026-09-16 11:09
• 作業場所の用意 — 2026-09-16 11:09
• 設計 — 2026-09-16 11:09
• 素材の収集と出典の確定
• ドキュメント再構成 — 2026-09-16 11:13
• ドキュメントレビュー — 2026-09-16 11:15
• 計画 — 2026-09-17 05:28
• 実装 — 2026-09-17 05:30
• 構造改善 — 2026-09-17 05:48
• 実装レビュー — 2026-09-17 06:19
• 完了判定 — 2026-09-17 07:29
• Pull Request — 2026-09-17 07:31
• 確定仕様化 — 2026-09-17 09:14
• 後片付け — 2026-09-17 05:28
• 配布 — 2026-09-17 09:23
• 体裁レビュー
• リリース後テスト — 2026-09-17 09:28
• 振り返り — 2026-09-17 09:30

振り返り: #189 (comment)