在Docker中，進程管理的基礎是Linux內核的PID命名空間技術。在不同的PID命名空間下，可以有相同的PID。

Linux內核為所有的PID命名空間維護了一個樹狀的數據結構，最頂層是系統初始化時創建的root namespace（根命名空間）， 父節點可以看到子節點中的進程，并可以通過信號等方式對子節點中的進程產生影響。反過來，子節點不能看到父節點名空間中的任何內容，也不可能通過kill或ptrace影響父節點或其他名空間中的進程。

在docker中有一個很特殊的進程——PID為1的進程，這也是docker的主進程，通過Dockerfile中的 ENTRYPOINT 和/或 CMD指令指定。當主進程退出的時候，容器所擁有的PIG命名空間就會被銷毀，容器的生命周期也會結束docker最佳實踐建議的是一個container一個service，并不強制要你一個container一個線程。有的服務，會催生更多的子進程，比如Apache和uwsgi，這是完全OK的。

PID1進程需要對自己創建的子進程負責，當主進程沒有設計好，不能優雅地讓子進程退出，就會照成很多問題，比如數據庫container，如果處理數據的進程沒有優雅地退出，可能會照成數據丟失。如果很不幸，你的主進程就是這種管理不了子進程的那種，docker提供了一個小工具，幫助你來完成這部分內容。你只需要在run創建container的時候提供一個—init flag就行，docker就會手動為你處理好這些問題。

來看一個實例

在docker中，對于CMD和 ENTRYPOINT，支持兩種進程執行方式：exec和shell。

shell的格式是：

CMD "executable param1 param2" 復制代碼

最終PID1進程將是： /bin/sh -c ”executable param1 param2”

Exec的格式是:

CMD ["executable","param1","param2"] 復制代碼

最終的PID1進程是： executable param1 param2

現在有兩個鏡像，Dockerfile分別如下：

• 鏡像redis:shell

FROM ubuntu:14.04 RUN apt-get update && apt-get -y install redis-server && rm -rf /var/lib/apt/lists/* EXPOSE 6379 CMD "/usr/bin/redis-server" 復制代碼

• 鏡像redis:exec

FROM ubuntu:14.04 RUN apt-get update && apt-get -y install redis-server && rm -rf /var/lib/apt/lists/* EXPOSE 6379 CMD ["/usr/bin/redis-server"] 復制代碼docker run -d --name myredis1 redis:shell docker run -d --name myredis2 redis:exec 復制代碼

那個docker鏡像更好一點呢？

我們前面講過，PID1進程（主進程）需要對自己的子進程負責，對于redis:shell，它產生的PID1進程是

/bin/sh -c "/usr/bin/redis-server" 復制代碼

也就是說，是/bin/sh這個進程，不是/usr/bin/redis-server！/usr/bin/redis-server只是它創建的一個子進程！

執行命令

docker exec myredis1 ps -ef 復制代碼

可以驗證這種猜測

通過exec方式運行的container的主進程則是我們所期望的。

你可能會覺得，這有什么大不了的呢，問題出現當我們停止container的時候。

停止redis:shell

docker stop myredis1 docker logs myredis1 復制代碼

Stop的時候，docker明顯停頓了一段時間，而且查看日志可以看出，redis沒有做任何保存數據庫的操作，直接被強制退出了。這期間發生了什么？首先，運行stop命令會向容器發送 SIGTERM信號，告訴主進程：你該退出了，感覺收拾收拾。但是，這里的主進程是/bin/sh啊，它怎么可能會有處理redis進程退出的機制？所以redis進程不會馬上退出。 Docker Daemon等待一段時間之后（默認是10s），發現容器還沒有完全退出，這時候就會發送 SIGKILL，將容器強行殺死。在這過程中，redis進程完全不知道自己該退出了，所以他沒有做任何收尾的工作。

停止redis:exec

docker stop myredis2 docker logs myredis2 復制代碼

這一次stop的時候是立即生效了，沒有卡頓延遲現象，從輸出來看，redis進行了shutdown的操作，把該持久化的數據都保存到磁盤了。因為這時候的PID1進程是

/usr/bin/redis-server 復制代碼

它是能夠正確處理SIGTERM信號的。這才是我們所期望的。

總結一下

Docker的主進程（PID1進程）是一個很特殊的存在，它的生命周期就是docker container的生命周期，它得對產生的子進程負責，在寫Dockerfile的時候，務必明確PID1進程是什么。

關注我的微信公眾號

總結

以上是生活随笔為你收集整理的从一个实例，一窥docker进程管理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。