Docker容器优雅终止方案是怎样的
这期内容当中小编将会给大家带来有关Docker容器优雅终止方案是怎样的，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。
作为一名系统重启工程师（SRE），你可能经常需要重启容器，毕竟 Kubernetes 的优势就是快速弹性伸缩和故障恢复，遇到问题先重启容器再说，几秒钟即可恢复，实在不行再重启系统，这就是系统重启工程师的杀手锏。然而现实并没有理论上那么美好，某些容器需要花费 10s 左右才能停止，这是为啥？有以下几种可能性：
容器中的进程没有收到 SIGTERM 信号。
容器中的进程收到了信号，但忽略了。
容器中应用的关闭时间确实就是这么长。
对于第 3 种可能性我们无能为力，主要解决 1 和 2。
如果要构建一个新的 Docker 镜像，肯定希望镜像越小越好，这样它的下载和启动速度都很快，一般我们都会选择一个瘦了身的操作系统（例如 Alpine，Busybox 等）作为基础镜像。
问题就在这里，这些基础镜像的 init 系统也被抹掉了，这就是问题的根源！
init 系统有以下几个特点：
它是系统的第一个进程，负责产生其他所有用户进程。
init 以守护进程方式存在，是所有其他进程的祖先。
它主要负责：
启动守护进程
回收孤儿进程
将操作系统信号转发给子进程
1. Docker 容器停止过程
对于容器来说，init 系统不是必须的，当你通过命令 docker stop mycontainer 来停止容器时，docker CLI 会将 TERM 信号发送给 mycontainer 的 PID 为 1 的进程。
如果 PID 1 是 init 进程 - 那么 PID 1 会将 TERM 信号转发给子进程，然后子进程开始关闭，最后容器终止。
如果没有 init 进程 - 那么容器中的应用进程（Dockerfile 中的
ENTRYPOINT或CMD指定的应用）就是 PID 1，应用进程直接负责响应TERM信号。这时又分为两种情况：应用不处理 SIGTERM - 如果应用没有监听
SIGTERM信号，或者应用中没有实现处理SIGTERM信号的逻辑，应用就不会停止，容器也不会终止。容器停止时间很长 - 运行命令
docker stop mycontainer之后，Docker 会等待10s，如果10s后容器还没有终止，Docker 就会绕过容器应用直接向内核发送SIGKILL，内核会强行杀死应用，从而终止容器。
2. 容器进程收不到 SIGTERM 信号？
如果容器中的进程没有收到 SIGTERM 信号，很有可能是因为应用进程不是 PID 1，PID 1 是 shell，而应用进程只是 shell 的子进程。而 shell 不具备 init 系统的功能，也就不会将操作系统的信号转发到子进程上，这也是容器中的应用没有收到 SIGTERM 信号的常见原因。
问题的根源就来自 Dockerfile，例如：
FROM alpine:3.7COPY popcorn.sh .RUN chmod +x popcorn.shENTRYPOINT ./popcorn.sh
ENTRYPOINT 指令使用的是 shell 模式，这样 Docker 就会把应用放到 shell 中运行，因此 shell 是 PID 1。
解决方案有以下几种：
方案 1：使用 exec 模式的 ENTRYPOINT 指令
与其使用 shell 模式，不如使用 exec 模式，例如：
FROM alpine:3.7COPY popcorn.sh .RUN chmod +x popcorn.shENTRYPOINT ["./popcorn.sh"]
这样 PID 1 就是 ./popcorn.sh，它将负责响应所有发送到容器的信号，至于 ./popcorn.sh 是否真的能捕捉到系统信号，那是另一回事。
举个例子，假设使用上面的 Dockerfile 来构建镜像，popcorn.sh 脚本每过一秒打印一次日期：
#!/bin/shwhile truedo date sleep 1done
构建镜像并创建容器：
???? → docker build -t truek8s/popcorn .???? → docker run -it --name corny --rm truek8s/popcorn
打开另外一个终端执行停止容器的命令，并计时：
???? → time docker stop corny
因为 popcorn.sh 并没有实现捕获和处理 SIGTERM 信号的逻辑，所以需要 10s 左右才能停止容器。要想解决这个问题，就要往脚本中添加信号处理代码，让它捕获到 SIGTERM 信号时就终止进程：
#!/bin/sh# catch the TERM signal and then exittrap "exit" TERMwhile truedo date sleep 1done
注意：下面这条指令与 shell 模式的 ENTRYPOINT 指令是等效的：
ENTRYPOINT ["/bin/sh", "./popcorn.sh"]
方案 2：直接使用 exec 命令
如果你就想使用 shell 模式的 ENTRYPOINT 指令，也不是不可以，只需将启动命令追加到 exec 后面即可，例如：
FROM alpine:3.7COPY popcorn.sh .RUN chmod +x popcorn.shENTRYPOINT exec ./popcorn.sh
这样 exec 就会将 shell 进程替换为 ./popcorn.sh 进程，PID 1 仍然是 ./popcorn.sh。
方案 3：使用 init 系统
如果容器中的应用默认无法处理 SIGTERM 信号，又不能修改代码，这时候方案 1 和 2 都行不通了，只能在容器中添加一个 init 系统。init 系统有很多种，这里推荐使用 tini，它是专用于容器的轻量级 init 系统，使用方法也很简单：
安装
tini将
tini设为容器的默认应用将
popcorn.sh作为tini的参数
具体的 Dockerfile 如下：
FROM alpine:3.7COPY popcorn.sh .RUN chmod +x popcorn.shRUN apk add --no-cache tiniENTRYPOINT ["/sbin/tini", "--", "./popcorn.sh"]
现在 tini 就是 PID 1，它会将收到的系统信号转发给子进程 popcorn.sh。
如果你想直接通过 docker 命令来运行容器，可以直接通过参数
--init来使用 tini，不需要在镜像中安装 tini。如果是Kubernetes就不行了，还得老老实实安装 tini。
3. 使用 tini 后应用还需要处理 SIGTERM 吗？
最后一个问题：如果移除 popcorn.sh 中对 SIGTERM 信号的处理逻辑，容器会在我们执行停止命令后立即终止吗？
答案是肯定的。在 Linux 系统中，PID 1 和其他进程不太一样，准确地说应该是 init 进程和其他进程不一样，它不会执行与接收到的信号相关的默认动作，必须在代码中明确实现捕获处理 SIGTERM 信号的逻辑，方案 1 和 2 干的就是这个事。
普通进程就简单多了，只要它收到系统信号，就会执行与该信号相关的默认动作，不需要在代码中显示实现逻辑，因此可以优雅终止。
上述就是小编为大家分享的Docker容器优雅终止方案是怎样的了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注行业资讯频道。
