我们可能都使用过docker stop命令来停止正在运行的容器,有时候可能会使用docker kill命令强行关闭容器或者把某个信号传递给容器中的进程。这些操作的本质都是通过主机向容器发送信号实现主机与容器中程序的交互。比如说我们可以向容器中的应用发送一个重新加载信号,容器中的应用程序在接到信号后执行相应的处理程序完成重新加载配置文件的任务。我们在这个章节中来看看docker中捕获信号的基本知识。
信号是什么?
信号是进程间通信的一种方式(??这里的描述应该不是很准确)。一个信号就是内核发送给进程的一个消息,告诉进程发生了某个事件。当一个信号被发送给一个进程后,进程会在特定的时机中断当前的执行流,并开始执行信号的处理程序。如果没有为这个信号指定处理程序,就执行默认的处理程序。
进程需要为自己感兴趣的信号注册处理程序,比如为了能让程序优雅地退出(接到退出的请求后能够对资源进行清理)。一般的程序都会处理sigterm信号,而sigkill则会粗暴地结束一个进程,
容器中的信号
docker中的stop和kill都是用来向容器发送信号的。注意,只有容器中的一号进程能够接收到信号,这一点非常关键!
stop命令会首先发送sigterm信号,并等待应用的优雅结束。如果发现应用没有结束,就再发送一个sigkill信号强行结束程序。docker 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,为sigterm和sigint信号注册了处理程序,接下来我们以不同方式在容器中运行程序,看看它们对信号的处理方式。
应用程序作为容器中的1号进程
创建Dockerfile文件,把上面的应用打包到镜像中:
FROM iojs:onbuildCOPY ./app.js ./app.jsCOPY ./package.json ./package.jsonEXPOSE 3000ENTRYPOINT ["node", "app"]
注意,ENTRYPOINT的写法,会让node在容器中以1号进程的身份运行。
接下来创建镜像:
$ docker build --no-cache -t signal-app -f Dockerfile .
然后启动node应用在容器中的进程号为1:
现在我们让程序退出,执行命令:
$ docker container kill --signal="SIGTERM" my-app
此时应用会以我们期望的方式退出:
应用程序不是容器中的1号进程
创建一个启动应用程序的脚本文件app1.sh, 内容如下:
#!/usr/bin/env bashnode app
然后创建新的Dockerfile文件,内容如下:
FROM iojs:onbuildCOPY ./app.js ./app.jsCOPY ./app1.sh ./app1.shCOPY ./package.json ./package.jsonRUN chmod +x ./app1.shEXPOSE 3000ENTRYPOINT ["./app1.sh"]
接下来创建镜像:
$ docker build --no-cache -t signal-app1 -f Dockerfile .
然后启动容器运行应用程序:
$ 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-app1or#docker container kill --signal="sigkill" my-app1
在脚本中捕获信号
创建另外一个启动应用程序的脚本文件app2.sh, 内容如下:
#!/usr/bin/env bashset -xpid=0# SIGUSR1-handlermy_handler() {echo "my_handler"}# SIGTERM-handlerterm_handler() {if [ $pid -ne 0 ]; thenkill -SIGTERM "$pid"wait "$pid"fiexit 143; # 128 + 15 -- SIGTERM}# setup handlers# on callback, kill the last background process, which is `tail -f /dev/null` and execute the specified handlertrap 'kill ${!}; my_handler' SIGUSR1trap 'kill ${!}; term_handler' SIGTERM# run applicationnode app &pid="$!"# wait foreverwhile truedotail -f /dev/null & wait ${!}done
这个脚本文件在启动应用程序的同时可以捕获发送给它的sigterm和sigusr1,并为它们添加了处理程序。其中,sigterm信号处理程序就是向我们node应用程序发送sigterm信号。
继续创建dockerfile, 内容如下:
FROM iojs:onbuildCOPY ./app.js ./app.jsCOPY ./app2.sh ./app2.shCOPY ./package.json ./package.jsonRUN chmod +x ./app2.shEXPOSE 3000ENTRYPOINT ["./app2.sh"]
接下来创建镜像:
$ docker build --no-cache -t signal-app2 -f Dockerfile .
然后启动容器运行应用程序:
$ docker run -it --rm -p 3000:3000 --name="my-app2" signal-app2
此时node应用在容器中进程号也不是1,但是它却可以接收到SIGTERM信号并优雅的退出:
容器中的1号进程是非常重要的,如果它不能正确的处理相关的信号,那么应用程序退出的方式几乎总是被强制杀死而不是优雅地退出。
