建议 Docker Compose 中 init: true 常备

关键点

在 Docker Compose (docker --init) 中设置 init: true 会为容器启用一个初始化进程，以正确处理信号和僵尸进程。
这在容器中很重要，因为主进程（PID 1）如果不处理僵尸进程可能会导致资源泄漏。
它在 Compose 文件版本 2.2 和 3.7 及以上版本中受支持，研究表明这是最佳实践。

我遇到了什么问题？

我之前利用 Puppeteer 实现了一个网页内容抓取服务，并通过 Docker 运行在云端服务器上。服务运行一段时间后，会出现奇怪的问题，如服务器出现高速读磁盘操作，导致假死状态，根本没法动，只能重启服务器。起初并不知道问题出在哪里，后来发现是 Puppeteer 存在大量异常连接，导致占用非常多的空间和操作，直至内存泄漏。在结合 GitHub 上的讨论（ProtocolError: Target.createTarget timed out）和分析后，感觉是因为什么东西导致连接中断而没能关闭，后续新的请求进来打开的又是新连接，这样就产生了大量闲置连接。

我通过改善 Puppeteer 的连接与关闭逻辑很大程度上避免了这个问题，但是长时间运行后，偶尔还是会出现这个问题。后来其他人提到，僵尸进程不会因为重启容器而被终结，建议使用 init: true 来清除僵尸进程，进一步保证稳定。原因是 Puppeteer 在运行时可能会生成子进程（如浏览器实例），如果这些子进程未被正确管理，可能会变成僵尸进程，积累资源泄漏。启用 init: true 可以确保这些子进程被正确清理，从而防止类似问题。

什么是 `init: true`？

init: true 是一个 Docker Compose 的配置选项，用于在服务容器中运行一个初始化进程。这个进程会作为容器的 PID 1，负责转发信号和清理已结束但未被父进程等待的僵尸进程。这确保了容器内的进程管理符合 Linux 系统的标准行为。

为什么这很重要？

在容器中，主进程通常是 PID 1。如果这个进程不是一个初始化进程（比如许多应用程序进程），它可能无法正确处理子进程的结束状态，导致僵尸进程积累，进而可能引发资源泄漏。启用 init: true 可以避免这些问题，尤其是在容器运行后台进程或需要正确信号处理的情况下。

一个意外的细节

你可能不知道的是，init: true 实际上使用了像 Tini 这样的轻量级初始化进程，这在 Docker 运行时是内置支持的，但通过 Compose 文件配置更方便。

详细介绍

来深入探讨 Docker Compose 中 init: true 的功能、用途及其技术背景，旨在为用户提供全面的理解。这部分内容将涵盖所有相关细节，包括历史背景、版本支持以及最佳实践。

背景与功能

Docker Compose 是一个用于定义和运行多容器 Docker 应用程序的工具。在其配置文件（通常为 docker-compose.yml）中，init: true 是一个服务级别的配置选项。它等同于在 docker run 命令中使用的 --init 标志，目的是在容器内运行一个初始化进程作为 PID 1。

这个初始化进程的主要作用是：

转发信号：确保容器内的进程能够正确接收和处理系统信号（如 SIGTERM、SIGINT），这对于优雅关闭容器至关重要。
清理僵尸进程：在 Unix-like 系统中，PID 1 负责回收已结束但未被父进程等待的子进程（即僵尸进程）。如果主进程不是初始化进程，僵尸进程可能会积累，导致资源泄漏。

例如，在一个运行数据库或 Web 服务器的容器中，如果有子进程（如日志收集器）结束但未被主进程等待，启用 init: true 可以确保这些进程被正确清理，从而保持系统稳定。

版本支持与历史

init: true 的引入经历了一些版本更迭。根据查询，最初在 Docker Compose 文件版本 2 中支持该选项，但随后在版本 3 中被移除。直到版本 3.7，它才重新被引入并稳定支持。此外，Docker Compose CLI 版本 1.25.0 也明确支持这一功能。

以下是关键版本信息：

Compose 文件版本 2.2：支持 init: true。
Compose 文件版本 3.0-3.6：不支持（曾被移除）。
Compose 文件版本 3.7 及以上：重新支持。

这意味着，如果你使用较新的 Compose 文件版本（例如 version: '3.7'），可以放心使用 init: true。以下是一个示例配置：

version: '3.7'
services:
  redis:
    image: redis
    init: true
    container_name: redis

技术细节：`PID 1` 问题与 `Tini`

在容器环境中，主进程通常是 PID 1，这与传统 Linux 系统中的 init 进程（通常是 systemd 或其他初始化系统）不同。许多应用程序（如 Node.js、Python 脚本）不是为 PID 1 设计的，它们可能不处理信号或僵尸进程。例如：

如果子进程结束但父进程未调用 wait() 或 waitpid()，子进程会变成僵尸进程，占用系统资源。
信号（如 SIGTERM）可能无法正确传递，导致容器无法优雅关闭。

为了解决这些问题，Docker 提供了 --init 选项，内部使用了一个轻量级初始化进程（如 Tini）。Tini 是一个开源工具，专门为容器设计，负责信号转发和僵尸进程清理。当你在 Compose 文件中设置 init: true 时，Docker 会自动在容器内运行 Tini 作为 PID 1，然后再启动你的主进程。

例如，假设你运行一个 Redis 容器：

没有 init: true：Redis 进程是 PID 1，可能无法处理子进程或信号。
有 init: true：Tini 作为 PID 1，Redis 作为其子进程，信号和僵尸进程问题得到解决。

最佳实践与使用场景

启用 init: true 被认为是容器化最佳实践，特别是在以下场景：

运行后台进程的容器：如数据库（MySQL、PostgreSQL）、消息队列（RabbitMQ）等，这些服务可能有多个子进程。
需要优雅关闭的应用程序：确保容器能正确响应 docker stop 命令，通过信号转发实现干净的关闭。
调试和生产环境：在生产环境中，资源管理尤为重要，init: true 可以减少潜在的资源泄漏。

然而，需要注意的是，并非所有容器都需要 init: true。如果你的容器只运行一个前台进程（如简单的 Web 服务器），且没有子进程，可能会觉得这个选项无足轻重。但为了遵循最佳实践，特别是在复杂应用中，启用它通常是明智的选择。

潜在争议与注意事项

虽然 init: true 被广泛推荐，但也有一些讨论点：

性能影响：Tini 是一个轻量级进程，但理论上会增加微小的资源开销（内存和 CPU）。不过，在现代容器化环境中，这种影响通常可以忽略。
兼容性：在较旧的 Docker Compose 版本或 Compose 文件版本中，init: true 可能不可用，需要升级到支持的版本。
与 Init 容器混淆：用户有时会将 init: true 与 Docker Compose 中的 Init 容器功能混淆。后者是另一种特性，类似于 Kubernetes 的 Init 容器，用于在主容器启动前运行初始化任务（如数据库迁移）。两者功能不同，init: true 专注于 PID 1 的进程管理。

关键信息总结

总结项	内容
功能	运行初始化进程（Tini）作为 PID 1，处理信号和僵尸进程
支持的 Compose 版本	文件版本 2.2 和 3.7 及以上
使用场景	运行后台进程的容器、需要优雅关闭的应用、资源管理严格的生产环境
潜在影响	微小资源开销（通常可忽略），需确保 Compose 版本支持
最佳实践	推荐在复杂容器中启用，特别是在生产环境中

意外发现

一个可能不为人知的细节是，init: true 的实现依赖于 Tini，这是一个专门为容器设计的轻量级初始化进程。Tini 的存在使得 ``Docker容器能够更接近传统Linux` 系统的行为，这在调试和生产环境中尤为重要。

结论

总的来说，init: true 是 Docker Compose 中的一个强大工具，旨在解决容器中 PID 1 相关的问题。通过启用它，你可以确保容器内的进程管理更加健壮，特别是在运行复杂应用或需要高可靠性场景下。它是容器化最佳实践的一部分，值得在支持的 Compose 文件版本中广泛使用。

关键引用：