在“docker Kill --signal=SIGX”上以这种方式关闭在容器内运行的 go 应用程序是否安全？

小伙伴们有没有觉得学习Golang很有意思？有意思就对了！今天就给大家带来《在“docker Kill --signal=SIGX”上以这种方式关闭在容器内运行的 go 应用程序是否安全？》，以下内容将会涉及到，若是在学习中对其中部分知识点有疑问，或许看了本文就能帮到你！

上下文

docker 容器内有一个应用程序正在运行。当发送 docker stop %container_id% 时，容器收到 sigterm。该信号在 golang 应用程序内部通过退出前执行清理代码进行处理。在这种情况下，代码是退出前的单个日志语句。

问题

1. 是否保证在该语句执行之前容器不会停止存在？
2. 如果是，是否适用于其他信号？
3. 如果没有，是否存在适用于此的信号？

func main() {
    http.HandleFunc("/", func(rw http.ResponseWriter, r *http.Request) {
        fmt.Fprintln(rw, "chirtkem mudila")
    })

    go func() {
        if err := http.ListenAndServe(":8080", nil); err != nil {
            log.Fatal(err)
        }
    }()

    interupt := make(chan os.Signal, 1)
    signal.Notify(interupt, syscall.SIGTERM, syscall.SIGINT)
    <-interupt

    log.Println("graceful shutdown") // is it guaranteed to execute before container ceases to exist?
}

正确答案

如果 docker stop %container_id% docker 发送 sigterm 并等待 timeout（默认 10 秒），然后发送 sigkill。

此超时可使用 --time 选项进行配置，docs

Usage:  docker stop [OPTIONS] CONTAINER [CONTAINER...]
Stop one or more running containers
Options:
  -t, --time int   Seconds to wait for stop before killing it (default 10)

因此（1）如果语句花费的时间超过此时间，则不能保证容器在语句完成期间仍处于活动状态。

对于（2）和（3），由于（1）是否，并且 docker stop 对信号没有覆盖，不适用于其他信号。

docker kill 对信号有一个覆盖，默认为 sigkill，带有 --signal 标志。 docs

虽然默认 (sigkill) 信号将终止容器，但 通过 --signal 设置的信号可能是非终结符，具体取决于 容器的主要流程。例如，大多数情况下的 sighup 信号 将是非终端，并且容器将在之后继续运行 接收信号。

因此，根据命令中提供的信号，容器在信号处理后可能会也可能不会被杀死。

理论要掌握，实操不能落！以上关于《在“docker Kill --signal=SIGX”上以这种方式关闭在容器内运行的 go 应用程序是否安全？》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！