在 docker 容器中捕獲訊號

sparkdev發表於2017-09-27
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 等指令的寫法決定，所以這些指令的使用是很有講究的。

 

相關文章