当构建Docker 容器时，需要注意PID 1 僵尸回收问题，那个问题会在你最不期望出现问题的时候，导致一些不期望的结果和看起来很困惑的问题。本文解释了PID 1问题，解释怎样解决它，并且作为一个预先构建的方案--可以作为一个基本的Docker镜像来使用。

当上面的问题解决了，你可能会想去读 第二部分：Docker基础镜像，胖容器 和 “把容器当虚拟机” 

介绍
大概一年前-回溯到Docker0.6 的时期-我第一次介绍Docker基础镜像。这是为了对Docker友好而修改的最小的Ubuntu 基础镜像。其他人可以 从Docker 登记下载Docker基础镜像并且把它作为他们自己镜像的基础镜像。

我们是早期的Docker使用者，用Docker来持续集成并且在Docker达到1.0版本之前，用作搭建开发环境的方式。为了解决一些使用 Docker能够解决的问题，我们开发了docker基础镜像。例如，Docker不会在某个恰当处理子进程的初始化进程下运行进程。以至于容器有可能结 束导致各种各样的问题僵尸进程。Docker 也不会做任何事情，以至于让重要的消息能够正常的被处理等等。

即使他们终止了进程，为什么僵尸进程是一件坏事 ？ 原始应用程序的内存已经被释放，对啊？这不仅仅是一个条目，你在ps中看到它了吗？

你是对的，原始应用程序的内存已经被释放。 但事实上，你还看到它在ps中，这意味着它仍然占用一些内核资源。 我参考Linux waitpid手册:

“只要一个僵尸进程通过等待没有在系统中被移除， 它就会在内核进程表中消耗一个位置，并且要是这个表被填满，那它就没办法创建一个新的进程。”
 

那么这怎么涉及到Docker？我们看到很多人在他们的容器里只运行一个进程，他们认为运行单进程，他们的工作就结束了。但是，这个进程写出来并不是为了 完全像init进程的行为。也就是说，非但没有恰当的收割被收容的孤儿进程，反而没准它还期望其他的init进程来正确地做那样的工作。

让我们来看看具体的例子.假设你的容器运行了一个web服务器，web服务器运行一个CGI，它是用bash写的脚本。CGI脚本调用grep.然 后web服务器决定CGI脚本运行的时间太长了并且杀死了这个脚本，但是grep 没有受影响并继续运行。当grep结束了，它成为了僵尸并且被PID 1收容（web服务器）。web服务器不知道grep，所以web容器不收割它，然后grep僵尸进程停留在系统中了。

这个问题也适用于其他状况。人们经常为第三方应用创建Docker容器--比如PostgreSQL--并且把这些应用当做灵魂进程在容器中运行。当你正 运行其他人的代码，你能确保这些应用接下来不会大量产生僵尸进程吗？如果你运行你自己的代码，并且你审计了类库。没发现问题。但是通常情况下还是应该运行 一个适当的init系统进程来阻止问题发生。

但是运行一个全初始化系统不会让container重量级并且像一个虚拟机吗？

一个初始化系统没有必要是重量级的，你可能很轻易地就想到了Upstart,Systemd,SysV等初始化系统。可能你认为完整的系统需要在容器中被启动。其实不是这样的。我们所说的“全初始化系统”，是没有必要的也不是令人满意的。

我所谈论的初始化系统是小的，它的唯一职责就是启动你的应用，并且收割收容的子进程。使用如此简单的初始化系统是完全符合Docker的哲学的。

一个简单的初始化系统

是否已经存在一个能够运行其他应用并且能够同时收割收容的子进程的软件？

有一个几近完美的解决方案，每个人都有--它是简单陈旧的bash. Bash正确的收割收容的子进程。Bash能够运行任何事。所以不是要把这些放到你的Dockerfile中...

CMD ["/path-to-your-app"]

 …你可能有兴趣用这个替代：

CMD ["/bin/bash", "-c", "set -e && /path-to-your-app"]

（-e 指令阻止bash把这个脚本当做简单的命令直接执行exec（））

这回导致如下处理层次结构：

但是不幸的是，这个程序有一个致命问题，它没有正确处理信号！假设你用kill发送SIGTERM信号给bash.Bash终止了，但是没有发送SIGTERM给它的子进程！

当bash结束了，内核结束整个容器中的所有进程。包扩通过SIGKILL信号没有被干净的终结的进程。SIGKILL不能被捕获，所以进程是没有办法干 净的终结。假设你运行的应用程序正忙于写文件；在写的过程中，应用被不干净的终止了这个文件可能会崩溃。不干净的终止是很坏的事情。很像把服务器的电源给 拔掉。

但是为什么要关心init进程是否被SIGTERM给终结了呢？那是因为docker stop 发送 SIGTERM信号给init进程了。“docker stop” 应该干净的停止容器，以至于稍后你能够用“docker start”启动它。

Bash专家现在可能会有兴趣写一个EIXT处理器，它简单的发送信号给子进程，像这样：

#!/bin/bash
function cleanup() { 
    local pids=`jobs -p`
    if [[ "$pids" != "" ]]; then        
        kill $pids >/dev/null 2>/dev/null    
    fi
} 
 
trap cleanup EXIT
/path-to-your-app

所以明显的一个更加复杂的解决方案是需要的。但是一个全初始化系统像 Upstart,Systemd 和SysV init对于轻量级的Docker容器来说就是赶尽杀绝。幸运的是，Baseimage-docker有一个解决方案。我们已经写了一个自定义的，轻量级 的初始化系统。特别是在Docker容器内。由于缺少一个好的名字，我们把这个程序叫做my init,一个350行最小资源使用率的Python程序。

my_init的一些关键特性：

• 收割收容的子进程

•  执行子进程

•  等待直到所有的子进程都终结了才结束自己，并且用最大超时时间。

• 记录活动到“docker日志文件”。
   

你可能会认为，我从来没有看到它出现，所以机会是很小的。但是墨菲定律说道，当事情可能会出错，那么它们就会出错。