Go 应用容器下优雅停止坑点
前言
之前我有写过 go 应用在 k8s 中如何优雅停止 的博客，理论上在配置好对应的参数之后就能 优雅停止 了，但是最近接触到了两个场景，会导致配置的优雅停止失效，为了避免踩坑，对于之前的博客进一步进行补充。
场景说明
有了之前的经验，Golang 应用本身没有问题，它已经接受并处理 SIGTERM 和 SIGINT 信号，但是实际场景出现的情况，在 k8s 或者 docker 停止的时候 有一些缓慢 ，但是由于最终容器还是会被关闭，于是这个问题就没有关注，这个现象也很容易被忽略。
package main
import (
"fmt"
"os"
"os/signal"
"syscall"
)
func main() {
fmt.Println("启动")
ch := make(chan os.Signal, 1)
signal.Notify(ch, syscall.SIGTERM, syscall.SIGINT)
s := <-ch
switch {
case s == syscall.SIGINT:
fmt.Println("收到 SIGINT 信号!")
case s == syscall.SIGTERM:
fmt.Println("收到 SIGTERM 信号!")
}
fmt.Println("退出")
}场景 1
这个场景非常简单，也是容易被使用到的一个场景
Dockerfile 是这样的
FROM alpine
ADD app /app
ADD entrypoint.sh /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh"]entrypoint.sh 是这样的
#!/bin/sh
/app这里是做了一定的抽象，由于这个入口脚步这个部分可能包含一些实际初始化的工作，这部分工作可能是程序没办法处理的环境等等问题，有兴趣的同学可以按下面的步骤测试一下。
GOOS=linux GOARCH=amd64 go build -o app .
docker build -t star .
docker run --name star star启动之后你就会发现一个问题，Ctrl+c 是没办法关闭的，执行 docker stop star 之后需要一段时间才会关闭，并且关闭之前没有任何信号相关的日志信息。
问题原因
这个场景出现问题的原因很简单，就是因为我们运行的方式是以脚步的方式运行的，主进程并不是业务的 app 而是 shell。而关闭时 SIGTERM 信号会发给 shell ，但是 shell 是不会把信号给你的。我们可以进入容器 ps 一下马上就清楚了。
docker exec -it star sh
/ # ps
PID USER TIME COMMAND
1 root 0:00 {entrypoint.sh} /bin/sh /entrypoint.sh
7 root 0:00 {app} [rosetta] /app /app
14 root 0:00 sh
20 root 0:00 ps解决
这个场景的解决方式非常简单，只需要修改一下脚步就可以了
#!/bin/sh
exec /app使用 exec 让新启动的 app 作为主进程就可以
docker exec -it star sh
/ # ps
PID USER TIME COMMAND
1 root 0:00 {app} [rosetta] /app /app
12 root 0:00 sh
18 root 0:00 ps场景 2
这个场景是，当我们的一个容器有多个进程的时候，入口脚步可能是这样的（这里是用同一个二进制模拟，实际场景可能是多个不同应用）
#!/bin/sh
/app &
/app我们没办法同时让两个进程都成为主进程，这个时候就要找外援帮忙了，dumb-init 就是一个不错的选择
FROM alpine
RUN apk add --no-cache dumb-init
ADD entrypoint.sh /entrypoint.sh
ADD app /app
ENTRYPOINT ["/usr/bin/dumb-init", "--"]
CMD ["/entrypoint.sh"]#!/usr/bin/dumb-init /bin/sh
/app &
/app同时 dumb-init 可以很容易的帮助我们实现信号的传递工作，以它作为主进程，以管理我们的应用子进程。
启动
启动
^C收到 SIGINT 信号!
退出
收到 SIGINT 信号!
退出总结
当然实际的项目中如果没有特别的需求，还是建议直接启动，而并非使用脚本，一旦使用脚本就需要注意信号和进程的特殊情况。并且，一个应用建议一个容器，这样可以避免很多问题。
腾讯云开发者
