首页 > 其他分享 >Docker 笔记 - Docker 容器重启策略 --restart 介绍和实战

Docker 笔记 - Docker 容器重启策略 --restart 介绍和实战

时间:2024-07-23 09:30:51浏览次数:8  
标签:容器 04 03 -- 重启 nginx 2022 Docker restart

https://zhuanlan.zhihu.com/p/494370957

 

1. Docker 容器的重启策略

目的
为了保证容器运行时健壮性(自愈),Docker 提供了容器重启策略,即使用参数 --restart,它可以让容器在退出时自动尝试重启。

场景
Docker 容器的重启策略一般用于生产环境,开发环境和实验环境可以忽略。例如使用 Docker 运行 Nginx。Nginx 作为目前常用的 web 服务器,我们肯定更希望看到它在因停电、主机重启等意外事件中尝试自动恢复。

原理
Docker 容器的自动重启是由 Docker 守护进程完成的。在较老版本 Docker 中,如果 docker 守护进程重启,容器会全部挂掉。新版本 Docker 中,允许设置,当 docker 守护进程重启,容器不受影响。该场景比较多见,例如修改了 docker 的配置而需要重新加载 docker 守护进程,如果 docker 容器重启,业务会短暂中断,尤其是在生产环境这是不可接受的。所以这个设置很有必要。
具体设置方法有两种:
第一种,编辑 /etc/docker/daemon.json,添加 "live-restore": true :

{
    "live-restore": true,
}

第二种,命令启用

dockerd --live-restore systemd

Docker 容器的重启策略具体如下:

  • no
    默认策略,在容器退出时不重启容器。启动容器时不添加参数 --restart 即可。
  • on-failure
    在容器非正常退出时(退出状态非0),才会重启容器。
  • on-failure:n
    在容器非正常退出时重启容器,并且指定重启次数。n 为正整数。如果不指定次数,则会一直重启。
  • always
    只要容器退出就重启容器。
  • unless-stopped
    在容器退出时总是重启容器,但是 Docker 守护进程启动之前就已经停止运行的容器不算在内。

2. Docker 容器的退出状态码

Docker 容器也有退出状态码,这一点类似 Linux 命令。Docker 容器的重启策略就是基于状态码。具体如下:

  • 0
    表示容器正常退出。例如 stop 容器。
  • 非 0
    表示容器退出异常(退出状态码采用 chroot 标准)。例如执行 docker run 失败后的容器退出。
  • 125
    Docker 守护进程本身有错误。
  • 126
    容器启动后,要执行的默认命令无法调用。
  • 127
    容器启动后,要执行的默认命令不存在。
  • 其他命令状态码
    容器启动后在容器内部执行命令,该命令退出时的返回状态码,就作为容器的退出状态码

3. 获取 Docker 容器退出状态码的方法

3.1 使用命令 docker ps -a

该命令结果的第 5 列中 Exited 后面括号中的数字就是容器的退出状态码。如下所示,Exited (1) 33 minutes ago,1 就是这个容器的退出状态码。但是 1 并不是容器本身的退出状态码,而是容器中运行的命令执行失败后退出的状态码。在 Linux 系统定义的命令退出状态码中,1 表示未知,即系统不知道具体错误的原因。这时候就需要看具体的日志来判断。

[root@k8s-master /]# docker ps -a | grep nginx
3e64cad716c0   192.168.100.20:5000/mynginx:latest   "nginx"   36 minutes ago   Exited (1) 33 minutes ago    nginx-demo

3.2 使用 inspect 命令

inspect 命令是用来获取容器的命令,配合其他参数就能获取容器的退出状态码。如下所示,还是上面案例中的容器,获得其退出状态码为 1

[root@k8s-master /]# docker inspect 3e64cad716c0 --format='{{.State.ExitCode}}'
1

4. docker run 的 --restart 参数说明

  • --restart 选项通常只用于 detached 模式的容器。
    detached 即后台运行模式(类比 Linux 命令的前台运行和后台运行)。Docker容器的两种运行模式:Foreground,Detached。docker run 时添加了 -d 或者 -d=true 参数,就是后台模式运行。
  • --restart 选项不能与 --rm 选项同时使用。
    因为 --rm 选项只适用于 foreground 模式的容器。
  • 在 docker ps 查看容器时,对于使用了 --restart 选项的容器,其可能的状态只有 Up 或 Restarting 两种状态。

5. --restart 参数中的其他设定

猜测一下,--restart 的重启时间间隔是怎样的?这个参数会失效吗?又会在什么情况下失效?

来看实验:
启动一个 Nginx 容器,当它找不到配置文件时,Nginx 报错并且进程退出,容器也随之推出。此时该容器会尝试重启。

如下所示:

[root@k8s-master /]# docker run -d --name nginx-demo -p 8010:80 -v /data/nginx/html/:/usr/share/nginx/html/ -v /data/nginx/logs/:/var/log/nginx/ -v /data/nginx/conf/:/etc/nginx/ --restart=always 192.168.100.20:5000/mynginx:latest
3e64cad716c0d60e9249dc72c11cc5cc7ece42d3f69fcf276ff28fd84782ed89
[root@k8s-master /]#
[root@k8s-master /]# ls /data/nginx/*
/data/nginx/conf:
/data/nginx/html:
/data/nginx/logs:
error.log
[root@k8s-master /]#
[root@k8s-master /]# tail -f /data/nginx/logs/error.log
2022/03/30 04:00:54 [emerg] 1#0: open() "/etc/nginx/nginx.conf" failed (2: No such file or directory)
2022/03/30 04:00:55 [emerg] 1#0: open() "/etc/nginx/nginx.conf" failed (2: No such file or directory)
2022/03/30 04:00:55 [emerg] 1#0: open() "/etc/nginx/nginx.conf" failed (2: No such file or directory)
2022/03/30 04:00:56 [emerg] 1#0: open() "/etc/nginx/nginx.conf" failed (2: No such file or directory)
2022/03/30 04:00:57 [emerg] 1#0: open() "/etc/nginx/nginx.conf" failed (2: No such file or directory)
2022/03/30 04:00:58 [emerg] 1#0: open() "/etc/nginx/nginx.conf" failed (2: No such file or directory)
2022/03/30 04:01:02 [emerg] 1#0: open() "/etc/nginx/nginx.conf" failed (2: No such file or directory)
2022/03/30 04:01:08 [emerg] 1#0: open() "/etc/nginx/nginx.conf" failed (2: No such file or directory)
2022/03/30 04:01:21 [emerg] 1#0: open() "/etc/nginx/nginx.conf" failed (2: No such file or directory)
2022/03/30 04:01:47 [emerg] 1#0: open() "/etc/nginx/nginx.conf" failed (2: No such file or directory)
2022/03/30 04:02:39 [emerg] 1#0: open() "/etc/nginx/nginx.conf" failed (2: No such file or directory)
[root@k8s-master /]#
[root@k8s-master /]# docker stop nginx-demo
nginx-demo
[root@k8s-master /]#
[root@k8s-master /]# tail -f /data/nginx/logs/error.log
2022/03/30 04:00:56 [emerg] 1#0: open() "/etc/nginx/nginx.conf" failed (2: No such file or directory)
2022/03/30 04:00:57 [emerg] 1#0: open() "/etc/nginx/nginx.conf" failed (2: No such file or directory)
2022/03/30 04:00:58 [emerg] 1#0: open() "/etc/nginx/nginx.conf" failed (2: No such file or directory)
2022/03/30 04:01:02 [emerg] 1#0: open() "/etc/nginx/nginx.conf" failed (2: No such file or directory)
2022/03/30 04:01:08 [emerg] 1#0: open() "/etc/nginx/nginx.conf" failed (2: No such file or directory)
2022/03/30 04:01:21 [emerg] 1#0: open() "/etc/nginx/nginx.conf" failed (2: No such file or directory)
2022/03/30 04:01:47 [emerg] 1#0: open() "/etc/nginx/nginx.conf" failed (2: No such file or directory)
2022/03/30 04:02:39 [emerg] 1#0: open() "/etc/nginx/nginx.conf" failed (2: No such file or directory)
2022/03/30 04:03:39 [emerg] 1#0: open() "/etc/nginx/nginx.conf" failed (2: No such file or directory)
2022/03/30 04:04:39 [emerg] 1#0: open() "/etc/nginx/nginx.conf" failed (2: No such file or directory)

通过上面的实验,发现了几个很有意思的现象:

04:00:54,容器首次重启失败。
04:00:55,容器开始第一次尝试重启,直到第 5 次重启,每次重启时间间隔为 1 秒。
04:01:02,从第 6 次重启开始,时间间隔变为 3 秒。
04:01:08,从第 7 次重启开始,时间间隔变为 6 秒。
04:01:21,从第 8 次重启开始,时间间隔变为 13 秒。
04:01:47,从第 9 次重启开始,时间间隔变为 26 秒。
04:02:39,从第 10 次重启开始,时间间隔变为 52 秒。从这之后,时间间隔稳定变为 1 分钟。

从实验中我们推断出关于 --restart 重启策略中的一些设定:

  • 关于时间策略的设定:
    - 前 5 次时间间隔为 1 秒
    - 第 6 次开始时间间隔为之前的 2 倍。
    - 直到时间间隔超过 1 分钟时,后续的每一次重启的时间间隔都固定为 1 分钟。
  • 关于 --restart 策略失效的设定:
    - 当执行容器 stop 时, --restart 失效,容器不再尝试重启。实验中,重启日志一直停留在“2022/03/30 04:04:39”。

6. 容器启动时忘记使用 --restart=always 如何补救

6.1 使用 update 命令

[root@k8s-master /]# docker container update --restart=always 3e64cad716c0
3e64cad716c0

6.2 修改容器的配置文件

vim /var/lib/docker/containers/容器ID/hostconfig.json,找到关键字 RestartPolicy,将 no 改为 always
修改前:

"RestartPolicy:{"Name":"no","MaximumRetryCount":0}

修改后:

"RestartPolicy:{"Name":"always","MaximumRetryCount":0}

重启容器即可。如果无法修改容器的配置,可先将容器停止,修改配置文件后再启动。

7. 获取容器重启信息

查看容器重启次数

[root@k8s-master /]# docker inspect -f "{{ .RestartCount }}" 3e64cad716c0
13

查看容器最后一次的启动时间

[root@k8s-master /]# docker inspect -f "{{ .State.StartedAt }}" 3e64cad716c0
2022-03-30T04:04:39.87804495Z

 

编辑于 2022-04-07 11:40

标签:容器,04,03,--,重启,nginx,2022,Docker,restart
From: https://www.cnblogs.com/jiftle/p/18317560

相关文章

  • 源神,启动!马斯克开源史上最大模型Grok,参数高达3140亿,可商用!
    马斯克真不愧是源神,自开源X的推荐算法以及特斯拉智能驾驶算法后,又说到做到,开源旗下大模型Grok!代码和模型权重已上线GitHub。官方信息显示,此次开源的Grok-1是一个3140亿参数的混合专家模型,远超OpenAIGPT-3.5的1750亿。,就是说,这是当前开源模型中参数量最大的一个,遵照Apache......
  • 网站安全-CDN篇
    为了保证CDN不被恶意刷流量导致高额账单,可以对CDN做防护措施,或使用高防CDN。‍‍‍普通CDN普通CDN受到恶意攻击,也是会计费的。目前国内大部分CDN厂商都是这样的套路:即使你的CDN流量用完了,还是会继续计费(也就是先欠着),等到记账周期到了(例如次日)再提供账单给你,让你......
  • AI绘画入门实践 | Midjourney:画面权重控制
    在Midjourney中,使用两个连续的英文冒号::来进行分割与权重控制。作为分隔符使用在提示词中添加双冒号::表示让MJ将部分提示词单独考虑2d illustration, french fries, hot dog --v 62d illustration, french fries, hot:: dog --v 6作为权重......
  • BIG-SCAPE提取gbk文件时出错
    我在运行BiG-SCAPE时遇到以下错误。请帮忙。导入GenBank文件警告:未知产品“氰化氢”警告:未知产品“NRP-金属基团”警告:未知产品“类似膦酸盐”以314个文件开头提取序列的文件:0似乎我在从gbk文件中提取数据时遇到问题当BIG-SCAPE无法识别GenBank(......
  • bash: ls: command not found... Similar command is: 'lz'
     001、环境变量混乱出现如下问题[root@PC1~]#ls##基本命令调不起来bash:ls:commandnotfound...Similarcommandis:'lz'[root@PC1~]#vim~/.bashrc##vim编辑器也调不起来bash:vim:commandnotfound... 。......
  • AI盛行的今天还有必要学习数据分析吗?
    1.引言在过去十年中,人工智能(AI)技术以令人瞩目的速度发展,正在深刻改变我们的生活和工作方式。无论是自动驾驶汽车、智能家居,还是AI医疗诊断和金融市场预测,AI技术都在各个领域展现出强大的影响力。特别是在中国,AI技术的研究和应用取得了显著进展,政府和企业的高度重视使得中......
  • ssm乡村救助信息管理系统 计算机专业毕业设计源码44889
    摘要随着行业规模的不断壮大,信息变得越来越多。同时计算机网络技术高速发展,网络管理运用也变得越来越广泛。因此,建立一个BS结构的乡村救助信息管理系统来管理乡村救助信息,会使管理工作系统化、规范化,也会提高政府形象,提高管理效率。SSM乡村救助信息管理系统的主要使用者......
  • 如何实现可视化、智能化、自动化的文件采集?一文了解!
    内部数据文件采集需求在多个行业中都非常重要,以下是一些涉及此场景需求的行业:1.大数据行业:随着大数据的行业应用不断深入,物联网、智能家居、数字政务等领域的大数据技术应用逐渐成熟,数据采集的需求也将被逐步激发,带动数据采集软件及服务的市场规模日益增长。2.人工智能行业:在人......
  • C#开发的全屏图片切换效果应用 - 开源研究系列文章 - 个人小作品
          这天无聊,想到上次开发的图片显示软件《PhotoNet看图软件》,然后想到开发一个全屏图片切换效果的应用,类似于屏幕保护程序,于是就写了此博文。这个应用比较简单,主要是全屏切换换图片效果的问题。 1、项目目录;  2、源码介绍;1)类库部分源码;......
  • SUMA&国产海光平台服务器32DB16主板ECC内存对应表&故障内存定位
    32DB16主板内存映射关系,在ECC报错后,可参考LinuxHWError及EDAC等OS信息,定位出错内存所在位置。一、关于主板型号如何确认?方法一:可以使用以下命令在Linux系统进行查看,sudodmidecode-tbaseboard也可以使用cat/sys/class/dmi/id/board_vendorcat/sys/class/dmi/id/bo......