利用 trap 在 docker 容器优雅关闭前执行环境清理的方案

当一个运行中的容器被终止时,如何能够执行一些预定义的操作,比如在容器彻底退出之前清理环境。这是一种类似于 pre stop 的钩子体验。但 docker 本身无法提供这种能力,本文结合 Linux 内置命令 trap ,实现在容器优雅关闭之前,可以执行自定义的操作。

当一个运行中的容器被终止时,如何能够执行一些预定义的操作,比如在容器彻底退出之前清理环境。这是一种类似于 pre stop 的钩子体验。但 docker 本身无法提供这种能力,本文结合 Linux 内置命令 trap ,实现在容器优雅关闭之前,可以执行自定义的操作。

如何关闭容器

我了解有三种方式可以关闭一个正在运行中的容器,三者都是由 docker 命令行发起的。

  • 第一种是较为优雅的方式 docker stop ContainerID
  • 第二种看起来就比较武断 docker rm -f ContainerID
  • 第三种用的人会少很多 docker kill --signal=KILL ContainerID

docker 的设计者自然不会平白无故的设计三种命令组合来做关闭容器这件事,三种方式都应该在什么场景下被使用呢?

这三种终止容器的方式之间是略有不同的,在讲解这些不同之前,需要提及一些看似和容器不相关的知识点——SIGNAL 。

进程与信号

用户是可以通过发送信号,来和进程通信的。

基本上每一个运维工程师都执行过如下命令来杀死一个进程:

kill -9 PID

这个命令看起来恰如其分,我 "杀死" 了一个进程,但是,为什么是 "-9" ?

9 是信号 SIGKILL 的代号,上述命令实际上是向对应的进程发送了一个信号,一个可以杀死进程的信号。

kill 命令的真正意义,是向进程发送指定的信号,除了SIGKILL(9) 之外,还可以发送其他多种信号:

root@ubuntuserver:~# kill --help

kill: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec]

    Send a signal to a job.

root@ubuntuserver:~# kill -l

 1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP

 6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10) SIGUSR1

11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM

16) SIGSTKFLT 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20) SIGTSTP

21) SIGTTIN 22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ

26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO 30) SIGPWR

31) SIGSYS 34) SIGRTMIN 35) SIGRTMIN+1 36) SIGRTMIN+2 37) SIGRTMIN+3

38) SIGRTMIN+4 39) SIGRTMIN+5 40) SIGRTMIN+6 41) SIGRTMIN+7 42) SIGRTMIN+8

43) SIGRTMIN+9 44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13

48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12

53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9 56) SIGRTMAX-8 57) SIGRTMAX-7

58) SIGRTMAX-6 59) SIGRTMAX-5 60) SIGRTMAX-4 61) SIGRTMAX-3 62) SIGRTMAX-2

63) SIGRTMAX-1 64) SIGRTMAX

我无意去详解每一个信号的意义,我的功力还差得远,在这里只拣取和我们主题相关的知识来进行阐述。

有两个信号和我们的主题相关, SIGTERM. SIGKILL

信号名称 代号 可否被捕获或忽略
SIGTERM 15 可以
SIGKILL 9 不可以

SIGTERMkill 命令默认发送的信号。当用户请求终止进程时,会产生SIGTERM信号。SIGTERM信号可以被捕获或无视。这允许该进程在结束前释放掉所占用的资源并保存其状态。

SIGKILL 发送SIGKILL信号到一个进程可以使其立即终止(KILL)。与SIGTERM不同的是,这个信号不能被捕获或忽略,接收过程在接收到这个信号时不能执行任何清理。但有时候 kill -9 并非一定可以杀死进程,释放资源。还是有一些特殊情况:

  • 僵尸进程不能被杀死,因为它们已经死了,正在等待它们的父进程来收获它们。
  • 处于阻塞状态的进程不会死亡,直到它们再次醒来init 进程是特殊的:
  • init不接收任何它不打算处理的信号,因此它会忽略SIGKILL。这条规则有一个例外,Linux 上的 init 如果被 ptrace 了,那么它是可以接收 SIGKILL 并被杀死的。
  • 处于不可中断的睡眠的进程即使发送了SIGKILL,也有可能不会终止(并释放其资源)。这是少数 Unix 系统必须重新启动才能解决临时软件问题的几种情况之一。

容器与信号

容器的本质,是一组被封装起来的进程。所以通过开头讲到的三种命令行方式关闭一个运行中的容器,其本质也是在通过发送信号的方式与容器中的进程进行交互,使之被 "杀死" 的过程。

  • docker stop

执行 docker stop ContainerID ,会向容器中的主进程先发送一个 SIGTERM 信号,在一段时间的宽限期后,发送 SIGKILL 信号彻底杀死容器。

Docker 手册原文如下:

The main process inside the container will receive SIGTERM, and after a grace period, SIGKILL

  • docker rm -f

执行 docker rm -f ContainerID ,会向容器中的主进程直接发送SIGKILL 信号,在容器杀死之后,也会把容器删除掉。从删除容器这个操作看来,这个命令是用来删除一个已停止的容器,而非用于停止运行中的容器。

  • docker kill

执行 docker kill --signal=KILL ContainerID ,是专门向容器主进程发送各种自定义信号的方式。换言之,它就是面向容器的 kill 命令。当前命令是在向容器主进程发送一个 SIGKILL 信号。

通过比对,docker rm -f ContainerID 这种方式是不应该用于停止运行中容器的。而剩余两种方式之间, docker stop ContainerID 也明显要优雅一些,它既可以保证容器会被最终杀死,也会提供 SIGTERM 供用户后续捕获处理。

接下来终于要进入正题了。

捕获信号并处理

信号 SIGTERM 是一种可以被捕获的信号。当容器主进程捕获到这个信号之后,可以触发事先设计好的逻辑,在彻底退出之前完成预定的任务。比如可以执行环境的清理、数据的保存、关闭其他不受主进程控制的进程等等。在某些场景下,这种需求非常突出。

Linux 提供内置的 trap 命令,负责捕获信号,并确保在进程彻底退出前,执行某些任务。

root@ubuntuserver:~# trap --help

trap: trap [-lp] [[arg] signal_spec ...]

    Trap signals and other events.

其基本的使用方式如下:

trap do_some_things SIGSPEC

思路已经清晰了,我们需要在容器的启动脚本中,加入 trap 指令,来完成容器在退出前需要做的所有事情。

以下是一个脚本示例,这个脚本被作为容器的入口(ENTRYPOINT)执行。

#!/bin/bash

function clean_up_term {
  rm -rf /data/tmp
  echo "clean_up_term in execution"
}

trap clean_up_term SIGTERM

for ((i=1;i<=1000;i++))
  do
    echo "Wait for $i"
    sleep 1
  done

容器启动后,从其他终端执行了 docker stop ContainerID 命令,可以观察到以下结果。

guox@MacBook-Pro-For-Guox: /Users/guox/GitHub/test-plugin git:(master) ✗ 

➜   docker run -ti --name=clean -v $(pwd)/data:/data clean 

Wait for 1

Wait for 2

Wait for 3

Wait for 4

Wait for 5

Wait for 6

Wait for 7

Wait for 8

Wait for 9

Wait for 10

Wait for 11

Wait for 12

Wait for 13

clean_up_term in execution

Wait for 14

Wait for 15

Wait for 16

Wait for 17

Wait for 18

Wait for 19

Wait for 20

Wait for 21

Wait for 22

Wait for 23

guox@MacBook-Pro-For-Guox: /Users/guox/GitHub/test-plugin git:(master) ✗ 

信号 SIGTERM 的确被容器捕获,并进行了相关的清理操作。 docker stop ContainerID 提供了一段宽限期,所以在执行了清理操作后,容器主进程还是继续执行了一会才退出。

到此这篇关于利用 trap 在 docker 容器优雅关闭前执行环境清理的文章就介绍到这了,更多相关docker 容器执行环境清理内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • 详解Docker退出容器不关闭容器的方法

    进入docker容器后如果退出容器,容器就会变成Exited的状态,那么如何退出容器让容器不关闭呢? 如果要正常退出不关闭容器,请按Ctrl+P+Q进行退出容器,这一点很重要,请牢记! 以下示例为退出容器但不关闭容器 [root@localhost ~]# docker attach c600c4519fc8 [root@c600c4519fc8 /]# exit exit [root@localhost ~]# docker ps -a CONTAINER ID IMAGE COMMAND C

  • Docker 清理环境操作

    开始清理,需要慎重! 列出无用的卷 docker volume ls -qf dangling=true 清理无用的卷 docker volume rm $(docker volume ls -qf dangling=true) 清理无用的镜像 docker rmi $(docker images | grep '^<none>' | awk '{print $3}') 继续清理 docker system prune docker volume prune 以上足够使用,其他命令不要知道了!

  • docker批量启动关闭所有容器的操作

    docker中 启动所有的容器命令 docker start $(docker ps -a | awk '{ print $1}' | tail -n +2) docker中 关闭所有的容器命令 docker stop $(docker ps -a | awk '{ print $1}' | tail -n +2) 补充:shell批量启动和删除docker容器,基于docker toolbox 停止容器 stop.sh #!/bin/bash containerIDs="8f78b7e6995

  • 利用 trap 在 docker 容器优雅关闭前执行环境清理的方案

    当一个运行中的容器被终止时,如何能够执行一些预定义的操作,比如在容器彻底退出之前清理环境.这是一种类似于 pre stop 的钩子体验.但 docker 本身无法提供这种能力,本文结合 Linux 内置命令 trap ,实现在容器优雅关闭之前,可以执行自定义的操作. 当一个运行中的容器被终止时,如何能够执行一些预定义的操作,比如在容器彻底退出之前清理环境.这是一种类似于 pre stop 的钩子体验.但 docker 本身无法提供这种能力,本文结合 Linux 内置命令 trap ,实现在容器优

  • 在docker容器中调用和执行宿主机的docker操作

    首先这个帖子,献给docker新手.当然如果你是一个老手,文中分割线后的操作方法也是一种思路. 首先说一下,如何在docker中执行宿主机的docker操作,我们管它叫docker in docker. 至于为什么要在docker中操作宿主机的docker,优点不言而喻,你既可以将你的具体需求容器化部署,又不用直接在宿主机上安装(假设我们没有办法在docker中操作宿主机的docker,那么我们只能将这样的软件程序直接安装到宿主机上,这样显然是不利于管理和维护的). 实现这种需求,其实非常简单,

  • 关于docker容器优雅退出的问题详解

    前言 最近因为工作的原因,谈到了关于如何正确的退出运行中的docker容器,这是一个非常值得讨论的话题了.本文将给出详细的介绍,下面来一起看看吧. 容器信号使用 我们跑在容器中的程序通常想在容器退出之前做一些清理操作,比较常用的方式是监听一个信号,延迟关闭容器. docker提供了这样的功能: ╰─➤ docker stop --help Usage: docker stop [OPTIONS] CONTAINER [CONTAINER...] Stop one or more running

  • 详解利用ELK搭建Docker容器化应用日志中心

    概述 应用一旦容器化以后,需要考虑的就是如何采集位于Docker容器中的应用程序的打印日志供运维分析.典型的比如SpringBoot应用的日志 收集.本文即将阐述如何利用ELK日志中心来收集容器化应用程序所产生的日志,并且可以用可视化的方式对日志进行查询与分析,其架构如下图所示: 架构图 镜像准备 镜像准备 ElasticSearch镜像 Logstash镜像 Kibana镜像 Nginx镜像(作为容器化应用来生产日志) 开启Linux系统Rsyslog服务 修改Rsyslog服务配置文件: v

  • Docker容器中Mysql数据的导入/导出详解

    前言 Mysql数据的导入导出我们都知道一个mysqldump命令就能够解决,但如果是运行在docker环境下的mysql呢? 解决办法其实还是用mysqldump命令,但是我们需要进入docker的mysql容器内去执行它,并且通过配置volumes让导出的数据文件可以拷贝到宿主机的磁盘上 所以操作步骤就可以分为: 配置docker的volumes 进入docker的mysql容器,导出数据文件 至于数据导入,太过简单,就不说了 先来看看mysqldump命令常见选项: --all-datab

  • Spring Boot利用@Async异步调用:ThreadPoolTaskScheduler线程池的优雅关闭详解

    前言 之前分享了一篇关于Spring Boot中使用@Async来实现异步任务和线程池控制的文章:<Spring Boot使用@Async实现异步调用:自定义线程池>.由于最近身边也发现了不少异步任务没有正确处理而导致的不少问题,所以在本文就接前面内容,继续说说线程池的优雅关闭,主要针对ThreadPoolTaskScheduler线程池. 问题现象 在上篇文章的例子Chapter4-1-3中,我们定义了一个线程池,然后利用@Async注解写了3个任务,并指定了这些任务执行使用的线程池.在上文

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

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

  • 利用Volume在主机和Docker容器文件传输的方法

    之前写过一篇关于Docker容器和本机之间的文件传输.的文章,但是此方法相对比较繁琐一些,在查看了官方关于数据管理的文档之后发现利用volume来实现主机和容器的文件传输效率更高一点,其实也就是将本地的目录进行挂载到容器上,官方一共有三种方法:Manage data in Docker, 这里只介绍使用volume的操作:Use volumes 1.使用Volume在主机和容器之间传输文件. 在官方文档中可以看到使用如下命令即可创建一个volume: Create a volume: $ doc

随机推荐