docker重启容器（docker重启容器失败）

本文目录一览：

• 1、unraiddocker自动重启
• 2、威联通docker重启配置
• 3、docker 容器自动启动run
• 4、重启docker命令(docker自动重启)
• 5、docker修改conf配置重启容器配置没有了

unraiddocker自动重启

为了保证容器运行时健壮性（自愈），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 容器的重启策略就是基于状态码。具体如下：

表示容器正常退出。例如 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

威联通docker重启配置

威联通docker重启配置

1、登录威联通管理后台，进入“Docker”页面；

2、点击“重启”按钮，重启docker容器；

3、点击“启动”按钮，启动docker容器；

4、点击“重新加载”按钮，重新加载docker容器的配置文件；

5、点击“更新”按钮，更新docker容器的环境变量；

6、点击“保存”按钮，保存docker容器的配置文件；

7、点击“应用”按钮，应用docker容器的配置文件；

8、点击“重启”按钮，重启docker容器，完成重启配置。

docker 容器自动启动run

部署项目服务器时，为了应对停电等情况影响正常web项目的访问，会把Docker容器设置为开机自动启动。

如果创建时未指定 --restart=always ,可通过update 命令设置

Docker容器的重启策略是面向生产环境的一个启动策略，在开发过程中可以忽略该策略。

Docker容器的重启都是由Docker守护进程完成的，因此与守护进程息息相关。

Docker容器的重启策略如下：

no，默认策略，在容器退出时不重启容器

on-failure，在容器非正常退出时（退出状态非0），才会重启容器

on-failure:3，在容器非正常退出时重启容器，最多重启3次

always，在容器退出时总是重启容器

unless-stopped，在容器退出时总是重启容器，但是不考虑在Docker守护进程启动时就已经停止了的容器

docker run的退出状态码如下：

0，表示正常退出

非0，表示异常退出（退出状态码采用chroot标准）

125，Docker守护进程本身的错误

126，容器启动后，要执行的默认命令无法调用

127，容器启动后，要执行的默认命令不存在

其他命令状态码，容器启动后正常执行命令，退出命令时该命令的返回状态码作为容器的退出状态码

通过--restart选项，可以设置容器的重启策略，以决定在容器退出时Docker守护进程是否重启刚刚退出的容器。

--restart选项通常只用于detached模式的容器。

--restart选项不能与--rm选项同时使用。显然，--restart选项适用于detached模式的容器，而--rm选项适用于foreground模式的容器。

在docker ps查看容器时，对于使用了--restart选项的容器，其可能的状态只有Up或Restarting两种状态。

示例：

补充：

查看容器重启次数

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

重启docker命令(docker自动重启)

1、怎样重启docker。

2、重启docker容器命令。

3、重启Docker。

4、docker 重启命令。

1."重启docker的方法，为您提供重启docker的方法视频及对应图文信息，docker的重启方法有两种：第一使用systemctlrestartdocker重启docker服务，第二使用dockerrestart容器id重启docker容器。

docker修改conf配置重启容器配置没有了

在Docker中，容器的配置和数据是分离的，因此在修改配置文件后需要重新启动容器才能生效。如果您修改了容器中的配置文件，但是重启容器后发现配置没有生效，可能是以下原因之一：

1. 容器中的配置文件不是您想要修改的文件：有些应用程序可能会从多个配置文件中读取配置，而您修改的可能不是正在使用的配置文件。您可以查看应用程序的文档或者配置文件来确定正确的配置文件位置。

2. 挂载配置文件的方式不正确：Docker可以通过挂载本地文件系统上的文件来替换容器中的文件。如果挂载的本地文件系统上的文件不是您想要使用的配置文件，或者挂载的路径不正确，那么容器中的配置文件将不会被替换。您可以通过检查`docker run`或`docker-compose`命令中的挂载路径是否正确来解决此问题。

3. Docker镜像缓存：Docker在构建容器时使用缓存，如果您在容器中增加了新的配置文件，但是没有更新Docker镜像，则容器使用的可能是旧的镜像，从而导致配置文件没有生效。您可以使用`docker-compose build --no-cache`命令来避免Docker镜像缓存的问题。

如果您已经确认修改了正确的配置文件，并且挂载路径也正确，那么您可以尝试使用以下步骤来解决问题：

1. 停止容器：`docker stop container_name`

2. 删除容器：`docker rm container_name`

3. 重新启动容器：`docker run --name container_name -v local_config_path:container_config_path image_name`

其中`local_config_path`是本地文件系统上的配置文件路径，`container_config_path`是容器中的配置文件路径，`container_name`是容器的名称，`image_name`是容器所使用的镜像名称。

通过这些步骤，您可以重新启动容器，并且使用新的配置文件。