为什么需要健康检查机制？
健康检查机制是用来检查服务的可用性，当服务不可用时及时重启以恢复可用性。之前的文章《Kubernetes中配置livenessProbe、readinessProbe和startupProbe》讲解了Kubernetes中的各种健康检查类型和配置方法，本篇文章讲解一下docker容器的健康检查机制。
看过上文提到的那篇文章的同学型相信肯定能理解为什么需要对服务本身做健康检查。就以docker为例再解释一下，Docker Daemon用来运行和管理容器，本身会监控容器中PID为1的进程，其实在实际场景中仅监控PID为1的进程是不够的。例如当容器中的服产生死锁的情况，这时候服务虽然不能处理用户请求，但是PID为1的进程依然是运行状态。
Docker健康检查机制
Docker健康检查有两种方式：
- 在Dockerfile中使用HEALTHCHECK命令配置健康检查策略；
- 在启动容器时（docker run 命令）配置健康检查策略。
在Dockerfile中使用HEALTHCHECK命令配置健康检查策略
在Dockerfile中使用HEALTHCHECK声明健康检查策略，容器启动后就会自动进行健康检查。HEALTHCHECK支持下列选项：
- --interval=<间隔时间>：两次健康检查的间隔时间，默认30 秒；
- --timeout=<超时时间>：健康检查命令运行超时时间，如果超过这个时间，本次健康检查被视为失败，默认 30 秒；
- --retries=<重试次数>：当连续重试指定次数后，则将容器状态置为 unhealthy，默认 3 次。
- --start-period=<间隔>: 应用启动时间，不计启动过程中的健康检查失效情况，默认 0 秒。
使用示例如下:
from elasticsearch:latest
HEALTHCHECK --interval=5s --timeout=2s --retries=3 \
CMD curl --silent --fail localhost:9200/_cluster/health || exit 1在Dockerfile中HEALTHCHECK最好只写一个，如果写了多个，只有最后一个会有效。
CMD命令返回值有三种，如下
- 0，成功；
- 1，失败；
- 2，保留值，不要使用。
执行docker run后容器初始状态为starting，等待配置的interval时间后，开始执行健康检查。如果单次检查返回值不是0或者检查时间超过了timeout，本次检查被认为失败。如果健康检查连续失败次数超过了retries，状态就会变为unhealthy，健康检查结果一旦成功，容器就会被置为healthy状态。
在启动容器时（docker run 命令）配置健康检查策略
示例如下：
$ docker run --rm -d \
--name=es \
--health-cmd="curl --silent --fail localhost:9200/_cluster/health || exit 1" \
--health-interval=5s \
--health-timeout=2s \
--health-retries=3 \
elasticsearch:latest参数代表的意思和第一种方式中的相同，健康检查命令的输出存储在健康状态里，可以用docker inspect命令查看。
小结
本文介绍了Docker中两种原生的健康检查方式，使用起来非常方便。目前主流的容器编排框架也都自带了健康健康检查功能，这种情况下不需要使用Docker原生的健康检查方式。
