什么时候不使用 docker run --init答案

【问题标题】：When not to use docker run --init什么时候不使用 docker run --init
【发布时间】：2019-10-23 02:08:52
【问题描述】：

docker run 的--init flag 导致tini 初始化系统用作ENTRYPOINT。因此，在容器中运行的应用程序将成为 init 系统的子进程，以便它可以处理信号处理、僵尸收割等。

docker-compose 也有一个init: true 服务设置。

正如tini works transparently, Dockerfiles don't need to be modified in any way（这就是tini 文档所说的）。

所以我的问题是：

使用--init 有什么缺点吗？
在哪些情况下最好避免使用--init？
如果没有严重的缺点：为什么--init 不是默认设置？

【问题讨论】：

标签： docker

【解决方案1】：

使用 --init 标志没有缺点。但是，容器中 PID 为 1 的进程并不涵盖 init 进程的所有功能。在大多数情况下，这应该不是问题，因为您只需要 SIGNALS 处理和子进程处理。

什么情况下最好避免使用--init？

如果您编写应用程序来处理信号，例如在 NodeJS 中：

const registerSignals = () => {
process.on('SIGTERM', () => {
    console.log('SIGTERM received');
    shutDown(0);
});
process.on('SIGINT', () => {
    console.log('SIGTERM received');
    shutDown(0);
});
}

如果你没有僵尸进程可以收获或者你的收割僵尸自己处理

那么你可以避免使用 --init 或 tini （如果您希望上述 sn-p 工作，请确保在启动容器时使用 exec 表单）

如果没有严重的缺点：为什么 --init 不是默认设置？

因为像我的 sn-p 显示的那样让您的容器具有 SIGNAL 意识并不是那么困难，而且您可能有一些 PID 1 的特殊情况，tini 没有涵盖，因此没有充分的理由在所有容器中默认注入 tini。

编辑：添加了卡梅伦的建议

【讨论】：

1.) tini 没有涵盖哪些初始化系统功能？我找不到应该支持的规范。 2.) tini 将信号转发给它的孩子，因此信号感知应用程序应该可以工作（这不是避免使用 tini 的理由）。 3.) 有很多标准图像在没有 --init 的情况下无法正常运行。例如，MariaDB 的入口点脚本错误处理 SIGTERM；在 docker-compose 的上下文中，这会导致 MariaDB 在一段时间后被杀死。如果 tini 是默认值（特殊情况下可能加上 --no-init 标志），则不会发生此类问题。
当你运行一个没有 -p 或 --net=host 的容器时，它基本上没用。尽管如此，默认设置是不将任何端口映射到外部。基本上我要说的是让 docker 做太多不是一个好的解决方案。我再次认为在某些情况下你会想要拥有自己的 init 进程，因为 tini 不像 systemd
在我看来，这个答案应该提到，如果你自己处理信号，那么如果你没有僵尸进程来收割和/或你正在做自己的僵尸收割，那么你就不需要 Tini。我认为应该解释一下。