启动 Compose 前,先用 config 校验最终配置

58 次浏览4 条回复

Compose 文件有多层覆盖、环境变量和 profiles 时,直接启动才发现配置问题会比较慢。可以先在项目根目录检查最终解析结果:

docker compose config --quiet

校验通过时没有输出并返回 0;有问题会打印具体字段或语法错误。想看合并后的完整配置,可以去掉 --quiet:

docker compose -f compose.yml -f compose.dev.yml config

环境:Docker Compose v2。这个命令只解析配置,不会启动容器,特别适合放进 CI。注意命令会展开环境变量,查看输出或保存日志前先确认里面没有敏感值。

补充一点:CI 里如果依赖某个 profile,校验时要显式带上对应的 --profile,不然没启用的服务不会进入最终配置,容易漏掉问题。还可以把 docker compose ... config --quiet 放在部署前,并让缺失的必需环境变量直接令流程失败;调试完整配置时注意输出里的敏感值。

config --quiet 过了也不代表必需变量真的有值:Compose 对普通 ${VAR} 可能只给警告并替成空串。关键变量可以写成 ${VAR:?missing VAR},让校验直接失败。CI 里我还会顺手跑一次 docker compose ... config --services,确认 profile 和覆盖文件没有把预期服务漏掉。

还有一点是插值来源要固定:本地可能读到了项目根目录的 .env,CI 却没有。需要对齐环境时可以显式传 --env-file .env.ci 再跑 config --quiet,并把这份文件里的敏感值改成 CI 注入的变量。否则配置语法通过了,实际展开结果还是可能和部署环境不一样。

oliveLv1#3

还有一点是插值来源要固定:本地可能读到了项目根目录的 .env,CI 却没有。需要对齐环境时可以显式传 --env-file .env.ci 再跑 config --quiet,并把这份文件里的敏感值改成 CI 注入的变量。否则配置语法通过了,实际展开结果还是可能和部署环境不一样。

config --quiet 只验证 Compose 配置模型和插值,不会确认镜像能拉下来,也不会检查容器启动后的健康状态。CI 里可以把它当成第一道静态校验,后面再按环境决定是否跑 docker compose pull 和最小启动检查;这样配置错误、镜像权限问题、运行时失败不会混在一起。