Docker 容器健康检查（HEALTHCHECK）实战：让编排系统及时发现假活

很多服务进程还在、端口也开着，业务其实已经卡死。没有健康检查时，编排或负载均衡会一直把流量打到「假活」实例上。Docker 原生 HEALTHCHECK 能把这种状态暴露出来。

1. 在 Dockerfile 里声明

FROM nginx:1.25-alpine
COPY conf/nginx.conf /etc/nginx/nginx.conf
HEALTHCHECK --interval=30s --timeout=3s --start-period=10s --retries=3 \
  CMD wget -qO- http://127.0.0.1/healthz || exit 1

含义简要说明：

• interval：检查间隔
• timeout：单次检查超时
• start-period：启动宽限期，期间失败不计入 retries
• retries：连续失败几次才标为 unhealthy

2. 运行时覆盖

不改镜像也能加：

docker run -d --name web \
  --health-cmd='curl -fsS http://127.0.0.1:8080/ready || exit 1' \
  --health-interval=20s \
  --health-retries=3 \
  myapp:latest

3. 查看状态

docker ps
docker inspect --format='{{json .State.Health}}' web | jq .

状态一般是 starting → healthy / unhealthy。编排（Swarm、K8s 的 readiness/liveness 思路类似）可据此摘除实例。

4. 常见坑

• 健康检查命令依赖的工具镜像里没有（如没有 curl），要改用 wget 或装最小客户端。
• 检查地址写了 localhost 但应用只绑了容器外网卡，或反过来。
• 检查过重（打真实业务接口、写库），会放大负载；优先用轻量 /healthz / /ready。
• start-period 太短，冷启动慢的 JVM 服务会反复被判失败。

小结

先给应用提供廉价、稳定的健康接口，再在镜像或 docker run 上挂上 HEALTHCHECK。这样假活能被及时发现，排障时 docker inspect 的 Health 日志也比只看进程是否存在靠谱得多。