Docker - 初始化，僵尸 - 为什么重要？

Question

我确实读过这篇文章:https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/

设置一些上下文:文章是关于容器中僵尸的问题，它试图让我们相信这是一个真正的问题。

总的来说，我的心情很复杂。为什么这有关系 ？毕竟，即使主机操作系统中的僵尸能够释放/杀死这个僵尸。我们知道容器中的进程从主机操作系统的角度来看是正常进程(并且通常容器中的进程是具有一些命名空间和 cgroup 的正常进程)。

此外，我们还可以找到为了避免僵尸问题我们应该使用bash -c ...的信息。为什么 ？也许，更好的选择是使用 --init ？

有人可以解释一下吗？

Answer 1

有关 init 进程为您提供什么的简短但有用的说明，请查看 tini这是 Docker 在您指定 --init

时使用的

Using Tini has several benefits:

• It protects you from software that accidentally creates zombie processes, which can (over time!) starve your entire system for PIDs (and make it unusable).
• It ensures that the default signal handlers work for the software you run in your Docker image. For example, with Tini, SIGTERM properly terminates your process even if you didn't explicitly install a signal handler for it.

这两个问题都会影响容器。容器中的进程仍然是宿主机上的进程，所以它占用宿主机上的一个 PID。无论您在容器中运行什么都是 PID 1，这意味着它必须安装一个信号处理程序才能获取该信号。

Bash 恰好包含一个进程收割器，因此在 bash -c 下运行命令可以防止僵尸进程。默认情况下，Bash 不会将信号处理为 PID 1，除非您 trap 它们。

僵尸

首先要了解的是 init 进程不会神奇地移除僵尸。 (正常)init 旨在当未能等待它们的父进程退出并且僵尸徘徊时收割僵尸。然后 init 进程成为僵尸父进程，它们可以被清理。

接下来，容器是在它们自己的 PID 命名空间中运行的一组进程。这个 cgroup 在容器停止时被清理。在 stop 上移除容器中的任何僵尸。他们没有到达主机init。

第三是使用容器的不同方式。大多数运行一个主进程，没有别的。如果产生了另一个进程，它通常是该主进程的子进程。所以直到父级退出，僵尸才会存在。然后看第 2 点(僵尸将在容器导出处被清除)。

在容器中运行 Node.js、Go 或 Java 应用服务器往往不会严重依赖进程的 fork 或派生。

运行像 Jenkins worker 这样的东西，它产生大量涉及 shell 的临时作业可能会导致更糟糕的情况，但它是短暂的，因此会定期退出并清理

运行一个 Jenkins master，它也会产生作业。容器可能会闲置很长时间并留下许多僵尸进程，这是一种在没有僵尸收割者的情况下可能会出现问题的工作负载。

信号

init 进程可以提供的另一个作用是安装信号处理程序，以便可以将主机发送的信号传递到容器进程。 PID 1 有点特殊，因为它需要进程监听信号才能接收。

如果您可以在您的 PID 1 进程中安装 SIGINT 和 SIGTERM 信号处理程序，那么 init 进程不会在此处添加太多内容。

何时使用初始化

当你想在一个容器中运行多个服务时

多个进程应该在一个 init 进程下运行。当 Docker 启动时，init 管理它们应该如何启动。容器真正“运行”它所代表的服务需要什么。当容器停止时，应该如何将其传递给每个进程。不过，您可能想要一个更传统的初始化系统，s6通过 s6-overlay为多进程管理提供了许多有用的容器特性。

当您运行一个产生大量子进程的进程时

尤其是当进程是children 的children 或超越的时候。 CI worker (如 Jenkins)示例是第一个想到 Java 生成命令或生成其他命令的 shell 的示例。

当您无法将信号处理程序添加到以 PID 1 运行的进程时。

sleep 就是一个简单的例子。 docker run busybox sleep 60 不能被 ctrl-c 中断或停止，它将在默认的 10 秒 docker stop 超时后被杀死。 docker run --init busybox sleep 60 按预期工作。

无论何时

tini 的开销非常小，并且被广泛使用，那么为什么大部分时间不使用 --init 呢？

更多详情见this github comment哪个回答了“为什么？”来自 tini 创作者的问题。