容器轻松上阵,优雅下线才是胜负之道

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 容器轻松上阵,优雅下线才是胜负之道

概述

优雅关闭: 在关闭前,执行正常的关闭过程,释放连接和资源,如我们操作系统执行shutdown。

目前业务系统组件众多,互相之间调用关系也比较复杂,一个组件的下线、关闭会涉及到多个组件。

对于任何一个线上应用,如何保证服务更新部署过程中从应用停止到重启恢复服务这个过程中不影响正常的业务请求,这是应用开发运维团队必须要解决的问题。

传统的解决方式是通过将应用更新流程划分为手工摘流量、停应用、更新重启三个步骤,由人工操作实现客户端不对更新感知。这种方式简单而有效,但是限制较多:不仅需要使用借助网关的支持来摘流量,还需要在停应用前人工判断来保证在途请求已经处理完毕。

同时,在应用层也有一些保障应用优雅停机的机制,目前Tomcat、Spring Boot、Dubbo等框架都有提供相关的内置实现,如SpringBoot 2.3内置graceful shutdown可以很方便的直接实现优雅停机时的资源处理,同时一个普通的Java应用也可以基于Runtime.getRuntime().addShutdownHook()来自定义实现,它们的实现原理都基本一致,通过等待操作系统发送的SIGTERM信号,然后针对监听到该信号做一些处理动作。

优雅停机是指在停止应用时,执行的一系列保证应用正常关闭的操作。这些操作往往包括等待已有请求执行完成、关闭线程、关闭连接和释放资源等,优雅停机可以避免非正常关闭程序可能造成数据异常或丢失,应用异常等问题。优雅停机本质上是JVM即将关闭前执行的一些额外的处理代码

现状分析

现阶段,业务容器化后业务启动是通过shell脚本启动业务,对应的在容器内PID为1的进程为shell进程但shell 程序不转发signals,也不响应退出信号。所以在容器应用中如果应用容器中启动 shell,占据了 pid=1 的位置,那么就无法接收k8s发送的SIGTERM信号,只能等超时后被强行杀死了

关注--云原生百宝箱

行万里路,此处相逢,共话云原生之道。 偶逗趣事,明月清风,与君同坐。

案例分析

go开发的一个Demo

package main
import (
    "fmt"
    "os"
    "os/signal"
    "syscall"
    "time"
)
func main()  {
    c := make(chan os.Signal)
    signal.Notify(c, syscall.SIGTERM, syscall.SIGINT)
    go func() {
        for s := range c {
            switch s {
            case syscall.SIGINT, syscall.SIGTERM:
                fmt.Println("退出", s)
                ExitFunc()
            default:
                fmt.Println("other", s)
            }
        }
    }()
    fmt.Println("进程启动...")
    time.Sleep(time.Duration(200000)*time.Second)
}
func ExitFunc()  {
    fmt.Println("正在退出...")
    fmt.Println("执行清理...")
    fmt.Println("退出完成...")
    os.Exit(0)
}

1、Signal.Notify会监听括号内指定的信号,若没有指定,则监听所有信号。 2、通过switch对监听到信号进行判断,如果是SININT和SIGTERM则条用Exitfunc函数执行退出。

SHELL模式和CMD模式带来的差异性

在Dockerfile中CMD和ENTRYPOINT用来启动应用,有shell模式和exec模式

使用shell模式,PID为1的进程为shell;使用exec模式PID为1的进程为业务本身。

SHELL模式
FROM golang as builder
WORKDIR /go/
COPY app.go    .
RUN go build app.go
FROM ubuntu
WORKDIR /root/
COPY --from=builder /go/app .
CMD ./app

构建镜像

docker build -t app:v1.0-shell ./

运行查看

docker exec -it app-shell ps aux
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root           1  0.7  0.0   2608   548 pts/0    Ss+  03:22   0:00 /bin/sh -c ./
root           6  0.0  0.0 704368  1684 pts/0    Sl+  03:22   0:00 ./app
root          24  0.0  0.0   5896  2868 pts/1    Rs+  03:23   0:00 ps aux

可以看见PID为1的进程是sh进程

此时执行docker stop,业务进程是接收不到SIGTERM信号的,要等待一个超时时间后被KILL

日志没有输出SIGTERM关闭指令

docker stop app-shell
app-shell
docker logs app-shell
进程启动...
EXEC模式
FROM golang as builder
WORKDIR /go/
COPY app.go    .
RUN go build app.go
FROM ubuntu
WORKDIR /root/
COPY --from=builder /go/app .
CMD ["./app"]

构建镜像

docker build -t app:v1.0-exec ./

运行查看

docker exec -it app-exec ps aux
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root           1  2.0  0.0 703472  1772 pts/0    Ssl+ 03:33   0:00 ./app
root          14  0.0  0.0   5896  2908 pts/1    Rs+  03:34   0:00 ps aux

可以看见PID为1的进程是应用进程

此时执行docker stop,业务进程是可以接收SIGTERM信号的,会优雅退出

docker stop app-exec
app-exec
docker logs app-exec
进程启动...
退出 terminated
正在退出...
执行清理...
退出完成...

注意: 1、以上测试在ubuntu做为应用的base镜像测试成功,在alpine做为应用的base镜像时shell模式和exec模式都一样,都是应用进程为PID 1的进程。

直接启动应用和通过脚本启动区别

在实际生产环境中,因为应用启动命令后会接很多启动参数,所以通常我们会使用一个启动脚本来启动应用,方便我们启动应用。

对应的在容器内PID为1的进程为shell进程但shell 程序不转发signals,也不响应退出信号。所以在容器应用中如果应用容器中启动 shell,占据了 pid=1 的位置,那么就无法接收k8s发送的SIGTERM信号,只能等超时后被强行杀死了。

启动脚本

cat > start.sh<< EOF 
#!/bin/sh
sh -c /root/app

dockerfile

FROM golang as builder
WORKDIR /go/
COPY app.go    .
RUN go build app.go
FROM alpine
WORKDIR /root/
COPY --from=builder /go/app .
ADD start.sh /root/
CMD ["/bin/sh","/root/start.sh"]

构建应用

docker build -t app:v1.0-script ./

查看

docker exec -it app-script ps aux
PID   USER     TIME  COMMAND
1     root     0:00  /bin/sh /root/start.sh
6     root     0:00  /root/app
19    root     0:00  ps aux

docker stop关闭应用

docker stop app-script

是登待超时后被强行KILL

docker logs app-script
进程启动...

容器应用优雅关闭方案介绍

方案介绍

正常的优雅停机可以简单的认为包括两个部分:

  • 应用:应用自身需要实现优雅停机的处理逻辑,确保处理中的请求可以继续完成,资源得到有效的关闭释放,等等。针对应用层,不管是Java应用还是其他语言编写的应用,其实现原理基本一致,都提供了类似的监听处理接口,根据规范要求实现即可。
  • 平台:平台层要能够将应用从负载均衡中去掉,确保应用不会再接受到新的请求连接,并且能够通知到应用要进行优雅停机处理。在传统的部署模式下,这部分工作可能需要人工处理,但是在K8s容器平台中,K8s的Pod删除默认就会向容器中的主进程发送优雅停机命令,并提供了默认30s的等待时长,若优雅停机处理超出30s以后就会强制终止。同时,有些应用在容器中部署时,并不是通过容器主进程的形式进行部署,那么K8s也提供了PreStop的回调函数来在Pod停止前进行指定处理,可以是一段命令,也可以是一个HTTP的请求,从而具备了较强的灵活性。 通过以上分析,理论上应用容器化部署以后仍然可以很好的支持优雅停机,甚至相比于传统方式实现了更多的自动化操作,本文档后面会针对该方案进行详细的方案验证。
  • 容器应用中第三方Init:在构建应用中使用第三方init如tini或dumb-init

方案验证

方案一:通过k8s Prestop参数调用

通过k8s的prestop参数调用容器内进程关闭脚本,实现优雅关闭。

在前面脚本启动的dockerfile基础上,定义一个优雅关闭的脚本,通过k8s-prestop在关闭POD前调用优雅关闭脚本,实现pod优雅关闭。

启动脚本 start.sh

cat > start.sh<< EOF 
#!/bin/sh
./app

stop.sh 优雅关闭脚本

#!/bin/sh
ps -ef|grep app|grep -v grep|awk '{print $1}'|xargs kill -15

dockerfile

FROM golang as builder
WORKDIR /go/
COPY app.go    .
RUN go build app.go
FROM alpine
WORKDIR /root/
COPY --from=builder /go/app .
ADD start.sh /root/
CMD ["/bin/sh","/root/start.sh"]

构建镜像

docker build -t app:v1.0-prestop ./

通过yaml部署到k8s中

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-prestop
  labels:
    app: prestop
spec:
  replicas: 1
  selector:
    matchLabels:
      app: prestop
  template:
    metadata:
      labels:
        app: prestop
    spec:
      containers:
      - name: prestop
        image: 172.16.1.31/library/app:v1.0-prestop
        lifecycle:
          preStop:
            exec:
              command:
              - sh
              - /root/stop.sh

查看POD日志,然后删除pod副本

kubectl get pod 
NAME                            READY   STATUS    RESTARTS   AGE
app-prestop-847f5c4db8-mrbqr    1/1     Running   0          73s

查看日志

kubectl logs app-prestop-847f5c4db8-mrbqr -f
进程启动...

另外窗口删除POD

kubectl logs app-prestop-847f5c4db8-mrbqr -f
进程启动...
退出 terminated
正在退出...
执行清理...
退出完成...

可以看见执行了Prestop脚本进行优雅关闭。 同样的可以将yaml文件中的Prestop脚本取消进行对比测试可以发现就会进行强制删除。

方案二:shell脚本修改为exec执行

修改start.sh脚本

#!/bin/sh
exec ./app

shell中添加一个 exec 即可让应用进程替代当前shell进程,可将SIGTERM信号传递到业务层,让业务实现优雅关闭。

可使用上面例子,进行修改测试。

方案三:通过第三init工具启动

通过第三方init进程传递SIGTERM到进程中。

使用dump-init或tini做为容器的主进程,在收到退出信号的时候,会将退出信号转发给进程组所有进程。,主要适用应用本身无关闭信号处理的场景。docker–init本身也是集成的tini。

FROM golang as builder
WORKDIR /go/
COPY app.go    .
RUN go build app.go
FROM alpine
WORKDIR /root/
COPY --from=builder /go/app .
ADD start.sh tini /root/
RUN chmoad a+x start.sh && apk add --no-cache tini
ENTRYPOINT ["/sbin/tini", "--"]
CMD ["/root/tini", "--", /root/start.sh"]

首先运行了 /root/tini 作为初始化进程,然后启动了 /root/start.sh 脚本。这种设置有助于确保容器中的进程以正确的方式启动和终止,并处理信号,以便在容器停止时进行清理和关闭工作。

tini 是一个用于初始化进程并正确处理信号的工具,通常用于确保容器中的进程以正确的方式启动和终止。

构建镜像

docker build -t app:v1.0-tini ./

测试运行

docker run -itd --name app-tini app:v1.0-tini

查看日志

docker logs app-tini
进程启动...

发现容器快速停止了,但没有输出应用关闭和清理的日志

后面查阅相关资料发现

使用tini或dump-init做为应用启动的主进程。 tini和dumb-init会将关闭信号向子进程传递,但不会等待子进程完全退出后自己在退出。而是传递完后直接就退出了。

相关issue: https://github.com/krallin/tini/issues/180

后面又查到另外一个第三方的组件smell-baron能实现等待子进程优雅关闭后在关闭本身功能。 但这个项目本身热度不是特别高,并且有很久没有维护了。

FROM golang as builder
WORKDIR /go/
COPY app.go    .
RUN go build app.go
FROM ubuntu
WORKDIR /root/
COPY --from=builder /go/app .
ADD start.sh /root/
ADD smell-baron /bin/smell-baron
RUN chmod a+x /bin/smell-baron  && chmod a+x start.sh
ENTRYPOINT ["/bin/smell-baron"]
CMD ["/root/start.sh"]

构建镜像

docker build -t app:v1.0-smell-baron ./

测试

docker run -itd --name app-smell-baron app:v1.0-smell-baron
docker stop  app-smell-baron
进程启动...
退出 terminated
正在退出...
执行清理...
退出完成...

总结

  1. 1. 对于容器化应用启动命令建议使用EXEC模式。
  2. 2. 对于应用本身代码层面已经实现了优雅关闭的业务,但有shell启动脚本,容器化后部署到k8s上建议使方案一和方案二。
  3. 3. 对于应用本身代码层面没有实现优雅关闭的业务,建议使用方案三。

参考地址

  1. 1. https://github.com/insidewhy/smell-baron
  2. 2. https://github.com/Yelp/dumb-init
  3. 3. https://github.com/krallin/tini
相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
打赏
0
1
1
0
3331
分享
相关文章
《docker高级篇(大厂进阶):7.Docker容器监控之CAdvisor+InfluxDB+Granfana》包括:原生命令、是什么、compose容器编排,一套带走
《docker高级篇(大厂进阶):7.Docker容器监控之CAdvisor+InfluxDB+Granfana》包括:原生命令、是什么、compose容器编排,一套带走
275 77
|
20天前
|
《docker基础篇:3.Docker常用命令》包括帮助启动类命令、镜像命令、有镜像才能创建容器,这是根本前提(下载一个CentOS或者ubuntu镜像演示)、容器命令、小总结
《docker基础篇:3.Docker常用命令》包括帮助启动类命令、镜像命令、有镜像才能创建容器,这是根本前提(下载一个CentOS或者ubuntu镜像演示)、容器命令、小总结
104 6
《docker基础篇:3.Docker常用命令》包括帮助启动类命令、镜像命令、有镜像才能创建容器,这是根本前提(下载一个CentOS或者ubuntu镜像演示)、容器命令、小总结
在Docker容器中运行打包好的应用程序
在Docker容器中运行打包好的应用程序
docker 是什么?docker初认识之如何部署docker-优雅草后续将会把产品发布部署至docker容器中-因此会出相关系列文章-优雅草央千澈
Docker 是一个开源的容器化平台,允许开发者将应用程序及其依赖项打包成标准化单元(容器),确保在任何支持 Docker 的操作系统上一致运行。容器共享主机内核,提供轻量级、高效的执行环境。本文介绍如何在 Ubuntu 上安装 Docker,并通过简单步骤验证安装成功。后续文章将探讨使用 Docker 部署开源项目。优雅草央千澈 源、安装 Docker 包、验证安装 - 适用场景:开发、测试、生产环境 通过以上步骤,您可以在 Ubuntu 系统上成功安装并运行 Docker,为后续的应用部署打下基础。
docker 是什么?docker初认识之如何部署docker-优雅草后续将会把产品发布部署至docker容器中-因此会出相关系列文章-优雅草央千澈
容器化时代的领航者:Docker 和 Kubernetes 云原生时代的黄金搭档
Docker 是一种开源的应用容器引擎,允许开发者将应用程序及其依赖打包成可移植的镜像,并在任何支持 Docker 的平台上运行。其核心概念包括镜像、容器和仓库。镜像是只读的文件系统,容器是镜像的运行实例,仓库用于存储和分发镜像。Kubernetes(k8s)则是容器集群管理系统,提供自动化部署、扩展和维护等功能,支持服务发现、负载均衡、自动伸缩等特性。两者结合使用,可以实现高效的容器化应用管理和运维。Docker 主要用于单主机上的容器管理,而 Kubernetes 则专注于跨多主机的容器编排与调度。尽管 k8s 逐渐减少了对 Docker 作为容器运行时的支持,但 Doc
154 5
容器化时代的领航者:Docker 和 Kubernetes 云原生时代的黄金搭档
入门级容器技术解析:Docker和K8s的区别与关系
本文介绍了容器技术的发展历程及其重要组成部分Docker和Kubernetes。从传统物理机到虚拟机,再到容器化,每一步都旨在更高效地利用服务器资源并简化应用部署。容器技术通过隔离环境、减少依赖冲突和提高可移植性,解决了传统部署方式中的诸多问题。Docker作为容器化平台,专注于创建和管理容器;而Kubernetes则是一个强大的容器编排系统,用于自动化部署、扩展和管理容器化应用。两者相辅相成,共同推动了现代云原生应用的快速发展。
94 11
实战~如何组织一个多容器项目docker-compose
本文介绍了如何使用Docker搭建Nginx、PHP和MySQL的环境。首先启动Nginx容器并查看IP地址,接着启动Alpine容器并安装curl测试连通性。通过`--link`方式或`docker-compose`配置文件实现服务间的通信。最后展示了Nginx配置文件和PHP代码示例,验证了各服务的正常运行。
67 3
实战~如何组织一个多容器项目docker-compose
docker替换宿主与容器的映射端口和文件路径
通过正确配置 Docker 的端口和文件路径映射,可以有效地管理容器化应用程序,确保其高效运行和数据持久性。在生产环境中,动态替换映射配置有助于灵活应对各种需求变化。以上方法和步骤提供了一种可靠且易于操作的方案,帮助您轻松管理 Docker 容器的端口和路径映射。
158 3
深入理解容器化技术:Docker与Kubernetes的协同工作
深入理解容器化技术:Docker与Kubernetes的协同工作
89 14
Docker容器性能调优的关键技巧,涵盖CPU、内存、网络及磁盘I/O的优化策略,结合实战案例,旨在帮助读者有效提升Docker容器的性能与稳定性。
本文介绍了Docker容器性能调优的关键技巧,涵盖CPU、内存、网络及磁盘I/O的优化策略,结合实战案例,旨在帮助读者有效提升Docker容器的性能与稳定性。
187 7

热门文章

最新文章

AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等