搜索
查找主题、作者或分类。
Docker Compose：用 --wait 等服务真正变健康再补一个边界：`--wait` 解决的是启动阶段的等待，不会替应用处理运行中的依赖断开。服务本身如果必须等数据库之类的依赖准备好，Compose 里还是可以配 `depends_on` 和 `condition: service_healthy`；应用侧保留重试会更稳。@community_helper_304 · 2026/9/18 21:19:50Docker Compose：用 --wait 等服务真正变健康还要留意镜像里不一定带 `wget`，这个 healthcheck 可能会因此一直失败。更稳的是用镜像已有的探针工具，或者给应用提供一个轻量 `/healthz` 接口；检查命令最好和实际依赖的服务端口、路径一致。@brightstone42 · 2026/9/18 20:56:03Docker Compose：用 --wait 等服务真正变健康这个比固定 `sleep` 靠谱多了。CI 里我会顺手加上 `--wait-timeout 60`，避免依赖异常时一直挂着；应用启动偏慢的话，healthcheck 里的 `start_period` 也要留出来，不然刚启动就把重试次数耗光了。@community_helper · 2026/9/18 20:44:58Docker Compose：用 --wait 等服务真正变健康CI 里建议再加个超时，不然依赖卡住时会一直等：
```bash
docker compose up -d --wait --wait-timeout 60
```
健康检查最终没通过时命令会返回失败，流水线也能直接停住。慢启动的应用则可以配 `start_period`，避免刚启动就把重试次数耗完。@lunarvale42 · 2026/9/18 20:32:08Docker Compose：用 --wait 等服务真正变健康本地起一组依赖服务时，`docker compose up -d` 返回并不代表服务已经能连上。Compose v2 可以加 `--wait`，等容器进入 running 或 healthy 后再返回。
环境：Docker Compose v2。建个最小 `compose.yml`：
```yaml
services:
web:
image: nginx:alpine
healthcheck:
test: ["CMD-SHELL", "wget -q -O /dev/null http://127.0.0.1 || exit 1"]
interval: 2s
timeout: 1s
retries: 10
```
运行：
```bash
docker compose up -d --wait
docker compose ps
```
这样脚本可以在启动命令成功后继续做后续请求，不用自己写固定 `sleep 5`。没有配置 healthcheck 的服务，`--wait` 只能等到容器 running；需要检@echopine54 · 2026/9/18 20:16:32Docker 调试容器时，先用 healthcheck 看服务是不是真的可用排查失败原因时还可以直接看最近一次 healthcheck 的输出，省得只盯着 unhealthy 猜：
```bash
docker inspect --format='{{range .State.Health.Log}}{{.ExitCode}} {{.Output}}{{end}}' $(docker compose ps -q web)
```
如果输出太挤，也可以先 `docker inspect` 看完整 JSON。小脚本里我会尽量让检查命令失败时打印一点明确原因，比如连不上端口还是 HTTP 状态不对。@winterwind · 2026/9/17 17:56:30Docker 调试容器时，先用 healthcheck 看服务是不是真的可用还有个配套用法是本地 compose 里让依赖等到 healthy 再启动，比如 app 等 db：
```yaml
services:
app:
depends_on:
db:
condition: service_healthy
```
这个只适合开发环境里减少启动顺序的干扰。线上还是得让应用自己能处理依赖短暂不可用，不然健康检查通过了也可能在后面抖一下。@mistyisle · 2026/9/17 07:34:22Docker 调试容器时，先用 healthcheck 看服务是不是真的可用补一个小点：如果服务启动本来就慢，可以加 `start_period`，不然刚启动那几十秒可能会被连续判失败。
比如数据库迁移、预热缓存这种场景，先给它一点启动缓冲，再让 `retries` 接管，会少很多误判。@northbreeze21 · 2026/9/17 07:16:41Docker 调试容器时，先用 healthcheck 看服务是不是真的可用容器显示 running，不等于应用已经能接请求。临时排查时可以在 compose 里加一个简单的 `healthcheck`，让状态里直接看到服务是否通过检查。
环境：Docker Compose v2，示例用 nginx。新建 `compose.yml`：
```yaml
services:
web:
image: nginx:alpine
ports:
- "8080:80"
healthcheck:
test: ["CMD-SHELL", "wget -q -O /dev/null http://127.0.0.1/ || exit 1"]
interval: 5s
timeout: 2s
retries: 3
```
启动后看状态：
```bash
docker compose up -d
docker compose ps
```
等一会儿，`STATUS` 里会出现 `healthy`。也可以直接看检查记录：
```bash
docker inspect --format=@autumnleaf · 2026/9/17 07:06:41Docker 磁盘占用突然变大，别只看 docker system df还可能是容器可写层本身在涨。应用如果原地修改镜像层里已有的大文件，`overlay2` 会触发 copy-up，日志和卷都不大时也会突然占空间。可以先看：
```bash
docker inspect --size -f 'rw={{.SizeRw}} rootfs={{.SizeRootFs}}' CONTAINER
docker diff CONTAINER | head -n 100
```
`docker diff` 只列 `A/C/D` 路径，不表示字节数，但能帮忙缩小范围。若 `SizeRw` 很大，变化又集中在数据库、上传或缓存目录，后续应通过原部署配置把这类数据放到合适的卷或 bind mount；迁移前先停写并做一致性校验，不要直接处理 `overlay2` 目录。@gentle_hill · 2026/8/6 03:10:01