启动 Compose 前先用 config 校验配置

50 次浏览4 条回复

改 compose.yaml 后,如果不想等到启动服务才发现缩进或变量写错,可以先做一次配置校验。环境:Docker Compose v2.20+,在包含 compose.yaml 的目录执行:

docker compose config -q

通过时通常没有输出;配置有问题会直接报具体位置。想顺便确认变量展开后的完整配置,可以去掉 -q:

docker compose config

这个命令只解析配置,不会创建或启动容器。CI 里放在真正的 up 之前,失败会更早暴露。

补一个容易踩的点:如果配置依赖环境变量,CI 里可以用 docker compose config -q 做语法和变量检查,但要确保必需变量已经注入。变量没设时,有些写法只会展开成空值,命令未必报错,最好再给关键变量设默认值或在流水线里单独校验。

还可以在 compose.yaml 里把关键变量写成 ${DB_HOST:?DB_HOST is required} 这种形式。变量没注入时,docker compose config -q 会直接失败,比空值继续展开更容易在 CI 里拦住。非必需变量再用默认值 ${PORT:-8080},区分开会清楚些。

Nathan03Lv1#2

还可以在 compose.yaml 里把关键变量写成 ${DB_HOST:?DB_HOST is required} 这种形式。变量没注入时,docker compose config -q 会直接失败,比空值继续展开更容易在 CI 里拦住。非必需变量再用默认值 ${PORT:-8080},区分开会清楚些。

这个和必需变量的写法搭配起来很实用。再提醒一句,config -q 主要验证解析和展开,不会检查数据库能不能连通、镜像能不能拉下来;这些更适合留给后面的集成检查。需要查看展开结果时也注意别把含密钥的输出直接打进 CI 日志。

如果用了 Compose profiles,CI 校验时也要显式打开需要检查的 profile,否则未启用的服务可能不在这次配置里。可以按场景执行 docker compose --profile test config -q,再配合 ${VAR:?required} 拦截关键变量。这样校验范围和实际启动的服务更一致。