一种容器集群环境下构建云原生应用CICD流水线的方法与流程

一种容器集群环境下构建云原生应用cicd流水线的方法
技术领域
1.本发明涉及容器编排技术领域，具体为一种容器集群环境下构建云原生应用cicd流水线的方法。


背景技术：

2.随着云计算产业的不断发展，云原生底层核心技术也开始趋于成熟，细分领域的衍生技术呈井喷式爆发。容器、微服务、devops三大云原生核心技术中，通用的容器与容器编排技术已进入技术成熟期、市场采纳度高，在深化应用中诞生的边缘容器、多集群管理和容器安全均处于技术发展爆发期；微服务技术领域，服务注册发现与服务代理技术已进入技术成熟期，新一代微服务架构-服务网格也即将从技术爆发期进入整合期；devops处于技术整合期，市场采纳度初步攀升。
3.现有技术中，随着用户对云原生技术应用便捷化、免运维、一体化等需求增多，云原生中间件、无服务器架构的代表技术函数计算，以及云原生应用融合类技术如云原生ai、云原生区块链技术研究热度高涨，进入爆发期。云原生技术进入生产环境后，其安全性和稳定性成为应用关注的重点，系统稳定性、混沌工程、云原生安全技术等开始发展。
4.但是，随着数字化转型的推进，各行业头部企业都已经开始云上软件开发实践，并形成了良好的带头和示范作用。随着实践不断深入，云架构重塑了开发和运维模式、云测试打破了效能瓶颈进而提升软件质量、混沌工程保障了云上系统的稳定性。云软件工程正从技术架构升级、软件质量提升、系统稳定性保障三个维度打造云软件新格局。


技术实现要素：

5.本发明的目的在于提供一种容器集群环境下构建云原生应用cicd流水线的方法，以解决上述背景技术中提出的问题。
6.为实现上述目的，本发明提供如下技术方案：一种容器集群环境下构建云原生应用cicd流水线的方法，所述该方法包括：
7.通过gitlab进行代码管理及版本控制，并设置tag推送事件触发webhook，webhook触发jenkins流水线任务；
8.在jenkins中通过configure clouds配置容器集群，通过gitlab的webhook请求触发，配置的容器集群可以自动按需创建jenkins agent流水线执行器，执行jenkins流水线任务，流水线任务执行完毕后该执行器会自动销毁；
9.自定义jenkins pipeline流水线，拉取gitlab中的业务代码并进行代码打包，并将打包后的jar包发布到maven仓库、归档到jenkins服务器；
10.自定义jenkins pipeline流水线，自动生成打包“制品发布唯一编号”，将归档到jenkins服务器中的制品发布到gitlab仓库版本页，以供后期下载使用；
11.自定义jenkins pipeline流水线，拉取gitlab中的docker镜像构建配置代码，通过“制品发布唯一编号”作为镜像tag，通过kaniko进行docker镜像构建，并将构建的镜像推
送到本地harbor仓库；
12.根据harbor的多种镜像分发能力，实现镜像在不同仓库间的分发与同步；
13.自定义jenkins pipeline流水线，拉取gitlab中容器集群manifest或helm chart配置文件，将配置文件中的docker镜像tag修改为本次构建镜像的最新tag,并推送回gitlab仓库的固定分支；
14.gitlab仓库通过固定分支的push事件触发webhook，webhook触发argocd部署任务；
15.argocd自动同步gitlab中最新的容器集群manifest或helm chart配置文件，并根据其中配置的最新docker镜像tag,在本地docker仓库拉取镜像，并根据mainfest或chart的配置进行应用的自动部署。
16.优选的，自动化部署任务触发方式，进一步包括：
17.通过gitlab仓库进行代码管理及版本控制；
18.代码管理及版本控制就是通过gitlab仓库进行业务代码、docker镜像构建配置、容器集群manifest部署配置的代码管理及版本控制；
19.通过提交代码，添加并推送tag实现流水线任务触发。
20.优选的，jenkins pipeline流水线的执行步骤，进一步包括：
21.在jenkins配置中通过configure clouds进行容器集群配置；
22.详细的，配置容器集群的名称、api server地址、api server登录凭证、执行器自动创建所在命名空间、执行器启动最大数量、pod选择器标签、pod的执行超时时间等信息。
23.优选的，python脚本实现gitlab版本发布操作，进一步包括：
24.在jenkins中自定义的pipeline流水线中增加步骤，通过python脚本自动生成“制品发布唯一编号”，通过python的gitlab版本发布脚本将归档到本地jenkins中的制品发布到gitlab仓库版本页，以供他人下载使用。
25.优选的，python脚本实现docker镜像打包名称及tag组织操作，进一步包括：
26.在jenkins中自定义的pipeline流水线中增加步骤，拉取gitlab中容器集群manifest或helm chart配置文件，通过python脚本自动将配置文件中的docker镜像tag修改为本次构建的最新tag,并推送回gitlab仓库的固定分支。
27.优选的，argocd的webhook触发，进一步包括：
28.jenkins pipeline流水线修改镜像最新tag并提交gitlab后，gitlab仓库通过配置固定分支的push事件触发webhook，webhook触发argocd部署任务。
29.优选的，gitlab webhook触发自动部署任务后，argocd自动同步并拉取gitlab中最新的容器集群manifest或helm chart配置文件，并根据jenkins pipeline流水线中修改的最新docker镜像tag,在本地docker仓库拉取镜像，并根据mainfest或chart配置进行应用自动部署。
30.优选的，本地docker仓库拉取镜像，需要通过jenkins pipeline流水线构建镜像时将镜像直接推送的本地仓库，或是通过harbor镜像分发同步机制分发。
31.优选的，argocd自动部署，需要argocd中配置需部署的目的容器集群的api server连接信息。
32.与现有技术相比，本发明的有益效果是：
33.本发明提出的容器集群环境下构建云原生应用cicd流水线的方法通过应用的容器集群化部署，实现了应用镜像的版本化管理、应用的自动化部署、应用的滚动升级、应用的灵活扩缩容；
34.通过gitlab的webhook功能实现了代码打包、镜像打包、集群部署的自动化过程，减轻了研发、测试、运维等工作人员的工作量；
35.通过jenkins的pipeline流水线实现了多个工具的串联，实现了整个cicd过程的一体化，并结合argocd做到了对整个cicd执行过程的实时的可视化展示。
附图说明
36.图1为容器集群环境下构建云原生应用cicd流水线架构图；
37.图2为容器集群环境下构建云原生应用cicd流水线业务流程图；
38.图3为jenkins pipeline流水线执行流程图；
39.图4为容器集群环境下构建云原生应用cicd流水线部署流程图。
具体实施方式
40.为了使本发明的目的、技术方案进行清楚、完整地描述，及优点更加清楚明白，以下结合附图对本发明实施例进行进一步详细说明。应当理解，此处所描述的具体实施例是本发明一部分实施例，而不是全部的实施例，仅仅用以解释本发明实施例，并不用于限定本发明实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
41.在本发明的描述中，需要说明的是，术语“中心”、“中”、“上”、“下”、“左”、“右”、“内”、“外”、“顶”、“底”、“侧”、“竖直”、“水平”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。此外，术语“一”、“第一”、“第二”、“第三”、“第四”、“第五”、“第六”仅用于描述目的，而不能理解为指示或暗示相对重要性。
42.在本发明的描述中，需要说明的是，除非另有明确的规定和限定，术语“安装”、“相连”、“连接”应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本发明中的具体含义。
43.出于简明和说明的目的，实施例的原理主要通过参考例子来描述。在以下描述中，很多具体细节被提出用以提供对实施例的彻底理解。然而明显的是，对于本领域普通技术人员，这些实施例在实践中可以不限于这些具体细节。在一些实例中，没有详细地描述公知方法和结构，以避免无必要地使这些实施例变得难以理解。另外，所有实施例可以互相结合使用。
44.实施例一
45.请参阅图1至图4，本发明提供一种技术方案：一种容器集群环境下构建云原生应用cicd流水线的方法，所述该方法包括：
46.通过gitlab进行代码管理及版本控制，并设置tag推送事件触发webhook，webhook触发jenkins流水线任务；
47.在jenkins中通过configure clouds配置容器集群，通过gitlab的webhook请求触发，配置的容器集群可以自动按需创建jenkins agent流水线执行器，执行jenkins流水线任务，流水线任务执行完毕后该执行器会自动销毁；
48.自定义jenkins pipeline流水线，拉取gitlab中的业务代码并进行代码打包，并将打包后的jar包发布到maven仓库、归档到jenkins服务器；
49.自定义jenkins pipeline流水线，自动生成打包“制品发布唯一编号”，将归档到jenkins服务器中的制品发布到gitlab仓库版本页，以供后期下载使用；
50.自定义jenkins pipeline流水线，拉取gitlab中的docker镜像构建配置代码，通过“制品发布唯一编号”作为镜像tag，通过kaniko进行docker镜像构建，并将构建的镜像推送到本地harbor仓库；
51.根据harbor的多种镜像分发能力，实现镜像在不同仓库间的分发与同步；
52.自定义jenkins pipeline流水线，拉取gitlab中容器集群manifest或helm chart配置文件，将配置文件中的docker镜像tag修改为本次构建镜像的最新tag,并推送回gitlab仓库的固定分支；
53.gitlab仓库通过固定分支的push事件触发webhook，webhook触发argocd部署任务；
54.argocd自动同步gitlab中最新的容器集群manifest或helm chart配置文件，并根据其中配置的最新docker镜像tag,在本地docker仓库拉取镜像，并根据mainfest或chart的配置进行应用的自动部署。
55.实施例二
56.本发明实现了一种容器集群环境下构建云原生应用cicd流水线的方法，包括：
57.通过gitlab webhook的tag push事件实现代码发布后自动化部署任务的自动触发。
58.进一步地，所述自动化部署任务触发方式，进一步包括：
59.通过gitlab仓库进行代码管理及版本控制；
60.详细的，所述代码管理及版本控制就是通过gitlab仓库进行业务代码、docker镜像构建配置、容器集群manifest部署配置的代码管理及版本控制。
61.通过提交代码，添加并推送tag实现流水线任务触发；
62.详细的，代码发布人员发布业务代码后，通过gitlab添加本次发布的tag信息(包含本次发布的版本信息)，通过tag推送事件触发本次cicd流水线webhook，gitlab webhook向jenkins服务端发起对应项目的cicd流水线任务请求；
63.详细的，所述发布tag需要保证在当前项目仓库中的唯一性，通过此tag可以唯一的确定当前业务本次发布信息；
64.详细的，所述gitlab webhook需要配置jenkins中该业务发布所对应的pipeline的url及secret token信息，以便该pipeline可以被webhook正常发起。
65.通过构建jenkins pipeline流水线，实现后续gitlab代码拉取、代码打包、docker镜像打包推送、部署脚本更新。
66.进一步地，所述jenkins pipeline流水线的执行步骤，进一步包括：
67.在jenkins配置中通过configure clouds进行容器集群配置；
68.详细的，配置容器集群的名称、api server地址、api server登录凭证、执行器自动创建所在命名空间、执行器启动最大数量、pod选择器标签、pod的执行超时时间等信息；
69.详细的，配置pod模板，设置pod的名称(固定设置为jnlp)、命名空间、标签列表及标签匹配方式(只有jenkins pipeline中设置的agent标签选择器与该标签配置匹配时,才能发起对应的流水线任务)等信息；
70.详细的，在pod模板中创建容器模板，第一个容器模板名称固定设置为jnlp，且使用镜像为jenkins官方的jnlp-agent-maven或inbound-agent镜像，用于后端java业务代码打包发布以及归档到jenkins服务器的操作；第二个容器模板为python官方镜像，用于执行“gitlab中对应业务版本发布”、“docker镜像打包名称及tag自动生成”、“gitlab中容器集群manifest镜像tag更新提交”等复杂操作的脚本；第三个容器模板为kaniko官方镜像，用于docker镜像的构建及发布；第四个容器模板为nodejs官方镜像(也可以通过将前端依赖包提前打包到基础镜像中，来提高前端代码的打包效率)，用于前端vue.js代码打包操作；
71.详细的，当jenkins pipeline被gitlab webhook调起后，一个流水线执行器对应启动一个pod，一个pod中启动“jnlp python kaniko”三个容器或“jnlp python kaniko nodejs”四个容器；
72.详细的，所述容器模板中，所有容器需要设置相同的工作目录，并通过pod挂载emptydir存储卷方式实现多个容器相同工作目录的共享；
73.详细的，所述python脚本中的“gitlab中对应业务版本发布”脚本，是在后端java业务代码打包完成并归档到jenkins服务端后，通过该脚本调用gitlab api接口，将归档后的业务jar包url地址发布到gitlab的项目版本页面；
74.详细的，所述python脚本中的“docker镜像打包名称及tag自动生成”脚本分为两种：一种针对java代码，读取pom.xml配置文件中的项目id、版本等信息；一种针对nodejs代码，读取package.json配置文件中的项目id、版本等信息。结合拉取gitlab时获取到的代码tag信息，生成docker镜像打包时的名称和tag(格式如：《镜像仓库》/《项目id》:《gitlab tag》-《jenkins id》)；
75.详细的，所述python脚本中的“gitlab中容器集群manifest镜像tag更新提交”脚本，从gitlab拉取的容器集群manifest部署配置代码中查找需要升级业务对应的配置文件，匹配到对应的镜像设置部分代码，并将该代码中的镜像设置部分更新为最新构建的镜像名称及tag，之后通过jenkins将更新后的代码提交推送到gitlab仓库；
76.详细的，所述pod模板中设置的标签列表，需要与jenkins pipeline中设置的agent标签选择器一致，pod中需挂载本地maven仓库配置文件、docker登录配置文件、python复杂操作脚本等；
77.在jenkins中自定义pipeline流水线，拉取gitlab中业务代码并进行代码打包，打包时所需依赖通过配置的本地maven仓库拉取；
78.详细的，打包完成后，将打包的jar包文件归档到jenkins服务器并发布到本地maven仓库。
79.构建jenkins pipeline流水线过程中，通过python脚本方式实现gitlab版本发
布、docker镜像打包名称及tag组织、容器集群manifest镜像名称更新等复杂操作。
80.进一步地，所述python脚本实现gitlab版本发布操作，进一步包括：
81.在jenkins中自定义的pipeline流水线中增加步骤，通过python脚本自动生成“制品发布唯一编号”，通过python的gitlab版本发布脚本将归档到本地jenkins中的制品发布到gitlab仓库版本页，以供他人下载使用；
82.详细的，所述“制品发布唯一编号”，格式为gitlab tag jenkins id,保证了同一业务代码下的某一版本代码某一次构建的唯一性。
83.在jenkins中自定义的pipeline流水线中增加步骤，拉取gitlab中docker镜像构建配置代码，通过“制品发布唯一编号”作为镜像tag；
84.详细的，通过kaniko进行docker镜像构建，并将构建的镜像推送到本地harbor仓库；
85.详细的所述docker镜像构建所依赖的基础镜像，事先应该制作完成并推送到本地harbor仓库中，使得kaniko在进行镜像打包时可以直接拉取基础镜像。
86.根据现场不同的网络需求，利用harbor的推模式镜像复制、拉模式镜像复制、p2p分布式分发等多种方式，实现镜像在不同仓库间的分发与同步。
87.进一步地，所述python脚本实现docker镜像打包名称及tag组织操作，进一步包括：
88.在jenkins中自定义的pipeline流水线中增加步骤，拉取gitlab中容器集群manifest或helm chart配置文件，通过python脚本自动将配置文件中的docker镜像tag修改为本次构建的最新tag,并推送回gitlab仓库的固定分支；
89.详细的，所述本次构建的最新tag即为本次构建过程中所生成的“制品发布唯一编号”。
90.jenkins pipeline流水线更新部署脚本中的最新镜像tag后，推送到gitlab，gitlab通过webhook触发argocd的自动化部署过程。
91.进一步地，所述argocd的webhook触发，进一步包括：
92.jenkins pipeline流水线修改镜像最新tag并提交gitlab后，gitlab仓库通过配置固定分支的push事件触发webhook，webhook触发argocd部署任务。
93.详细的，所述webhook的触发需要在gitlab中配置push事件，在argocd中配置该gitlab仓库，在argocd中配置部署的目的集群、命名空间，在argocd中设置application以实现对该gitlab仓库的实时监听、实时同步。
94.argocd从gitlab拉取最新的部署脚本，并根据部署脚本部署目的容器集群的应用。
95.进一步地，所述argocd的自动化部署，进一步包括：
96.gitlab webhook触发自动部署任务后，argocd自动同步并拉取gitlab中最新的容器集群manifest或helm chart配置文件，并根据jenkins pipeline流水线中修改的最新docker镜像tag,在本地docker仓库拉取镜像，并根据mainfest或chart配置进行应用自动部署；
97.详细的，所述本地docker仓库拉取镜像，需要通过jenkins pipeline流水线构建镜像时将镜像直接推送的本地仓库，或是通过harbor镜像分发同步机制分发。
98.详细的，所述argocd自动部署，需要argocd中配置需部署的目的容器集群的api server连接信息。
99.实施例三
100.根据图2、图3、图4分别对cicd流水线业务流程、jenkins pipeline流水线执行流程、cicd流水线部署流程进行具体描述。
101.按照图4的操作流程进行cicd流水线的部署，依次进行如下操作：
102.创建至少三台linux虚拟机，用于部署容器集群；
103.通过helm部署traefik ingress controller，用于进行实现容器集群的统一入口流量管理；
104.通过helm部署harbor镜像仓库，用于业务镜像的版本控制，通过配置traefik设置镜像仓库的域名访问、ssl访问；
105.通过helm部署gitlab仓库，用于代码的版本控制，通过配置traefik设置镜像仓库的域名访问、ssl访问；
106.通过helm部署jenkins，用于管理cicd流水线，并在jenkins configure clouds中配置容器集群信息、pod模板配置信息等；
107.通过helm部署argocd，用于实现容器的自动化部署；
108.在gitlab仓库中创建业务代码、docker镜像构建配置代码、容器集群部署配置代码三个仓库；
109.在jenkins中创建对应业务的cicd流水线，并开启webhook服务监听；
110.在gitlab对应的业务代码仓库中配置jenkins webhook集成，主要配置jenkins中对应业务cicd流水线的webhook url和secret token，并创建tag push webhook；
111.在gitlab的容器集群部署配置代码仓库中配置argocd webhook集成，主要配置argocd中的webhook url和secret token，并创建push webhook；
112.在argocd中配置gitlab的容器集群部署配置代码仓库信息、部署的目的容器集群信息，并创建对应的application，用于同步gitlab的容器集群部署配置代码，并将代码部署到目的容器集群中。
113.尽管已经示出和描述了本发明的实施例，对于本领域的普通技术人员而言，可以理解在不脱离本发明的原理和精神的情况下可以对这些实施例进行多种变化、修改、替换和变型，本发明的范围由所附权利要求及其等同物限定。