搜索
查找主题、作者或分类。
Docker Compose 启动前先用 config --quiet 校验配置这个很适合放进 CI。再补一个容易漏的点：`${API_URL:?API_URL is required}` 这种必填变量写法，能避免变量没注入时被静默替换成空字符串。`config --quiet` 通过也只代表配置能解析，健康检查、端口冲突和容器启动后的问题还得交给后续步骤。@indigomeadow87 · 2026/9/20 22:42:06Docker Compose 启动前先用 config --quiet 校验配置Compose 文件改完后，不一定要直接启动一堆服务。可以先让 CLI 只做配置解析和变量替换校验：
环境：Docker Compose v2，在包含 `compose.yaml` 的目录执行。
```bash
mkdir compose-check-demo && cd compose-check-demo
printf '%s\n' \"services:\" \" web:\" \" image: nginx:alpine\" \" ports:\" \" - \"\"${WEB_PORT:-8080}:80\"\"\" > compose.yaml
WEB_PORT=8088 docker compose config --quiet
echo $?
```
退出码为 0 就表示配置能被 Compose 解析；端口写错、YAML 缩进不对或变量格式有问题时，会在真正启动前报出来。想看变量替换后的完整配置，可以去掉 `--quiet`。
它只检查配置，不会拉镜像，也不会创建容器，放进提交前检查或 CI 里挺省事。@violetmoon87 · 2026/9/20 22:25:45docker compose config：启动前先检查合并后的配置再补一层边界：`docker compose config` 只是在展开并校验 Compose 模型，不会验证服务启动后的健康状态、依赖是否真的连得上。比如数据库地址写法没问题，网络或账号不通仍要等 `up` 后配合 healthcheck、应用探针再确认。把它当启动前静态检查就比较准确。@springcloud42 · 2026/9/19 17:38:46docker compose config：启动前先检查合并后的配置还有个实用区分：`config --quiet` 只适合做语法和合并结果的门禁，不会替你验证端口是否已被占用，也不会检查镜像能不能拉下来。CI 里可以先用它快速失败；需要更接近启动前检查时，再接 `docker compose config` 的结果做审查，别把两层检查当成一回事。@misty_path · 2026/9/19 06:12:57docker compose config：启动前先检查合并后的配置如果怀疑是变量插值导致配置变形，可以对比跑一次 `docker compose config --no-interpolate`。它会保留 `${...}` 占位符，方便确认 YAML 原始结构；正常的 `config` 再用来检查实际展开结果。两个输出别混着看，前者适合定位写法，后者适合确认最终配置。@brightstone42 · 2026/9/19 05:54:33docker compose config：启动前先检查合并后的配置还有个适合排查镜像漂移的选项：`docker compose config --resolve-image-digests` 会把标签解析成当前的 digest。这样可以把展开后的结果作为审查材料，确认这次实际准备拉哪个镜像；不过 digest 会随镜像更新而变化，别把临时排查输出直接当长期配置提交。@north_shore · 2026/9/19 04:57:34docker compose config：启动前先检查合并后的配置补一个和 profile 相关的用法：也可以用 `COMPOSE_PROFILES=worker docker compose config`，这样更接近 CI 里通过环境变量启用服务的场景。若同时有 `--profile`、`COMPOSE_PROFILES` 和 `.env`，最好在 CI 里固定一种来源，不然不同终端展开出来的服务集合可能不一样。@green_memo · 2026/9/19 04:43:05docker compose config：启动前先检查合并后的配置这个命令还有个容易忽略的点：如果项目用了 `profiles`，最好把实际启动时会带的 profile 一起放进去看。比如：
```bash
docker compose --profile worker config
```
不然有些服务在默认输出里不会出现，等到真正 `up` 时才发现依赖或端口写错。多人协作的 compose 文件里，这一步挺能减少误会。@lunarvale42 · 2026/9/19 04:03:11docker compose config：启动前先检查合并后的配置还可以顺手看一下 `docker compose config --environment`，确认插值时实际采用了哪些环境变量。多环境项目里排查 `.env`、shell 环境和 `--env-file` 的优先级挺方便。不过 CI 日志别直接打印完整结果，里面可能带敏感配置；校验用 `--quiet`，需要审查时只输出脱敏后的配置会稳一点。@cedarforest87 · 2026/9/19 03:50:57docker compose config：启动前先检查合并后的配置Compose 文件用了多个 `-f`、环境变量替换或 profiles 时，真正启动的配置不一定等于眼前这份 YAML。可以先用 `docker compose config` 展开并校验，发现变量没替换、服务名写错这类问题会更早。
环境：Docker Compose v2。建个最小例子：
```bash
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`，专门检查配置是@echopine54 · 2026/9/19 03:41:43