在 docker 容器中捕獲信號

咱們可能都使用過 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 等指令的寫法決定，因此這些指令的使用是頗有講究的。