强制异常容器重启,让你的Docker锦上添花

云计算
在没有HEALTHCHECK指令之前,Docker只能通过process是否退出来判断container的状态,不过有时候服务已经无法正常运作了,但process没有退出,这样会导致该服务仍然可以接收用户请求,但是无法正常响应。我们需要对这种容器进行识别并自动重启。

今天我们接着上次的docker健康检查机制那篇文章,讲述一下如何给不健康的容器进行重启。另外有读者反馈有几个参数不是很理解,我们会在这篇文章里再补充讲解一下。

Docker在1.12版本之后提供了HEALTHCHECK指令,可以设定一行command用来判断服务的状态是否正常,这样可以更准确地判断服务状态。

HEALTHCHECK Container启动后的初始状态为starting,在指令检查成功后,状态会更改为healthy,如果连续失败超过指定次数则会改为unhealthy。看下HealthCheck的工作机制。

HEALTHCHECK参数选项:

--interval: Health check时间间隔,预设为30秒

--timeout:当Health check超过此设定的时间,则会视为失败,预设为30秒

--retries:当Health check连续失败次数超过此设定时,则会将状态更改为,预设为3次unhealthy

--start-period:启动时间,预设为0秒

HEALTHCHECK可以通过Dockerfile或是docker-compose.yml设定:

Dockerfile 示例

在Dockerfile中,HEALTHCHECK指令格式为

HEALTHCHECK [options] CMD <command>

<command>可以是shell指令或是exec格式(和其他Dockerfile指令相同,可以参考ENTRYPOINT)。而一个Dockerfile中只能有一个HEALTHCHECK指令,如果同时有多个HEALTHCHECK指令,则只有最后一个有效。

<command>的返回值代表container的状态:

0:成功,container is healthy

1:失败,如果失败超过指定次数,则container为unhealthy

2: reserved,不要使用这个值

假设我们的container服务是web服务,我们可以使用来检查服务是否正常运行,例如:每30秒检查一次是否可在5秒内响应请求:curl http://localhost:3000

# ...


HEALTHCHECK --interval=30s --timeout=5s --retries=5 --start_period=30s \
  CMD curl -fs http://localhost:3000/ || exit 1


# ...

Docker-compose 示例

docker-compose.yml的healthcheck,示例如下:

version: "3.7"
services:
  api:
    restart: always
    image: api
    container_name: api
    ports:
      - 3000:3000
    build:
      context: ./api
    healthcheck:
      test: curl -fs http://localhost:3000/ || exit 1
      interval: 30s
      timeout: 5s
      retries: 5
      start_period: 30s
    networks:
      - net
networks:
  net:
    name: net
    driver: bridge

其中test必须是string或list.如果是list,第一个item必须是NONE,或CMD-SHELL。如果是string,则等同于CMD-SHELL。

确认健康状态

在设定好health check指令之后,接着启动container,检查container状态时可以看到初始状态是:health: starting

$ docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS                            PORTS                       NAMES
6c7b9ca321d2        api:1.0.0           "uwsgi --ini /home/d…"   5 seconds ago       Up 2 seconds (health: starting)   0.0.0.0:3000->3000/tcp      api

过30秒之后再执行一次docker ps,可以看到container的状态变成:healthy

$ docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS                            PORTS                       NAMES
6c7b9ca321d2        api:1.0.0           "uwsgi --ini /home/d…"   35 seconds ago      Up 32 seconds (healthy)           0.0.0.0:3000->3000/tcp      api

而如果连续失败超过指定次数,状态会变成unhealthy。

关键步骤:重新启动不正常的容器

以上的步骤只有检查container的健康状态,但没有针对unhealthy container做任何处理,这部分我们可以搭配docker-autoheal来重启unhealthy container。先看下AutoHeal的工作机制。

autoheal可以直接使用docker执行,或是写在docker-compose中:

使用 docker 指令:

$ docker run -d \
    --name autoheal \
    --restart=always \
    -e AUTOHEAL_CONTAINER_LABEL=all \
    -v /var/run/docker.sock:/var/run/docker.sock \
    willfarrell/autoheal

使用docker-compose指令:

version: "3.7"
services:
  autoheal:
    restart: always
    image: willfarrell/autoheal
    container_name: autoheal
    environment:
      - AUTOHEAL_CONTAINER_LABEL=all
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock

然后执行 docker-compose up -d autoheal 就可以启动。

启动之后可以通过docker ps观察unhealthy的容器是否重启了。也可以查看autoheal的日志查看是否有启动记录。

最后再给大家介绍一种模拟unhealthy的方法,正常情况下都是healthy的,可以通过修改命令来模拟unhealthy。比如模拟mysql的服务,我们可以使用如下命令。

test: ["CMD", "nc -vz localhost 3307 || exit 1"]

正常监听3306端口,我们用3307连接检查,就会一直处于unhealthy状态,这个时候我们可以通过autoheal的日志观察到对mysql容器的重启。

有了这个机制,以后docker假死的情况就可以自动重启了。这个检查和自动重启机制对于数据库或者tomcat服务都非常有用。如果使用过程中有什么问题也欢迎发消息给我们。

责任编辑:华轩 来源: 微技术之家
相关推荐

2014-02-09 14:49:51

云计算网络IT

2011-12-31 08:58:04

服务器重启Unix

2019-05-07 08:50:11

开源工具Kubernetes容器

2024-02-26 18:11:08

Docker容器镜像

2021-07-01 10:03:55

Distroless容器安全

2009-10-10 14:07:43

2014-12-26 09:52:08

Go

2019-08-19 08:00:00

服务器Ubuntu Live漏洞

2017-02-10 11:00:59

Windows服务器filebeat

2012-09-20 15:11:31

Unix服务器

2018-04-24 10:05:13

Docker工具交付

2023-08-28 10:54:09

容器Docker

2021-07-15 09:47:20

Docker容器命令

2011-09-05 14:00:12

容错服务器stratus

2019-05-14 14:27:36

KubernetesDocker存储

2018-08-27 06:58:06

无线路由器WiFi网络

2020-04-26 15:38:28

Docker容器

2024-02-26 16:40:58

2016-03-28 09:39:54

2023-12-13 18:46:51

Docker容器进程
点赞
收藏

51CTO技术栈公众号