使用Dock基础镜像解决PID1问题.docxVIP

使用Dock基础镜像解决 PID 1 问题,让僵尸进程瞑目而去当构建Docker 容器时，需要注意PID 1 僵尸回收问题，那个问题会在你最不期望出现问题的时候，导致一些不期望的结果和看起来很困惑的问题。本文解释了PID 1问题，解释怎样解决它，并且作为一个预先构建的方案--可以作为一个基本的Docker镜像来使用。介绍大概一年前-回溯到Docker0.6 的时期-我第一次介绍Docker基础镜像。这是为了对Docker友好而修改的最小的Ubuntu 基础镜像。其他人可以 从Docker 登记下载Docker基础镜像并且把它作为他们自己镜像的基础镜像。我们是早期的Docker使用者，用Docker来持续集成并且在Docker达到1.0版本之前，用作搭建开发环境的方式。为了解决一些使用Docker能够解决的问题，我们开发了docker基础镜像。例如，Docker不会在某个恰当处理子进程的初始化进程下运行进程。以至于容器有可能结束导致各种各样的问题僵尸进程。Docker 也不会做任何事情，以至于让重要的消息能够正常的被处理等等。然而，我们已经发现很多人对我们解决的问题理解上有问题。Granted，是Unix操作系统底层很少人知道和理解的系统级机制。所以在本文中我们将会详细描述这个我们已经解决了的最重要的PID 1僵尸进程问题。Zombies我们发现：我们解决的问题适用于很多人大多数人甚至没有意识到这些问题，所以很多事情会以意想不到的方式被打断（墨菲定律）如果每个人都一遍又一遍的重复解决这些问题是低效率的。所以我们在空闲时间，把解决方案提取为每个人可以复用的基础镜像：Baseimage-docker.这个镜像也加入了一些有用的，相信大多数Docker镜像开发者都需要的工具。我们把Baseimage-docker作为我们所有Docker镜像的一个基础镜像。社区看起来喜欢我们所做得事情：我们是Docker注册处最流行的第三方镜像。只是排在了官方的Ubuntu和CentOServer镜像下面。PID 1 问题: 进程僵尸回想一下Unix的进程是一个有序的树。每个进程可以派生子进程，每个进程具有一个除了最顶层以外的父进程。这个最顶层的进程是init进程。它是当你启动系统时由内核启动。这个init进程负责启动系统的其余部分，如启动SSH服务，从启动Docker守护进程，启动Apache / Nginx的，启动你的GUI桌面环境，等等。他们每个进程都可能会反过来派生出更多的子进程。到目前为止还没有什么特别的。但考虑到如果一个进程终止会发生什么。比方说，bash（PID 5）进程终止。它变成了一个所谓的“停止活动的进程”，也称为“僵尸进程”。为什么会这样？这是因为Unix被设计为这样一种方式，父进程必须明确地“等待”子进程终止，以便收集它的退出状态.。僵尸进程一直存在，直到父进程已经执行该操作，使用系统调用waitpid()函数。我从手册页引用 “一个子进程终止了，但一直被等待就变成了”僵尸“。内核维护了一组关于僵尸进程最小的信息列表（PID，终止状态，资源使用信息），为了让父进程以后进行等待时，能够获取有关子进程的信息。”在日常的语言中，人们认为“僵尸进程”是会造成严重破坏的混乱进程。但正式的说 - 从Unix操作系统观点 - 僵尸进程有一个非常明确的定义。他们是已经终止，但没有（还）被他们的父进程等待的进程。大多数时间这都不是问题，在子进程上调用waitpid()的动作是为了消除它的僵死进程，这就是所谓的“收割”。许多应用正确的收割它们的子进程。在上面的例子中用的是sshd,如果bash终止了然后操作系统将会向sshd发送一个SIGCHLD信号把它唤醒。sshd注意到了这个信号后就收割子进程。?但是有个特殊情况，假设父进程终结了，或者是故意的（因为程序逻辑决定该退出系统了）或者是用户的操作导致的（例如用户将这个进程杀死了）。这个父进程的子进程将会发生什么？他们不再有父进程了，所以他们变成了“孤儿”（这是实际的专业术语）。这就是init进程起作用的地方。init进程--PID 1--有一个特殊的任务。就是“接收”孤儿进程（注意，这是实际的技术术语）。这就意味着init进程变为了这些进程的父进程。尽管这些进程从来都没有被init进程直接创建。拿Nginx作为例子，默认是作为后台守护进程。它是这么工作的。第一，Nginx创建一个子进程。第二，原始的Nginx进程退出了。第三，Nginx子进程被init进程给接收了。你可能知道我将要表达什么。操作系统内核自动的处理收容，所以这就意味着内核期望init进程要有一个专门的职责：操作系统也期望init进程收割被接收的孤儿进程。这是Unix系统中一个非常重要的职责。它是如此基础的职责以至于很多很多软件的都利用