Docker コンテナーでシグナルをキャッチする方法を知っていますか?

実行中のコンテナを停止するには docker stop コマンドを使用したはずですが、場合によっては docker kill コマンドを使用してコンテナを強制的に閉じたり、プロセスにシグナルを渡したりすることもあります。コンテナ。

実際、私たちが実行する操作は基本的に、ホストからコンテナーに信号を送信することによる、ホストとコンテナー内のプログラム間の対話です。たとえば、コンテナ内のアプリケーションにリロード信号を送信すると、コンテナ内のアプリケーションは、信号の受信後に対応するハンドラを実行して、構成ファイルをリロードするタスクを完了します。

Signal (linux)

Signal はプロセス間通信の形式です。シグナルは、特定のイベントが発生したことをプロセスに伝えるために、カーネルからプロセスに送信されるメッセージです。シグナルがプロセスに送信されると、プロセスは現在の実行フローを直ちに中断し、シグナル ハンドラーの実行を開始します (シグナルが特定の時間に処理されるというのは正確ではありません)。このシグナルにハンドラーが指定されていない場合は、デフォルトのハンドラーが実行されます。
プロセスは、対象となるシグナルのハンドラーを登録する必要があります。たとえば、プログラムが正常に終了できるようにする (終了要求を受信した後にリソースをクリーンアップするため) ため、通常、プログラムは SIGTERM シグナルを処理します。 SIGTERM シグナルとは異なり、SIGKILL シグナルはプロセスを強制的に終了します。したがって、プログラムを正常に終了するには、アプリケーションで SIGTERM シグナルをキャプチャして処理するディレクトリを実装する必要があります。失敗した場合、ユーザーは最後の手段として SIGKILL シグナルに頼らなければなりません。 SIGTERM と SIGKILL に加えて、特にユーザー定義の動作をサポートする SIGUSR1 のようなシグナルがあります。次のコードは、nodejs でシグナルのハンドラーを登録する方法を簡単に説明しています。

process.on('SIGTERM', function() {
  console.log('shutting down...');
});

シグナルの詳細については、著者が記事「linux kill コマンド」で言及しているため、ここでは繰り返しません。

コンテナ内のシグナル

Docker の stop および kill コマンドは、コンテナにシグナルを送信するために使用されます。コンテナ内のプロセス No. 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]);
  });
});

このアプリケーションは、SIGINT および SIGTERM シグナル用に登録されたハンドラーを備えたポート 3000 でリッスンする http サーバーです。次に、さまざまな方法でコンテナー内でプログラムを実行するときにシグナルがどのように処理されるかを紹介します。

アプリケーションはコンテナ内のプロセス 1 として使用されます

Dockerfile ファイルを作成し、上記のアプリケーションをイメージにパッケージ化します:

FROM iojs:onbuild
COPY ./app.js ./app.js
COPY ./package.json ./package.json
EXPOSE 3000ENTRYPOINT ["node", "app"]

方法に注意してくださいENTRYPOINT命令の書き方 この書き方ではノードがコンテナ内のプロセス1番として動作します。

次にイメージを作成します:

$ docker build --no-cache -t signal-app -f Dockerfile .

次にコンテナを起動してアプリケーションを実行します:

请注意 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：

この時点で、コンテナ内のノード アプリケーションのプロセス番号は 1 です。 :

次に、プログラムを終了してコマンドを実行します:

$ docker container kill --signal="SIGTERM" my-app

この時点で、アプリケーションは期待どおりに終了します:

アプリケーションはコンテナ内のプロセス No. 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

これでこの時点で、コンテナ内のノード アプリケーションのプロセス番号は 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 等指令的写法决定，所以这些指令的使用是很有讲究的。

相关推荐：docker入门教程

以上がDocker コンテナーでシグナルをキャッチする方法を知っていますか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。