我們可能都使用過 docker stop 命令來停止正在運行的容器，有時可能會使用 docker kill 命令強行關閉容器或者把某個信號傳遞給容器中的進程。這些操作的本質都是通過從主機向容器發送信號實現主機與容器中程序的交互。比如我們可以向容器中的應用發送一個重新加載信號，容器中的應用程序在接到信號后執行相應的處理程序完成重新加載配置文件的任務。本文將介紹在 docker 容器中捕獲信號的基本知識。
信號(linux)
信號是一種進程間通信的形式。一個信號就是內核發送給進程的一個消息，告訴進程發生了某種事件。當一個信號被發送給一個進程后，進程會立即中斷當前的執行流並開始執行信號的處理程序。如果沒有為這個信號指定處理程序，就執行默認的處理程序。
進程需要為自己感興趣的信號注冊處理程序，比如為了能讓程序優雅的退出(接到退出的請求后能夠對資源進行清理)一般程序都會處理 SIGTERM 信號。與 SIGTERM 信號不同，SIGKILL 信號會粗暴的結束一個進程。因此我們的應用應該實現這樣的目錄：捕獲並處理 SIGTERM 信號，從而優雅的退出程序。如果我們失敗了，用戶就只能通過 SIGKILL 信號這一終極手段了。除了 SIGTERM 和 SIGKILL ，還有像 SIGUSR1 這樣的專門支持用戶自定義行為的信號。下面的代碼簡單的說明在 nodejs 中如何為一個信號注冊處理程序：
process.on('SIGTERM', function() {
console.log('shutting down...');
});
關於信號的更多信息，筆者在《linux kill 命令》一文中有所提及，這里不再贅述。
容器中的信號
Docker 的 stop 和 kill 命令都是用來向容器發送信號的。注意，只有容器中的 1 號進程能夠收到信號，這一點非常關鍵！
stop 命令會首先發送 SIGTERM 信號，並等待應用優雅的結束。如果發現應用沒有結束(用戶可以指定等待的時間)，就再發送一個 SIGKILL 信號強行結束程序。
kill 命令默認發送的是 SIGKILL 信號，當然你可以通過 -s 選項指定任何信號。
下面我們通過一個 nodejs 應用演示信號在容器中的工作過程。創建 app.js 文件，內容如下：
'use strict'; var http = require('http'); var server = http.createServer(function (req, res) { res.writeHead(200, {'Content-Type': 'text/plain'}); res.end('Hello World\n'); }).listen(3000, '0.0.0.0'); console.log('server started'); var signals = { 'SIGINT': 2, 'SIGTERM': 15 }; function shutdown(signal, value) { server.close(function () { console.log('server stopped by ' + signal); process.exit(128 + value); }); } Object.keys(signals).forEach(function (signal) { process.on(signal, function () { shutdown(signal, signals[signal]); }); });
這個應用是一個 http 服務器，監聽端口 3000，為 SIGINT 和 SIGTERM 信號注冊了處理程序。接下來我們將介紹以不同的方式在容器中運行程序時信號的處理情況。
應用程序作為容器中的 1 號進程
創建 Dockerfile 文件，把上面的應用打包到鏡像中：
FROM iojs:onbuild COPY ./app.js ./app.js COPY ./package.json ./package.json EXPOSE 3000 ENTRYPOINT ["node", "app"]
請注意 ENTRYPOINT 指令的寫法，這種寫法會讓 node 在容器中以 1 號進程的身份運行。
接下來創建鏡像：
$ docker build --no-cache -t signal-app -f Dockerfile .
然后啟動容器運行應用程序：
$ docker run -it --rm -p 3000:3000 --name="my-app" signal-app
此時 node 應用在容器中的進程號為 1：
現在我們讓程序退出，執行命令：
$ docker container kill --signal="SIGTERM" my-app
此時應用會以我們期望的方式退出：
應用程序不是容器中的 1 號進程
創建一個啟動應用程序的腳本文件 app1.sh，內容如下：
#!/usr/bin/env bash node app
然后創建 Dockerfile1 文件，內容如下：
FROM iojs:onbuild COPY ./app.js ./app.js COPY ./app1.sh ./app1.sh COPY ./package.json ./package.json RUN chmod +x ./app1.sh EXPOSE 3000 ENTRYPOINT ["./app1.sh"]
接下來創建鏡像：
$ docker build --no-cache -t signal-app1 -f Dockerfile1 .
然后啟動容器運行應用程序：
$ docker run -it --rm -p 3000:3000 --name="my-app1" signal-app1
此時 node 應用在容器中的進程號不再是 1：
現在給 my-app1 發送 SIGTERM 信號試試，已經無法退出程序了！在這個場景中，應用程序由 bash 腳本啟動，bash 作為容器中的 1 號進程收到了 SIGTERM 信號，但是它沒有做出任何的響應動作。
我們可以通過：
$ docker container stop my-app1 # or $ docker container kill --signal="SIGKILL" my-app1
退出應用，它們最終都是向容器中的 1 號進程發送了 SIGKILL 信號。很顯然這不是我們期望的，我們希望程序能夠收到 SIGTERM 信號優雅的退出。
在腳本中捕獲信號
創建另外一個啟動應用程序的腳本文件 app2.sh，內容如下：
#!/usr/bin/env bash set -x pid=0 # SIGUSR1-handler my_handler() { echo "my_handler" } # SIGTERM-handler term_handler() { if [ $pid -ne 0 ]; then kill -SIGTERM "$pid" wait "$pid" fi exit 143; # 128 + 15 -- SIGTERM } # setup handlers # on callback, kill the last background process, which is `tail -f /dev/null` and execute the specified handler trap 'kill ${!}; my_handler' SIGUSR1 trap 'kill ${!}; term_handler' SIGTERM # run application node app & pid="$!" # wait forever while true do tail -f /dev/null & wait ${!} done
這個腳本文件在啟動應用程序的同時可以捕獲發送給它的 SIGTERM 和 SIGUSR1 信號，並為它們添加了處理程序。其中 SIGTERM 信號的處理程序就是向我們的 node 應用程序發送 SIGTERM 信號。
然后創建 Dockerfile2 文件，內容如下：
FROM iojs:onbuild COPY ./app.js ./app.js COPY ./app2.sh ./app2.sh COPY ./package.json ./package.json RUN chmod +x ./app2.sh EXPOSE 3000 ENTRYPOINT ["./app2.sh"]
接下來創建鏡像：
$ docker build --no-cache -t signal-app2 -f Dockerfile2 .
然后啟動容器運行應用程序：
$ docker run -it --rm -p 3000:3000 --name="my-app2" signal-app2
此時 node 應用在容器中的進程號也不是 1，但是它卻可以接收到 SIGTERM 信號並優雅的退出了：
結論
容器中的 1 號進程是非常重要的，如果它不能正確的處理相關的信號，那么應用程序退出的方式幾乎總是被強制殺死而不是優雅的退出。究竟誰是 1 號進程則主要由 EntryPoint, CMD, RUN 等指令的寫法決定，所以這些指令的使用是很有講究的。