Docker容器进程及生命周期

容器进程

Docker 的本质是进程

Docker 在启动容器的时候，会启动该容器进程。例如，当我们启动 Ubuntu 的容器时让容器运行 Bash Shell时：

这使得 Bash Shell 成为容器中运行且唯一运行的进程，列表中 PID 为 1 的进程，是容器所运行的 Bash Shell，第二个进程是查看所有进程命令 ps -elf 所产生的，是个临时进程，并且在输出之后就已经退出了。也就是说容器当前只有一个 Bash Shell 进程。

如果键入 exit 即退出 Bash Shell ，那么容器也会退出（终止）。原因是容器如果不运行任何进程则无法存在，杀死 Bash Shell 即杀死了容器中的主进程，导致这个容器也被杀死。

同时，可以通过一些组合键退出当前容器（Windows 下 ctrl + PQ ），切回 Docker 主机的 Shell，并不会终止容器的运行，并保持该容器在后台运行。

可以通过命令查看当前系统正在运行的容器列表和重新链接到容器中

1
2
3

docker container ls

docker container exec

再次进入该 Ubuntu 容器中会发现有两个 Bash 正在运行：

这意味着在当前 Shell 中输入 exit 并不会导致容器终止。

输入 exit 退出容器，并通过命令 docker container ps 来确认容器依然在运行中。

可以通过命令停止并删除容器：

1
2
3

docker container stop <conatiner>

docker container rm <conatiner>

容器在非持久化领域上的良好表现，并不意味着其不擅长持久化工作或持久化数据。

我们经常拿虚拟机和容器做比较，停止一个容器就像停止虚拟机一样，尽管它已经停止运行了，但是容器的全部配置和内容仍然保存在 Docker主机的文件系统当中，并可以随时启动。

总结一下容器的生命周期。可以根据需要多次停止、启动、暂停以及重启容器。

容器及其数据是安全的。直至明确删除容器前，容器都不会丢弃其中的数据。如果将容器数据存储在卷中，那么即便是删除了容器，数据也会被保存下来。

当我们使用 docker container rm <container> -f 来销毁运行中的容器时，不会发出任何警告，是一个相当暴力的过程，容器将被毫无征兆的被删除，应用也会一起被销毁。

相比而言， docker container stop <container> 就要温和许多了，该命令会提前想容器发送将要停止的警告消息，给予进程一些时间来有序有效的处理停止前要做的事儿，一旦 docker stop 命令返回后，就可以使用 rm 命令来删除容器了。

这背后的原理可以通过 linux/POSIX 信号来解释。docker container stop 命令向容器内的 PID 1 进程发送了 SIGTERM 这样的信号。

这会为进程预留一个清理并优雅停止的机会。

通常建议在运行容器时配置好重启策略。这是容器的一种自我修复能力，可以在指定事件或者错误后重启来完成自我修复。

重启策略应用于每个容器，可以作为参数被强制传入 docker-container run 命令中，或者在 Compose 文件中声明（在使用 Docker Compose 以及 Docker Stacks 的情况下）。

容器支持的重启策略包括 always、unless-stopped 和 on-failed。

always 策略是一种简单的方式。除非容器被明确停止，比如通过 docker container stop 命令，否则该策略会一直尝试重启处于停止状态的容器。

一种简单的证明方式是启动一个新的交互式容器，并在命令后面指定 –restart always 策略，同时在命令中指定运行 Shell 进程。

当容器启动的时候，会登录到该 Shell。退出 Shell 时会杀死容器中 PID 为 1 的进程，并且杀死这个容器。

但是因为指定了 –restart always 策略，所以容器会自动重启。