前言

之前我有写过 go 应用在 k8s 中如何优雅停止 的博客，理论上在配置好对应的参数之后就能 优雅停止 了，但是最近接触到了两个场景，会导致配置的优雅停止失效，为了避免踩坑，对于之前的博客进一步进行补充。

场景说明

有了之前的经验，Golang 应用本身没有问题，它已经接受并处理 SIGTERM 和 SIGINT 信号，但是实际场景出现的情况，在 k8s 或者 docker 停止的时候 有一些缓慢 ，但是由于最终容器还是会被关闭，于是这个问题就没有关注，这个现象也很容易被忽略。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
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 是这样的

1
2
3
4
FROM alpine
ADD app /app
ADD entrypoint.sh /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh"]

entrypoint.sh 是这样的

1
2
#!/bin/sh
/app

这里是做了一定的抽象，由于这个入口脚步这个部分可能包含一些实际初始化的工作，这部分工作可能是程序没办法处理的环境等等问题，有兴趣的同学可以按下面的步骤测试一下。

1
2
3
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 一下马上就清楚了。

1
2
3
4
5
6
7
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

解决

这个场景的解决方式非常简单，只需要修改一下脚步就可以了

1
2
#!/bin/sh
exec /app

使用 exec 让新启动的 app 作为主进程就可以

1
2
3
4
5
6
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

这个场景是，当我们的一个容器有多个进程的时候，入口脚步可能是这样的（这里是用同一个二进制模拟，实际场景可能是多个不同应用）

1
2
3
#!/bin/sh
/app &
/app

我们没办法同时让两个进程都成为主进程，这个时候就要找外援帮忙了，dumb-init 就是一个不错的选择

1
2
3
4
5
6
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"]
1
2
3
#!/usr/bin/dumb-init /bin/sh
/app &
/app

同时 dumb-init 可以很容易的帮助我们实现信号的传递工作，以它作为主进程，以管理我们的应用子进程。

1
2
3
4
5
6
启动
启动
^C收到 SIGINT 信号!
退出
收到 SIGINT 信号!
退出

总结

当然实际的项目中如果没有特别的需求，还是建议直接启动，而并非使用脚本，一旦使用脚本就需要注意信号和进程的特殊情况。并且，一个应用建议一个容器，这样可以避免很多问题。