前言
之前我有写过 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 是这样的
代码语言:javascript复制FROM alpine
ADD app /app
ADD entrypoint.sh /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh"]
entrypoint.sh
是这样的
#!/bin/sh
/app
这里是做了一定的抽象,由于这个入口脚步这个部分可能包含一些实际初始化的工作,这部分工作可能是程序没办法处理的环境等等问题,有兴趣的同学可以按下面的步骤测试一下。
代码语言:javascript复制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
解决
这个场景的解决方式非常简单,只需要修改一下脚步就可以了
代码语言:javascript复制#!/bin/sh
exec /app
使用 exec 让新启动的 app 作为主进程就可以
代码语言:javascript复制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
这个场景是,当我们的一个容器有多个进程的时候,入口脚步可能是这样的(这里是用同一个二进制模拟,实际场景可能是多个不同应用)
代码语言:javascript复制#!/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"]
代码语言:javascript复制#!/usr/bin/dumb-init /bin/sh
/app &
/app
同时 dumb-init
可以很容易的帮助我们实现信号的传递工作,以它作为主进程,以管理我们的应用子进程。
启动
启动
^C收到 SIGINT 信号!
退出
收到 SIGINT 信号!
退出
总结
当然实际的项目中如果没有特别的需求,还是建议直接启动,而并非使用脚本,一旦使用脚本就需要注意信号和进程的特殊情况。并且,一个应用建议一个容器,这样可以避免很多问题。