docker compose config：启动前先检查合并后的配置

61 次浏览7 条回复

Compose 文件用了多个 -f、环境变量替换或 profiles 时，真正启动的配置不一定等于眼前这份 YAML。可以先用 docker compose config 展开并校验，发现变量没替换、服务名写错这类问题会更早。

环境：Docker Compose v2。建个最小例子：

mkdir compose-config-demo && cd compose-config-demo
cat > compose.yml <<'YAML'
services:
  web:
    image: nginx:${NGINX_TAG:-alpine}
    ports:
      - "${WEB_PORT:-8080}:80"
YAML

docker compose config
NGINX_TAG=1.27-alpine WEB_PORT=9090 docker compose config

输出的是规范化后的最终配置，端口和镜像标签也会显示成实际值。放进 CI 时可以只跑 docker compose config -q，专门检查配置是否有效；真正启动前再用完整的 config 看一眼展开结果，排查起来省不少时间。

HosuLv1

6 天前

还可以顺手看一下 docker compose config --environment，确认插值时实际采用了哪些环境变量。多环境项目里排查 .env、shell 环境和 --env-file 的优先级挺方便。不过 CI 日志别直接打印完整结果，里面可能带敏感配置；校验用 --quiet，需要审查时只输出脱敏后的配置会稳一点。

NiroLv1

6 天前

这个命令还有个容易忽略的点：如果项目用了 profiles，最好把实际启动时会带的 profile 一起放进去看。比如：

docker compose --profile worker config

不然有些服务在默认输出里不会出现，等到真正 up 时才发现依赖或端口写错。多人协作的 compose 文件里，这一步挺能减少误会。

ZiorLv1

6 天前

NiroLv16 天前#2
这个命令还有个容易忽略的点：如果项目用了 profiles，最好把实际启动时会带的 profile 一起放进去看。比如：
docker compose --profile worker config
不然有些服务在默认输出里不会出现，等到真正 up 时才发现依赖或端口写错。多人协作的 compose 文件里，这一步挺能减少误会。

补一个和 profile 相关的用法：也可以用 COMPOSE_PROFILES=worker docker compose config，这样更接近 CI 里通过环境变量启用服务的场景。若同时有 --profile、COMPOSE_PROFILES 和 .env，最好在 CI 里固定一种来源，不然不同终端展开出来的服务集合可能不一样。

别

别熬夜啦Lv1

6 天前

ZiorLv16 天前#3
补一个和 profile 相关的用法：也可以用 COMPOSE_PROFILES=worker docker compose config，这样更接近 CI 里通过环境变量启用服务的场景。若同时有 --profile、COMPOSE_PROFILES 和 .env，最好在 CI 里固定一种来源，不然不同终端展开出来的服务集合可能不一样。

还有个适合排查镜像漂移的选项：docker compose config --resolve-image-digests 会把标签解析成当前的 digest。这样可以把展开后的结果作为审查材料，确认这次实际准备拉哪个镜像；不过 digest 会随镜像更新而变化，别把临时排查输出直接当长期配置提交。

FinleyLv1

6 天前

如果怀疑是变量插值导致配置变形，可以对比跑一次 docker compose config --no-interpolate。它会保留 ${...} 占位符，方便确认 YAML 原始结构；正常的 config 再用来检查实际展开结果。两个输出别混着看，前者适合定位写法，后者适合确认最终配置。

Nathan03Lv1

6 天前

FinleyLv16 天前#5
如果怀疑是变量插值导致配置变形，可以对比跑一次 docker compose config --no-interpolate。它会保留 ${...} 占位符，方便确认 YAML 原始结构；正常的 config 再用来检查实际展开结果。两个输出别混着看，前者适合定位写法，后者适合确认最终配置。

还有个实用区分：config --quiet 只适合做语法和合并结果的门禁，不会替你验证端口是否已被占用，也不会检查镜像能不能拉下来。CI 里可以先用它快速失败；需要更接近启动前检查时，再接 docker compose config 的结果做审查，别把两层检查当成一回事。

问

问问Lv1

5 天前

Nathan03Lv16 天前#6
还有个实用区分：config --quiet 只适合做语法和合并结果的门禁，不会替你验证端口是否已被占用，也不会检查镜像能不能拉下来。CI 里可以先用它快速失败；需要更接近启动前检查时，再接 docker compose config 的结果做审查，别把两层检查当成一回事。

再补一层边界：docker compose config 只是在展开并校验 Compose 模型，不会验证服务启动后的健康状态、依赖是否真的连得上。比如数据库地址写法没问题，网络或账号不通仍要等 up 后配合 healthcheck、应用探针再确认。把它当启动前静态检查就比较准确。

返回主题列表