即使容器状态是 UP ，也不能保证应用没有问题。web server 虽然没有崩溃，但如果总是返回 HTTP 500 - Internal Server Error ，对应用来说这就是很严重的故障。 如何从应用的业务层面检查容器的状态呢？ 答案是：Health Check。 Docker 支持的 Health Check 可以是任何一个单独的命令，Docker 会在容器中执行该命令，如果返回 0，容器被认为是 healthy ，如果返回 1，则为 unhealthy 。 对于提供 HTTP 服务接口的应用，常用的 Health Check 是通过 curl 检查 HTTP 状态码，比如：

curl --fail http://localhost:8080/ || exit 1

如果 curl 命令检测到任何一个错误的 HTTP 状态码，则返回 1，Health Check 失败。

下面我们通过例子来演示 Health Check 在 swarm 中的应用。

docker service create --name my_db \
       --health-cmd "curl --fail http://localhost:8091/pools || exit 1" \
       couchbase

--health-cmd Health Check 的命令，还有几个相关的参数：

--timeout 命令超时的时间，默认 30s。

--interval 命令执行的间隔时间，默认 30s。

--retries 命令失败重试的次数，默认为 3，如果 3 次都失败了则会将容器标记为 unhealthy 。swarm 会销毁并重建 unhealthy 的副本。

通过 docker ps 可以查看到容器的状态为 healthy ：

下面模拟一个 unhealthy 的场景， curl 指向一个不存在的 url。

docker service create --name my_db \
       --health-cmd "curl --fail http://localhost:8091/non-exist || exit 1" \
       couchbase

副本被 shutdown 了，可以到 swarm-worker1 用 docker inspect 查看具体原因。

root@swarm-worker1:~# docker inspect my_db.1.saebvmn7aql2l2n4kgp6s1lui

容器被标记为 unhealthy ，其原因是 curl 连续三次返回 404 错误。

Docker 默认只能通过容器进程的返回码判断容器的状态，Health Check 则能够从业务角度判断应用是否发生故障，是否需要重启。

Health Check 就讨论到这里， 下一节我们学习如何在容器中使用密码，私钥这类敏感数据 。

1.《每天5分钟玩转Docker容器技术》
https://item.jd.com/16936307278.html

2.《每天5分钟玩转OpenStack》
https://item.jd.com/12086376.html [ 云原生 | Docker ] 构建高可用性的 SQL Server：Docker 容器下的主从同步实现指南 开发专题 | 2：如何在 docker 容器内部运行 docker命令