Docker Compose profiles 依赖服务分属不同 profile 时的启动配置

Docker Compose 的 profiles 只决定服务何时被启用，不会把不同 profile 自动合并成一个依赖组。一个常见场景是：migrate 放在 tools，它的 depends_on 又指向放在 data 的 db。这时直接点选或执行 docker compose run migrate，重点不是继续堆启动参数，而是先收敛依赖模型。

官方地址：https://docs.docker.com/compose/how-tos/profiles/

先把跨 profile 依赖画清楚

先不要改命令，打开项目里的 compose.yaml，找到目标服务的 profiles、depends_on，再沿着依赖名称找到被依赖服务的 profile。下面这份最小配置故意制造了边界：

services:
  migrate:
    image: example/app:latest
    profiles: [tools] # 一次性迁移任务只在 tools 场景启用
    depends_on:
      - db # 这里声明启动依赖，但不替代 profile 规划

  db:
    image: postgres:16
    profiles: [data] # 数据服务被放进了另一个场景

这里的关键事实是：显式指定 migrate 时，Compose 会处理它所属的 tools profile；但 db 仍被 data profile 限制。只看 depends_on，容易误以为 data 会自动跟随 tools。

按依赖强度选择三种配置方案

有三种处理方式，选择标准是依赖是否和目标服务总是成对出现。

强绑定时，把两者改为同一 profile 是最直观的方案：

services:
  migrate:
    image: example/app:latest
    profiles: [tools] # 迁移命令与数据服务共享 tools 场景
    depends_on: [db]
  db:
    image: postgres:16
    profiles: [tools] # 同 profile 才能随目标一起纳入启用范围

如果 db 是整个项目的核心服务，更适合删除它的 profiles 属性。官方文档把没有 profile 的服务视为默认启用服务，这比为每个命令反复拼接 data 更稳定。

用明确命令启用并启动服务

同 profile 配置保存后，在 compose 文件所在目录执行：

# 启用 tools profile，并以后台方式启动迁移依赖
docker compose --profile tools up -d

# 只启用多个已知 profile，避免意外启动其他工具
docker compose --profile tools --profile data up -d

# 也可以用逗号分隔的环境变量表达同一范围
COMPOSE_PROFILES=tools,data docker compose up -d

若采用“单独启动”方案，先启动依赖，再运行目标任务；不要把“目标服务显式启动”误当成“所有依赖 profile 自动打开”。此时命令顺序表达了运维意图，回滚时也更容易拆分。

验证启动范围和回退路径

配置保存后，用三步检查结果。第一步查看 Compose 解析到的 profile 和服务；第二步查看运行状态；第三步确认停止命令不会误伤其他 profile。

# 先看解析结果，确认 services 与 profile 归属
docker compose config --profiles

# 再看当前容器状态，确认 db 已 ready、migrate 已完成或运行中
docker compose ps

# 只停止本次目标服务；需要清理整个 profile 时再使用 --profile
docker compose stop migrate

如果 config --profiles 显示的 profile 和预期不同，先回到服务定义检查缩进、服务名和 profile 拼写。不要用 --profile "*" 作为第一反应，它会打开所有 profile，排查时可能把无关工具一起拉起。

常见问题

为什么 depends_on 写了 db，db 还是没有跟随启动？

因为 depends_on 描述依赖关系，而 profiles 仍限制服务是否被启用。让两者共享 profile、去掉核心依赖的 profile，或先单独启用 db。

目标服务显式启动时一定要写 --profile 吗？

不一定。显式指定带 profile 的目标服务时，Compose 会自动处理目标服务的 profile；但这不等于会自动启用依赖服务所在的其他 profile。

什么时候适合把依赖移出 profiles？

当它是大多数开发、测试或运维命令都需要的核心服务时。这样启动范围更可预测，profile 只用来隔离可选工具。