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

前言

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

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

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

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

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

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

docker stop 与 docker kill 的区别

Docker本身提供了两种终止容器运行的方式，即docker stop与docker kill。

docker stop

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

→ docker stop --helpUsage: docker stop [OPTIONS] CONTAINER [CONTAINER...]Stop one or more running containersOptions:  --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 --helpUsage: docker kill [OPTIONS] CONTAINER [CONTAINER...]Kill one or more running containersOptions:  --help   Print usage -s, --signal string Signal to send to the container (default "KILL")