LINUXSHELL代码，如何判断容器是否在运行

LINUX SHELL代码，如何判断容器是否在运行，没有运行就自动启动？

假设容器名为my_container，可以使用以下Shell脚本来实现：

LINUXSHELL代码，如何判断容器是否在运行

#!/bin/bash

# 检查容器是否在运行

if [ "$(docker inspect -f '{{.State.Running}}' my_container 2>/dev/null)" == "true" ]; then

echo "Container is running"

else

# 启动容器

docker start my_container

echo "Container has been started"

fi

这段脚本会首先使用 docker inspect 命令检查容器是否在运行，如果容器正在运行，则打印一条消息并退出。如果容器没有运行，则使用 docker start 命令启动容器，并打印一条消息表示容器已经启动。

docker容器启动自动启动shell脚本

1、先将容器打包成镜像

2、start.sh

3、制作dockerflie

构建镜像lnmp:6

启动容器

进入容器查看nginx、php-fpm进程

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

1、怎样重启docker。

2、重启docker容器命令。

3、重启Docker。

4、docker 重启命令。

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

linux安装docker后启动docker后主机重启

在 Linux 系统中，安装 Docker 后启动 Docker 服务，如果主机重启，系统将会自动重新启动 Docker 服务并恢复容器的状态。这是因为 Docker 服务是作为系统服务来运行的，并且默认使用 systemd 来管理服务。在系统重启时，systemd 会自动启动 Docker 服务，并加载先前的容器状态。这意味着您不必再手动启动 Docker 服务和容器了，这可节省时间和精力。但是请注意，如果您在主机重启之前未保存容器数据，则该数据可能会丢失。因此，一定要确保您已经保存了重要的容器数据。

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容器自动启动及修改配置文件

创建容器时没有添加参数 --restart=always ，导致的后果是：当 Docker 重启时，容器未能自动启动。

现在要添加该参数怎么办呢，方法有二：

1、Docker 命令修改

docker container update --restart=always 容器名字

2、直接改配置文件（经测试后无效，修改配置文件后，启动容器后，该参数有自动变成了no，修改不生效）

修改docker容器的挂载路径

修改config的Source的配置路径

启动docker服务

启动所有docker容器

修改docker默认的存储位置

查看默认的docker存储路径

停止所有docker容器

停止docker服务

打包docker目录

修改docker默认的存储位置

查看修改后docker存储路径