Docker容器重启慢？快来看看这些优雅终止方案，kafka原理pdf

Docker容器重启慢？快来看看这些优雅终止方案，kafka原理pdf

FROM alpine:3.7
COPY popcorn.sh .
RUN chmod +x popcorn.sh
ENTRYPOINT ./popcorn.sh

ENTRYPOINT 指令使用的是 shell 模式，这样 Docker 就会把应用放到 shell 中运行，因此 shell 是 PID 1。

解决方案有以下几种：

方案 1：使用 exec 模式的 ENTRYPOINT 指令

与其使用 shell 模式，不如使用 exec 模式，例如：

FROM alpine:3.7
COPY popcorn.sh .
RUN chmod +x popcorn.sh
ENTRYPOINT ["./popcorn.sh"]

这样 PID 1 就是 ./popcorn.sh，它将负责响应所有发送到容器的信号，至于 ./popcorn.sh 是否真的能捕捉到系统信号，那是另一回事。

举个例子，假设使用上面的 Dockerfile 来构建镜像，popcorn.sh 脚本每过一秒打印一次日期：

#!/bin/sh

while true
do
date
sleep 1
done

构建镜像并创建容器：

 → 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 exit

trap “exit” TERM

while true
do
date
sleep 1
done

注意：下面这条指令与 shell 模式的 ENTRYPOINT 指令是等效的：

ENTRYPOINT ["/bin/sh", “./popcorn.sh”]

方案 2：直接使用 exec 命令

如果你就想使用 shell 模式的 ENTRYPOINT 指令，也不是不可以，只需将启动命令追加到 exec 后面即可，例如：

FROM alpine:3.7
COPY popcorn.sh .
RUN chmod +x popcorn.sh
ENTRYPOINT exec ./

《一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》

【docs.qq.com/doc/DSmxTbFJ1cmN1R2dB】 完整内容开源分享

popcorn.sh

这样 exec 就会将 shell 进程替换为 ./popcorn.sh 进程，PID 1 仍然是 ./popcorn.sh。

方案 3：使用 init 系统

如果容器中的应用默认无法处理 SIGTERM 信号，又不能修改代码，这时候方案 1 和 2 都行不通了，只能在容器中添加一个 init系统。init 系统有很多种，这里推荐使用 tini，它是专用于容器的轻量级 init 系统，使用方法也很简单：

1. 安装 tini
2. 将 tini 设为容器的默认应用
3. 将 popcorn.sh 作为 tini 的参数

具体的 Dockerfile 如下：

FROM alpine:3.7
COPY popcorn.sh .
RUN chmod +x popcorn.sh
RUN apk add --no-cache tini
ENTRYPOINT ["/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 干的就是这个事。

普通进程就简单多了，只要它收到系统信号，就会执行与该信号相关的默认动作，不需要在代码中显示实现逻辑，因此可以优雅终止。

---