7.12 HEALTHCHECK 健康检查
7.12.1 基本语法
HEALTHCHECK [选项] CMD <命令>
HEALTHCHECK NONEHEALTHCHECK 指令告诉 Docker 如何判断容器状态是否正常。这是保障服务高可用的重要机制。
7.12.2 为什么需要 HEALTHCHECK
在没有 HEALTHCHECK 之前,Docker 只能通过 进程退出码 来判断容器状态。问题场景:
Web 服务死锁,无法响应请求,但进程仍在运行
数据库正在启动中,尚未准备好接受连接
应用陷入死循环,CPU 爆满但进程存活
引入 HEALTHCHECK 后: Docker 定期执行指定的检查命令,根据返回值判断容器是否 “健康”。
容器状态转换:
Starting ──成功──> Healthy ──失败N次──> Unhealthy
▲ │
└──────成功──────┘7.12.3 基本用法
Web 服务检查
命令返回值
0:成功 (healthy)1:失败 (unhealthy)2:保留值(不使用)
常用选项
--interval
两次检查的间隔
30s
--timeout
检查命令的超时时间
30s
--start-period
启动缓冲期(期间失败不计入次数)
0s
--retries
连续失败多少次标记为 unhealthy
3
7.12.4 屏蔽健康检查
如果基础镜像定义了 HEALTHCHECK,但你不想使用它:
7.12.5 常见检查脚本
HTTP 服务
使用 curl 或 wget:
数据库
自定义脚本
7.12.6 在 Compose 中使用
可以在 compose.yaml(或 docker-compose.yml)中覆盖或定义健康检查:
带健康检查的依赖启动:
7.12.7 查看健康状态
7.12.8 最佳实践
1. 避免副作用
健康检查会被频繁执行,不要在检查脚本中进行写操作或消耗大量资源的操作。
2. 使用轻量级工具
优先使用镜像中已有的工具(如 wget),避免为了健康检查安装庞大的依赖(如 curl)。
3. 设置合理的 Start Period
应用启动可能需要时间(如 Java 应用)。设置 --start-period 可以防止在启动阶段因检查失败而误判。
4. 只检查核心依赖
健康检查应主要关注 当前服务 是否可用,而不是检查其下游依赖(数据库等)。下游依赖的检查应由应用逻辑处理。
5. 与容器编排平台的关系
不同平台对 HEALTHCHECK 的支持有所不同:
Docker Compose:直接使用 Dockerfile 中定义的 HEALTHCHECK,也可在
compose.yaml中覆盖Docker Swarm:使用 HEALTHCHECK 进行服务健康判断和滚动更新决策
Kubernetes:忽略 Dockerfile 中的 HEALTHCHECK,使用自己的
livenessProbe和readinessProbe机制
如果应用同时部署在 Docker Compose 和 Kubernetes 环境中,建议在 Dockerfile 中保留 HEALTHCHECK(供 Compose 使用),同时在 Kubernetes 的 Pod 配置中定义对应的探针。
最后更新于