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

前言

在Docker大行其道的今天,我们能够非常方便的使用容器打包我们的应用程序,并且将它在我们的服务器上部署并运行起来。但是,谈论到如何停掉运行中的docker容器并正确的终止其中的程序,这就成为一个非常值得讨论的话题了。

事实上,在我们日常的项目当中,这是我们经常需要面对和处理的问题:

场景A:假如我们打包在容器中的程序,提供HTTP方式的服务,负责处理各种HTTP requests并返回结果,我们必然希望在容器被停掉的时候,能够让程序有时间把已经在处理中的请求继续处理完毕,并返回结果给客户端。

场景B:又比如我们打包在容器中的程序,负责写入数据到某个数据文件中,我们希望程序能够在容器被停掉的时候,有时间把内存中缓存的数据持久化到存储设备中,以防数据丢失。

场景C:再比如现在流行的微服务架构中,一般会有服务发现的机制,也即每一个微服务在启动之后,都会主动把自己的地址信息注册到服务发现模块当中,让其他的服务可以知道自己的存在。而在容器被停掉的时候,微服务需要即时从服务发现模块中注销自己,以防止从API Gateway而来的请求被错误的路由到了已经被停止掉的微服务。

如上的各种场景中,都要求打包在容器中的应用程序能够被优雅的终止(也即gracefully shutdown),这种gracefully shutdown的方式,允许程序在容器被停止的时候,有一定时间做一些后续处理操作,这也是我们需要进一步探讨的话题。

docker stop 与 docker kill 的区别

Docker本身提供了两种终止容器运行的方式,即docker stopdocker kill

docker stop

先来说说docker stop吧,当我们用docker stop命令来停掉容器的时候,docker默认会允许容器中的应用程序有10秒的时间用以终止运行。所以我们查看docker stop命令帮助的时候,会有如下的提示:

→ docker stop --help
Usage: docker stop [OPTIONS] CONTAINER [CONTAINER...]
Stop one or more running containers
Options:
  --help  Print usage
 -t, --time int Seconds to wait for stop before killing it (default 10)

docker stop命令执行的时候,会先向容器中PID为1的进程发送系统信号SIGTERM,然后等待容器中的应用程序终止执行,如果等待时间达到设定的超时时间,或者默认的10秒,会继续发送SIGKILL的系统信号强行kill掉进程。在容器中的应用程序,可以选择忽略和不处理SIGTERM信号,不过一旦达到超时时间,程序就会被系统强行kill掉,因为SIGKILL信号是直接发往系统内核的,应用程序没有机会去处理它。在使用docker stop命令的时候,我们唯一能控制的是超时时间,比如设置为20秒超时:

docker stop --time=20 container_name

docker kill

接着我们来看看docker kill命令,默认情况下,docker kill命令不会给容器中的应用程序有任何gracefully shutdown的机会。它会直接发出SIGKILL的系统信号,以强行终止容器中程序的运行。通过查看docker kill命令的帮助,我们可以看到,除了默认发送SIGKILL信号外,还允许我们发送一些自定义的系统信号:

→ docker kill --help
Usage: docker kill [OPTIONS] CONTAINER [CONTAINER...]
Kill one or more running containers
Options:
  --help   Print usage
 -s, --signal string Signal to send to the container (default "KILL")

比如,如果我们想向docker中的程序发送SIGINT信号,我们可以这样来实现:

docker kill --signal=SIGINT container_name

与docker stop命令不一样的地方在于,docker kill没有任何的超时时间设置,它会直接发送SIGKILL信号,以及用户通过signal参数指定的其他信号。

其实不难看出,docker stop命令,更类似于Linux系统中的kill命令,二者都是发送系统信号SIGTERM。而docker kill命令,更像是Linux系统中的kill -9或者是kill -SIGKILL命令,用来发送SIGKILL信号,强行终止进程。

在程序中接收并处理信号

了解了docker stopdocker kill的区别,我们能够知道,docker kill适合用来强行终止程序并实现快速停止容器。而如果希望程序能够gracefully shutdown的话,docker stop才是不二之选。这样,我们可以让程序在接收到SIGTERM信号后,有一定的时间处理、保存程序执行现场,优雅的退出程序。

接下来我们可以写一个简单的Go程序来实现信号的接收与处理,程序在启动过后,会一直阻塞并监听系统信号,直到监测到对应的系统信号后,输出控制台并退出执行。

// main.go
package main
import (
 "fmt"
 "os"
 "os/signal"
 "syscall"
)
func main() {
 fmt.Println("Program started...")
 ch := make(chan os.Signal, 1)
 signal.Notify(ch, syscall.SIGTERM)
 s := <-ch
 if s == syscall.SIGTERM {
 fmt.Println("SIGTERM received!")
 //Do something...
 }
 fmt.Println("Exiting...")
}

接下来使用交叉编译的方式来编译程序,让程序可以在Linux下运行:

CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o graceful

编译好之后,我们还需要打包程序到容器中运行。于是,我们还得有个Dockerfile。在这里,我们选择使用体积小又轻盈的alpine镜像作为基础镜像,打包这个Go程序:

from alpine:latest
MAINTAINER Timothy
ADD graceful /graceful
CMD ["/graceful"]

这里需要避开的一个坑,是Dockerfile中CMD命令的用法。

CMD命令有两种方式:

CMD /graceful

使用 CMD command param1 param2 这种方式,其实是以shell的方式运行程序。最终程序被执行时,类似于/bin/sh -c的方式运行了我们的程序,这样会导致/bin/sh以PID为1的进程运行,而我们的程序只不过是它fork/execs出来的子进程而已。前面我们提到过docker stop的SIGTERM信号只是发送给容器中PID为1的进程,而这样,我们的程序就没法接收和处理到信号了。

CMD [“/graceful”]

使用 CMD [“executable”,”param1”,”param2”] 这种方式启动程序,才是我们想要的,这种方式执行和启动时,我们的程序会被直接启动执行,而不是以shell的方式,这样我们的程序就能以PID=1的方式开始执行了。

话题转回来,我们开始执行容器构建操作,打包程序:

docker build -t registry.xiaozhou.net/graceful:latest .

打包过后的镜像,才6MB左右:

λ Timothy [workspace/src/graceful] → docker images
REPOSITORY            TAG     IMAGE ID   CREATED    SIZE
registry.xiaozhou.net/graceful       latest    b2210a85ca55  20 hours ago  6.484 MB

启动并运行容器:

λ Timothy [workspace/src/graceful] → docker run -d --name graceful b2210a85

查看容器运行状态:

λ Timothy [workspace/src/graceful] → docker ps -a
CONTAINER ID  IMAGE    COMMAND    CREATED    STATUS    PORTS    NAMES
fd18eedafd16  b221    "/graceful"   3 seconds ago  Up 2 seconds       graceful

查看容器输出,能看到程序已经正常启动:

λ Timothy [workspace/src/graceful] → docker logs graceful
Started...

接着我们要使用docker stop大法,看程序能否响应SIGTERM信号:

λ Timothy [workspace/src/graceful] → docker stop graceful
graceful

最后,查看容器的日志,检验输出:

λ Timothy [workspace/src/graceful] → docker logs graceful
Started...
SIGTERM received!
Exiting...

总结

以上就是这篇文章的全部内容了,用docker kill命令,可以简单粗暴的终止docker容器中运行的程序,但是想要优雅的终止掉的话,我们需要使用docker stop命令,并且在程序中多花一些功夫来处理系统信号,这样能保证程序不被粗暴的终止掉,从而实现gracefully shutdown。希望本文的内容对大家的学习或者工作能有所帮助,如果有疑问大家可以留言交流。

(0)

相关推荐

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

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

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

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

  • Docker容器配置Nginx实例分享

    作为目前最火的应用,Docker 确实存在着其独到之处,无论是程序猿还是运维都应该听说过 Docker 的大名,Docker 已经走过了许多的坑,目前最新版本是 v1.11.0 版本,应该说是完全能承载开发使用和运维监控,这款工具能帮助我们高效的打包.发布和运行承载着应用程序的容器系统.而且收集日志.帮助 App 的快速开发都有很大作用. 容器和虚拟机,经常是被拿出来对比的两款产品,实际上两者有着根本的差别,虚拟机是完全模拟了一台真实计算机,在上面运行的系统可能或者不可能知道自己运行在虚拟化环境

  • Docker容器的Tengine实践

    作为目前最火的应用,Docker 确实存在着其独到之处,无论是程序猿还是运维都应该听说过 Docker 的大名,Docker 已经走过了许多的坑,目前最新版本是 v1.11.0 版本,应该说是完全能承载开发使用和运维监控,这款工具能帮助我们高效的打包.发布和运行承载着应用程序的容器系统.而且收集日志.帮助 App 的快速开发都有很大作用. 容器和虚拟机,经常是被拿出来对比的两款产品,实际上两者有着根本的差别,虚拟机是完全模拟了一台真实计算机,在上面运行的系统可能或者不可能知道自己运行在虚拟化环境

  • Docker 镜像和容器的区别详解

    最近学习Docker,被Docker 的镜像和容器搞的晕头转向,索性上网查找相关资料并整理下彻底的理解这块内容,有需要的小伙伴可以看下,少走点弯路. Docker的镜像和容器的区别 一.Docker镜像 要理解Docker镜像和Docker容器之间的区别,确实不容易. 假设Linux内核是第0层,那么无论怎么运行Docker,它都是运行于内核层之上的.这个Docker镜像,是一个只读的镜像,位于第1层,它不能被修改或不能保存状态. 一个Docker镜像可以构建于另一个Docker镜像之上,这种层

  • Docker 手动配置容器网络实例详解

    Docker 手动配置容器网络 docker容器的网络是net命名空间与虚拟设备的结合,容器在启动时会创建一对虚拟接口veth pair,这一对接口分别放到本地和容器中,在本地的veth会被分配类似vethxxxx的名称并被桥接到指定网桥的上(默认为docker0),可以通过brctl show命令查看网桥上挂载的接口,在容器中的veth会从网桥获取一个未使用地址,该veth的名称会被更改为eth0并配置默认路由到vethxxxx,docker允许在启动容器的时候通过--net参数指定不同的网络

  • 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

  • 使用IPython来操作Docker容器的入门指引

    现在Docker是地球上最炙手可热的项目之一,就意味着人民实际上不仅仅是因为这个才喜欢它. 话虽如此,我非常喜欢使用容器,服务发现以及所有被创造出的新趣的点子和领域来切换工作作为范例. 这个文章中我会简要介绍使用python中的docker-py模块来操作Docker 容器,这里会使用我喜爱的编程工具IPython. 安装docker-py 首先需要docker-py.注意这里的案例中我将会使用Ubuntu Trusty 14.04版本. $ pip install docker-py IPyh

  • 详解Docker目录挂载的方法总结

    Docker容器启动的时候,如果要挂载宿主机的一个目录,可以用-v参数指定. 譬如我要启动一个centos容器,宿主机的/test目录挂载到容器的/soft目录,可通过以下方式指定: # docker run -it -v /test:/soft centos /bin/bash 这样在容器启动后,容器内会自动创建/soft的目录.通过这种方式,我们可以明确一点,即-v参数中,冒号":"前面的目录是宿主机目录,后面的目录是容器内目录. 貌似简单,其实不然,下面我们来验证一下: 一.容器

  • docker实践之容器的导入与导出

    前言 Docker的流行与它对容器的易分享和易移植密不可分.用户不仅可以把容器提交到公共服务器上,还可以将容器导出到本地文件系统中.同样,我们也可以将导出的容器重新导入到Docker环境中去. 如果要导出本地某个容器,可以使用 Docker export 命令,可以使用 docker import 从容器快照文件中再导入为镜像 1.首先查找正在运行的容器ID 2.然后使用 docker export 命令将容器导出(这里以GWAS_HF容器为例) 3.查看导出结果,scp命令传输到另一台服务器

随机推荐