profiles 是干什么的
profiles 让同一份编排文件里的服务按组选择性启动：带 profile 的服务只有在该组被激活时才会启动，没有 profile 的服务始终启动。它适合把调试工具、监控组件与一次性任务和主业务放进同一份文件，平时互不干扰，需要时一条命令拉起整组。
基本信息
| 用途 | 给服务分组并按需启动 |
|---|---|
| 激活方式 | 命令行指定 profile 或通过环境变量 |
| 规则 | 未标 profile 的服务始终启动 |
| 适用场景 | 调试工具、监控组件、一次性任务 |
| 注意 | 未激活时相关服务不参与常规操作 |
典型使用场景
- 把调试工具箱与主业务放在同一份文件
- 监控组件按环境决定是否启动
- 一次性任务按需触发，例如初始化或数据迁移
- 用环境变量统一激活某一组服务
- 排查服务为什么没起来时确认是否 profile 未激活
文件中的分组
文件中的分组
services:
api:
image: app/api:1.4.2
debug-tools:
image: nicolaka/netshoot
profiles: [debug] # 仅在激活 debug 组时启动
command: sleep infinity
metrics:
image: prom/prometheus
profiles: [monitoring]激活与核对
激活与核对
docker compose --profile debug up -d # 激活整组服务
COMPOSE_PROFILES=monitoring docker compose up -d # 用环境变量激活
docker compose --profile debug ps # 查看该组下的服务状态
docker compose --profile debug logs --tail=20 # 查看该组服务日志操作与结果
| 操作 | 结果 | 注意 |
|---|---|---|
| 直接启动 | 只起无 profile 的服务 | 带 profile 的服务不会启动 |
| 指定 profile | 该组服务一并启动 | 可同时指定多个组 |
| 环境变量激活 | 适用于脚本与流水线 | 注意不要与命令行参数冲突 |
| 日志与执行命令 | 未激活时看不到相关服务 | 先确认当前是否带了 profile |
该机制适合把调试、监控与一次性工具同主业务放进一份文件而互不干扰，减少维护多份编排文件的成本。
带 profile 的服务在未激活时对日志与执行类命令不可见，排查时先确认当前命令是否带上了对应的参数。