Dockerfile HEALTHCHECK健康检查

Dockerfile中使用HEALTHCHECK的形式有两种:

  1、HEALTHCHECK [options] CMD command
  2、HEALTHCHECK NODE 意思是禁止从父镜像继承的HEALTHCHECK生效 
下面我们主要介绍第一种形式的应用: 
options的可设定参数:

  interval:间隔(s秒、m分钟、h小时),从容器运行起来开始计时interval秒(或者分钟小时)进行第一次健康检查,随后每间隔interval秒进行一次健康检查;还有一种特例请看timeout解析。

  --start-period=DURATION 启动时间, 默认 0s, 如果指定这个参数, 则必须大于 0s ;--start-period 为需要启动的容器提供了初始化的时间段, 在这个时间段内如果检查失败, 则不会记录失败次数。 如果在启动时间内成功执行了健康检查, 则容器将被视为已经启动, 如果在启动时间内再次出现检查失败, 则会记录失败次数。

  timeout:执行command需要时间,比如curl 一个地址,如果超过timeout秒则认为超时是错误的状态,此时每次健康检查的时间是timeout+interval秒。
  retries:连续检查retries次,如果结果都是失败状态,则认为这个容器是unhealth的

CMD关键字后面可以跟执行shell脚本的命令或者exec数组。CMD后面的命令执行完的返回值代表容器的运行状况,可能的值:0 health状态,1 unhealth状态,2 reserved状态,这个没细研究,用的也很少。 
注意:在Dockerfile中只能有一个HEALTHCHECK指令。如果您列出多个,则只有最后一个HEALTHCHECK将生效。

下面我们进行几个测试: 
我手里有一个nginx的镜像,我们以它为base镜像进行一些简单的测试,以下是我的Dockerfile和测试脚本。

通过Dockerfile可以预计,容器启动10s内HEALTCHECK的状态为starting,10s后为healthy状态。脚本是监听容器的80端口,存在返回0,不存在返回1。

执行1、docker build -t test_nginx:2生成镜像 
       2、docker run -d test_nginx:2 启动容器。 
  3、通过docker ps查看HEALTHCHECK的状态 

验证:10s内health状态为starting,10s后状态为healthy 
下面我们需要进到容器把nginx服务停掉,然后观察health的状态,预计变成unhealthy使用时间为30s(关于时间上不好展示,有兴趣的话可以自己去做测试)

登到容器先确认80端口存在,停掉nginx服务,80端口消失,查看容器health状态 

验证:关掉nginx服务后,脚本检测到80端口不存在,返回1,容器状态为unhealthy(应该是执行了三次这个脚本得到结果都是1才确认这个容器是不健康的)

关于上面变成unhealthy状态使用了30s的时间,认真看的同事可能会发现不应该是timeout+interval秒后变吗。我的command是执行一个脚本,很快就能得到结果,不存在timeout的情况,所以我设置timeout的意义并不大。 
如果我这样设置HEALTHCHECK –interval=10s –timeout=3s –retries=3 CMD curl http://192.168.30.5:5000/v2。可能会出现curl这个地址3秒内没响应则认为失败,然后再开始interval的时间进行下次检测。最后显示unhealthy的状态应该是39s。这就不做测试了。

下面分享一个指令,通过docker指令得到指定容器id的健康状态 
docker inspect –format ‘{{json .State.Health.Status}}’ 41f1414fab75

原文地址:https://www.cnblogs.com/shawhe/p/11126450.html

时间: 2024-07-30 19:42:00

Dockerfile HEALTHCHECK健康检查的相关文章

docker容器HEALTHCHECK 健康检查

docker容器的健康检测是在编写dockerfile时,将检测机制写入到dockerfile中,基于此docerfile生成的镜像,在运行容器时会有健康检测的功能. dockerfile中的格式: HEALTHCHECK [选项] CMD <命令>:设置检查容器健康状况的命令. HEALTHCHECK NONE:如果基础镜像有健康检查指令,使用这行可以屏蔽掉其健康检查指令. HEALTHCHECK 指令是告诉 Docker引擎应该如何进行判断容器的状态是否正常,这是 Docker 1.12

docker HealthCheck健康检查

需求 最近遇到的问题:线上跑的一个 Node 镜像是在运行的,状态为 up ,但是访问报 502 ,重启镜像无效,重新拉了个镜像运行才恢复正常.于是想研究下如何从应用层面去检查容器的状态 为什么 docker ps STATUS 列显示容器的状态 [[email protected] ~]# docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 1cfb357dd83f 9962e62376bc "/bin/sh -

容器HEALTHCHECK指令对接ASP.NET Core健康检查能力

 写在前面 HealthCheck 不仅是对应用程序内运行情况.数据流通情况进行检查, 还包括应用程序对外部服务或依赖资源的健康检查. 健康检查通常是以暴露应用程序的HTTP端点的形式 实施,可用于配置健康探测的的场景有 : 容器或负载均衡时 探测应用的状态, 例如:容器探测到应用unhealthy可 终止后续的滚动部署或者重启容器:负载均衡器探测到实例healthyunt能将请求路由到健康的运行实例. 对应用程序种依赖的第三方服务进行健康探测,比如redis.database.外部服务接口 内

Docker 健康检查功能

Docker1.12及以上版本,自带了健康检查功能.通常情况下只能使用docker ps 来查看容器是否是up的状态,但是服务是否正常我们不可知,而健康检查功能,可以允许我们在容器中执行一些健康检查的命令,然后将容器的状态在"STATUS"中标识: [[email protected]]# docker ps CONTAINER ID        IMAGE                        COMMAND             CREATED             

docker 构建带健康检查的redis镜像

=============================================== 2018/11/5_第1次修改                       ccb_warlock =============================================== 由于希望引入docker的健康检查,即对不健康容器的策略(如果容器进入 unhealthy 状态,它会停止容器并且重新启动一个新容器来取代它),故根据官方给出的脚本进行修改后构建出带健康检查的redis镜像.

k8s的Health Check(健康检查)

强大的自愈能力是 Kubernetes 这类容器编排引擎的一个重要特性.自愈的默认实现方式是自动重启发生故障的容器.除此之外,用户还可以利用 Liveness 和 Readiness 探测机制设置更精细的健康检查,进而实现如下需求: 零停机部署. 避免部署无效的镜像. 更加安全的滚动升级. 下面通过实践学习 Kubernetes 的 Health Check 功能. 1.默认的健康检查 我们首先学习 Kubernetes 默认的健康检查机制: 每个容器启动时都会执行一个进程,此进程由 Docke

k8s之健康检查(Health Check)

强大的自愈能力是 Kubernetes 这类容器编排引擎的一个重要特性.自愈的默认实现方式是自动重启发生故障的容器.除此之外,用户还可以利用 Liveness 和 Readiness 探测机制设置更精细的健康检查,进而实现如下需求: 零停机部署. 避免部署无效的镜像. 更加安全的滚动升级. 下面通过实践学习 Kubernetes 的 Health Check 功能. 默认的健康检查 首先学习 Kubernetes 默认的健康检查机制: 每个容器启动时都会执行一个进程,此进程由 Dockerfil

k8s健康检查(9)

一.默认的健康检查 强大的自愈能力是 Kubernetes 这类容器编排引擎的一个重要特性.自愈的默认实现方式是自动重启发生故障的容器.除此之外,用户还可以利用 Liveness 和 Readiness 探测机制设置更精细的健康检查,进而实现如下需求: (1)零停机部署. (2)避免部署无效的镜像. (3)更加安全的滚动升级. 每个容器启动时都会执行一个进程,此进程由 Dockerfile 的 CMD 或 ENTRYPOINT 指定.如果进程退出时返回码非零,则认为容器发生故障,Kubernet

springCloud(6):Eureka的自我保护模式、多网卡下的IP选择、Eureka的健康检查

一.Eureka的自我保护模式 进入自我保护模式最直观的体现就是Eureka Server首页的警告,如下图: 默认情况下,如果Eureka Server在一定时间内没有接收到某个微服务实例的心跳,Eureka Server将会注销该实例(默认90秒).但是当网络分区故障发生时,微服务与Eureka Server之间无法正常通信,这就可能变得非常危险了----因为微服务本身是健康的,此时本不应该注销这个微服务. Eureka Server通过"自我保护模式"来解决这个问题----当Eu