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 -c 'apk upg…"   3 months ago        Exited (0) 3 months ago                                goofy_engelbart
91697fe789ee        3b6417bca798                                        "/bin/sh -c 'apk upg…"   3 months ago        Exited (99) 3 months ago                               lucid_swirles
2004c9aa5efc        172.18.11.161/lzwd/jdk1.8:v1                        "tini -- /bin/sh"        3 months ago        Up 3 months                                            elastic_proskuriakova

命令显示:

  1. 在运行的,状态为 up
  2. 正常停止的,状态为 Exited (0)
  3. 因发生故障停止了,退出代码为非0,例如Exited (99) Exited (1)

即使是状态为 up 的状态,也不代表业务就是正常的。如我们遇到的就是,状态为 up ,访问却提示 502。所以如何从应用层面去检查容器的状态呢?引出healcheck

怎么做

对于 HTTP 服务接口的容器,使用 curl 检查 HTTP 状态码

例如每10分钟检测一次,超时5秒就报超时:

HEALTHCHECK --interval=10m --timeout=5s   CMD curl --fail http://localhost:8080/ || exit 1

当指定了 healthcheck 指令启动容器后,初始状态会为 starting ,在 healtheck 指令检查成功后,状态会变为 healthy,检查成功,状态会变成 unhealthy

原文地址:https://www.cnblogs.com/fsckzy/p/11835210.html

时间: 2024-10-07 03:53:24

docker HealthCheck健康检查的相关文章

Docker Kubernetes 健康检查

Docker Kubernetes 健康检查 提供Probe探测机制,有以下两种类型: livenessProbe:如果检查失败,将杀死容器,然后根据Pod的重启策略来决定是否重启. readinessProbe:如果检查失败,Kubernetes会把Pod从服务代理的分发后端剔除. Probe支持以下三种检查方法: httpGet 发送HTTP请求,返回200-400范围状态码为成功. exec 执行Shell命令返回状态码是0为成功. tcpSocket 发起TCP Socket建立成功.

docker容器HEALTHCHECK 健康检查

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

Dockerfile HEALTHCHECK健康检查

Dockerfile中使用HEALTHCHECK的形式有两种: 1.HEALTHCHECK [options] CMD command 2.HEALTHCHECK NODE 意思是禁止从父镜像继承的HEALTHCHECK生效 下面我们主要介绍第一种形式的应用: options的可设定参数: interval:间隔(s秒.m分钟.h小时),从容器运行起来开始计时interval秒(或者分钟小时)进行第一次健康检查,随后每间隔interval秒进行一次健康检查:还有一种特例请看timeout解析.

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

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

Docker 健康检查功能

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

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

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

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

Oracle SQL 调优健康检查脚本

Oracle SQL 调优健康检查脚本 我们关注数据库系统的性能,进行数据库调优的主要工作就是进行SQL的优化.良好的数据架构设计.配合应用系统中间件和写一手漂亮的SQL,是未来系统上线后不出现致命性能问题的有力保证. 在CBO时代,一个SQL的执行计划是多样的.影响执行计划的因素也从过去RBO时代的SQL书写规则变为综合性因素.这为我们生成更加优秀执行计划提供了基础,同时也给我们进行调优带来的很多麻烦. 目前我们通常的做法,是通过AWR报告或者调试手段,发现某某SQL有问题,之后从Librar