详解如何在 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 等指令的写法决定,所以这些指令的使用是很有讲究的。

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持我们。

(0)

相关推荐

  • Docker 容器操作退出后进入解决办法

    在我们对Docker容器操作的时候,有时候会误操作或者其他的原因无意间退出了正在操作的容器,也许你会担忧你在其中的一些操作未保存下来,无须担忧,本文中将会提供各种方法供你参考(我的建议使用最后一种).在本文,我们将讨论五种(4+1)连接Docker容器并与其进行交互的方法.例子中所有的代码都可以在GitHub中找到,你可以亲自对它们进行测试. 1.nsenter 安装 nsenter 工具在 util-Linux 包2.23版本后包含. 如果系统中 util-linux 包没有该命令,可以按照下

  • Docker为网络bridge模式指定容器ip的方法

    前言 众所周知bridge模式是Docker默认的网络设置,此模式会为每一个容器分配Network Namespace.设置IP等,并将一个主机上的Docker容器连接到一个虚拟网桥上.下面来看看Docker为网络bridge模式指定容器ip的方法. 实现方法 如果只是简单创建一个bridge模式的网络是无法给容器指定ip的 [root@vultrvpn conf.d]# docker network create --driver bridge wordpress_net ad1ff3d972

  • 两种方式创建docker镜像的启动容器时区别介绍(总结篇)

    Docker是建立在Linux内核基础上的,在目前的主流Linux系统中,都已经原生支持了Docker且使用体验也最好,当然,在Windows平台和MacOS系统中也支持Docker,只是需要使用类似Boot2Docker等虚拟化工具来提供Linux支持. 下面重点给大家介绍基于两种创建docker镜像的启动容器时区别,感兴趣的朋友可以跟着小编一起学习! 1.凡是用docker commit生成的镜像启动的时候可以加载一个启动自己应用的脚本,例如: docker run -d -P tomcat

  • Docker 解决容器时间与主机时间不一致的问题三种解决方案

    Docker容器时间与主机时间不一致 通过date命令查看时间 查看主机时间 [root@localhost ~]# date 2016年 07月 27日 星期三 22:42:44 CST 查看容器时间 root@b43340ecf5ef:/#date Wed Jul 27 14:43:31 UTC 2016 可以发现,他们相隔了8小时. CST应该是指(China Shanghai Time,东八区时间) UTC应该是指(Coordinated Universal Time,标准时间) 所以,

  • Docker常用的清除容器镜像命令小结

    前言 Docker 是一个非常有趣的项目.它自己宣称可以减轻部署服务器的难度,当然我相信里面有炒作的成分.但是实际使用后,我觉得 Docker 的表现还是可圈可点的.这篇文章主要总结了Docker清除容器镜像常用的命令,下面来一起看看吧. 杀死所有running状态的容器 docker kill $(docker ps -q) 删除所有已经停止的容器 docker rm $(docker ps -a -q) 删除所有\'untagged/dangling\' ()状态的镜像 docker rmi

  • 详解挂载运行的docker容器中如何挂载文件系统

    前言 感觉最近很多人都在问docker相关的问题,关于怎么操作一个已经启动的docker容器的文件系统,首先我发现这非常困难,因为 mnt的命名空间. 为了登录进入一个已经启动的docker容器,我们需要这么做: 使用nsenter来在临时挂载点上挂载整个docker容器的文件系统. 创建一个特定目录的绑定挂载来当作卷来使用. 卸载临时挂载. 好吧,开始实践. 启动一个名为charlie的docker实例: $ docker run --name charlie -ti ubuntu bash

  • 如何在Docker容器内外互相拷贝数据

    从容器内拷贝文件到主机上 [root@oegw1 soft]# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 8d418a7b6021 postgres "/docker-entrypoint. 7 hours ago Up 7 hours test1 [root@oegw1 soft]# docker exec -t -i 8d418a7b6021 /bin/bash root@oegw1:/var/lib/po

  • Docker 容器内存监控原理及应用

    Docker 容器内存监控 linux内存监控 要明白docker容器内存是如何计算的,首先要明白linux中内存的相关概念. 使用free命令可以查看当前内存使用情况. [root@localhost ~]$ free total used free shared buffers cached Mem: 264420684 213853512 50567172 71822688 2095364 175733516 -/+ buffers/cache: 36024632 228396052 Sw

  • docker容器如何优雅的终止详解

    前言 在Docker大行其道的今天,我们能够非常方便的使用容器打包我们的应用程序,并且将它在我们的服务器上部署并运行起来.但是,谈论到如何停掉运行中的docker容器并正确的终止其中的程序,这就成为一个非常值得讨论的话题了. 事实上,在我们日常的项目当中,这是我们经常需要面对和处理的问题: 场景A:假如我们打包在容器中的程序,提供HTTP方式的服务,负责处理各种HTTP requests并返回结果,我们必然希望在容器被停掉的时候,能够让程序有时间把已经在处理中的请求继续处理完毕,并返回结果给客户

  • Docker容器中文乱码(修改docker容器编码格式)的解决方案

    前台上传文件到服务器后,服务器返回给前台的文件列表中出现中文乱码,所有的中文文件名全部变成?,英文文件名则正常显示. 问题经过定位,发现后台代码的multipartfile类在执行transterto的方法时就发生了此异常,然而配置文件集中的multipartResolver以及encodingFilter均已经设置成了UTF-8,排除代码异常.kubectl exec进入到docker容器中进行查看时发现,文件在容器中也是中文文件名显示异常.查看docker容器编码格式:执行locale命令:

随机推荐