一种基于容器技术的并行自动化GitOps系统的制作方法

一种基于容器技术的并行自动化gitops系统
技术领域
1.本发明涉及软件开发领域，具体涉及一种基于容器技术的并行自动化gitops系统。


背景技术：

2.在一个中小型企业研发团队中，通常会采用基于springcloud分布式架构进行web业务系统项目开发，它可以很好的将业务功能模块更细粒度的划分，更合理的为工作人员分配功能模块相关的开发和测试任务，而且该架构也能很好地适应当下主流的容器技术，快速将业务系统上云，享受云原生带来的便利。同时为了提高整个项目的版本迭代速度，企业通常会采用jenkins等自动化ci/cd工具，来打通项目从gitlab代码仓库自动编译构建打包推送到开发、测试运行环境以及生产环境的流水线，进而达到敏捷开发测试和循环持续交付的目的。但是当团队在并行开发迭代多个业务系统项目时，由于每个业务系统项目不完全独立，相互之间存在一定的依赖关系。例如，不同的业务系统项目中可能会包含部分相同的基础公共微服务，同一个业务系统项目中也会包含被当前业务系统中其他微服务所依赖的基础公共微服务。为了避免业务系统项目中复杂的依赖关系引起编译构建过程中产生冲突，进而导致开发运行环境和测试运行环境的不稳定，需要多台服务器资源为每个项目搭建独立的流水线运行环境、开发运行环境、测试运行环境以达到对不同项目进行环境隔离的目的，从而保证不同项目的并行开发、测试过程不会因为相互干扰，引发环境异常，影响交付进度。
3.但是一般中小型企业的人力资源和硬件基础设施资源的配置往往滞后于业务的发展速度，如果每台服务器只为单个项目提供运行环境，由于工作负载低，那么服务器的cpu以及内存等资源余量较大，会导致资源利用率很低，是一种极大的浪费和消耗。同时在这种使用方式下，当团队突然新增了一个项目，或者项目中新增一个微服务，或者为项目新增一个独立开发、测试小组时，现有的资源可能无法满足为不同的项目搭建独立的开发、测试运行环境，需要购买新的设备资源，也是一笔不小的开销。同时为业务系统项目搭建新的环境，也需要花费很长的时间和一定的人力成本，一般很难在短时间内快速的搭建好新项目所需的环境。因此在资源有限的前提下，满足对多个业务系统项目进行并行开发、测试的需求是一个很大的挑战。
4.同时即便给一个业务系统项目搭建了独立的开发、测试运行环境，如果一个项目功能模块复杂，需要多个开发、测试小组进行协同工作时，如果小组之间共享业务系统项目的同一个分支，同一套开发环境，同一套测试环境进行版本迭代。此时很容易由于双方开发和测试的进度不同步，发布上线前，需要将其中一方未能验证通过的功能代码，全部清理干净，才能发布上线，否则会导致将其中一个小组未经测试验证的功能模块代码携带发布到生产环境，造成极差的用户体验。或者较早完成开发、测试任务的一方需要等待另一方也同样完成开发、测试任务后，才能一起更新代码发布到生产环境，这样往往容易导致发布上线延期，无法正常交付项目。同时在协同开发过程中，如果两个开发小组开发的不同功能模块
依赖同一个基础公共服务，当对该基础公共服务做了不同修改时，还会导致另一方本来已经测试验证通过的功能反复出现异常，处理这些异常问题，是对人力资源的过渡消耗。
5.在基于springcloud分布式微服务架构的业务系统中，由于包含了大量的微服务，每个微服务的代码中往往耦合了一些包含环境变量的脚本文件以及跟业务逻辑无关的自动化ci/cd部署脚本文件，这种方式虽然让开发人员能够很方便的查看和自定义配置文件内容，但环境相关配置文件分布碎片化，与代码耦合度高，也会极大增加配置文件内容变更维护的复杂度，同时有一些关键敏感信息也会暴露给所有的开发人员。


技术实现要素：

6.本发明的目的是解决研发团队在并行迭代演进多个业务系统项目时存在的代码管理和运行环境管理复杂度高，服务器资源利用率低的问题以及环境相关配置文件和自动化ci/cd脚本文件分布碎片化，与代码耦合度高，信息变更维护成本代价高的问题，提出了一种基于容器技术的多项目多小组并行开发、测试的自动化gitops系统。
7.一种基于容器技术的并行自动化gitops系统，包括：
8.统一gitlab代码仓库运行环境模块，基于容器引擎构建，被配置为存放开发人员提交的代码的环境，同时为容器化的中间件服务提供基础运行环境；
9.统一流水线任务容器运行环境模块，基于容器引擎构建，被配置为运行持续集成工具，同时按照所属分支类型为属于不同分支的流水线任务挂载属于该分支单独的仓库；
10.统一业务容器开发运行环境模块，基于容器引擎构建，被配置为提供各个不同业务系统项目的各个小组之间相互资源隔离的自测环境，同时为其中的微服务容器提供映射到宿主机的端口；
11.统一业务容器测试运行环境模块，基于容器引擎构建，被配置为提供各个不同业务系统项目的各个小组之间相互资源隔离的验证环境，同时为其中的微服务容器提供映射到宿主机的端口；
12.统一业务容器生产运行环境模块，基于容器引擎构建，被配置为提供各个不同业务系统项目的各个小组之间相互资源隔离的生产运行环境，同时为其中的微服务容器提供映射到宿主机的端口。
13.优选的，所述容器引擎为kubernetes。
14.优选的，所述基础运行环境包括keepalived集群、haproxy集群、nacos集群、mariadb集群、redis集群、rabbitmq集群、seata集群、minio集群、harbor集群。
15.优选的，所述持续集成工具为jenkins，所述仓库为maven仓库。
16.优选的，所述资源隔离的方法为利用kubernetes的namespace的资源隔离能力实现。
17.优选的，所述为其中的微服务容器提供映射到宿主机的端口的方法为利用kubernetes的nodeport服务实现。
18.有益效果：
19.1.基于gitops的多小组协同工作并行完成持续集成，持续部署，发布上线的工作模式；技术效果：当一个业务系统项目功能模块复杂，上线时间紧急，需要更多的开发、测试人员来加速项目版本迭代交付进程的时候，利用这种工作模式，能够更加充分的利用人力
资源，更加细粒度的划分开发任务，在相互不冲突，运行环境稳定的前提下，多线程并行工作能够极大提高了团队成员的工作效率，加快了项目版本迭代交付上线的速度，同时也能够提高了团队协同工作的灵活性。
20.2.环境配置信息文件与微服务代码分离和统一管理技术；技术效果：将前后端微服务的相关配置文件统一放在nacos配置中心进行管理，在前端容器中增加一个启动时自动获取nacos配置文件的脚本，将nacos相关的环境变量信息统一利用kubernetes的configmap进行管理，将jenkinsfile文件利用jenkins的远程触发机制统一放在资源配置共享库中进行统一管理，每个微服务代码中不必再直接集成和环境相关的配置信息文件，能够有效降低代码和环境配置信息的耦合度，极大降低了信息变更维护的复杂度，同时也很好的对开发者隐藏了一些敏感的环境信息，降低了运行环境的安全风险，提高了稳定性和可靠性。
21.本发明与现有技术相比具有三个方面的优势：第一，能够充分利用服务器的计算和存储能力，多项目共享同一个流水线环境、同一个开发运行环境，同一个测试运行环境，在保证各个项目没有环境冲突的情况下，能够有效节约服务器资源，提高资源利用率。第二，能够有效降低代码和环境变量的耦合程度，统一高效管理不同项目不同分支下前后端微服务以及运行环境相关的配置文件，缩短了配置文件中相关环境变量的变更维护时间，降低了配置文件单副本无历史修改记录的风险。第三，适用于多项目多小组并行开发迭代，统一的代码管理和构建交付流程，同时能够按照团队人力资源的规模，项目的数量，灵活快速的组建多个开发、测试小组，满足在新增业务系统项目，以及项目下新增微服务的场景时仍然能够达到敏捷开发测试，循环持续交付的需求。
附图说明
22.图1为本发明的统一运行环境组成结构图；
23.图2为实施例中的统一联邦集群管理图；
24.图3为实施例中统一流水线任务容器环境仓库隔离图；
25.图4为实施例中统一业务容器运行环境映射端口规划图；
26.图5为实施例中统一业务容器高可用运行环境架构图；
27.图6为实施例中多项目多小组并行开发测试交付结构图；
28.图7为实施例中gitops系统的执行流程图。
具体实施方式
29.为了尽可能利用有限的基础设施资源，满足多项目多小组并行开发、并行测试的目的，首先将基础设施资源重新进行规划，如图1所示，主要有五大部分组成，统一gitlab代码仓库运行环境，统一流水线任务容器运行环境，统一业务容器开发运行环境，统一业务容器测试运行环境，统一业务容器生产运行环境。以上运行环境全部基于kubernetes容器引擎构建基础支撑平台，利用kubernetes的容器管理和调度能力以及自愈能力和弹性伸缩能力，为基础运行环境的稳定性提供了保障。同时利用kubernetes集群联邦机制，如图2所示，利用统一控制平面来管理多个kubernetes集群环境。
30.(1)统一gitlab代码仓库运行环境模块
31.统一gitlab代码仓库运行环境，主要用来存放开发人员提交的代码，也是自动化ci/cd的起点，同时该环境还为容器化的中间件服务提供了基础运行环境，包括keepalived集群、haproxy集群、nacos集群、mariadb集群、redis集群、rabbitmq集群、seata集群、minio集群、harbor集群等。
32.(2)统一流水线任务容器运行环境模块
33.统一流水线任务容器运行环境，主要是用来为运行jenkins服务，针对于多项目多小组并行开发过程中流水线任务并发的数量大，因此需要提供一个单独的运行环境，保证多个构建任务同时被触发的情况下不会引发排队阻塞，提升流水线构建任务的响应速度和执行效率，但后端微服务的编译构建一般依靠maven包管理工具来完成，jenkins中通常使用挂载宿主机唯一的maven仓库来完成编译构建的工作，当多个构建流水线任务同时执行的时候，由于代码中存在相互依赖的关系，不同分支的环境不能共享同一个maven仓库，如图3所示，需要为每个分支的流水线任务挂载单独的maven仓库存储编译后的jar包。
34.(3)统一业务容器开发运行环境模块
35.统一业务容器开发运行环境，主要用来为不同业务系统项目的多开发小组提供业务功能自测环境，利用kubernetes的namespace的资源隔离能力，保证归属于的各个开发小组的不同业务系统项目之间不会相互影响。同时利用nodeport的方式为微服务容器提供映射到宿主机的端口，保证开发人员可以通过本地环境远程调用业务系统微服务接口进行远程断点调试，由于多项目的情况下，微服务众多，需要开通的端口数量也很多，为了防止端口分配混乱，如图4所示，要对每个微服务占用的端口进行统一的规划。
36.(4)统一业务容器测试运行环境模块
37.统一业务容器测试运行环境，主要用来为不同业务系统项目的多测试小组提供业务功能验证环境。和开发环境类似。
38.(5)统一业务容器生产运行环境模块
39.统一业务容器生产运行环境，主要用来为不同业务系统项目提供生产运行环境，为线上真实用户提供业务服务能力。该运行环境利用高可用架构的设计原则，如图5所示，构建高可用kubernetes集群以及高可用中间件服务，满足企业级生产环境的需求。
40.具体的，图3为每个分支的流水线任务提供了一个专属的独立存储空间，专门用来存储流水线编译构建后的jar包和不同版本的依赖包，每个流水线任务pod与指定的项目和指定的环境一一对应。例如，pod-a-dev-1流水线任务执行过程中所使用的所有依赖包，都只在该a-dev-1的存储空间中，能够避免其他分支的同名jar包的覆盖，因为不同分支的代码开发进度不一致，一旦共享同一个存储空间，会引起业务系统功能模块异常和服务版本依赖的管理混乱。
41.图4是为不同业务系统运行环境ip地址和微服务的占用端口情况的全局统一规划，例如，a项目的不同运行环境主要由物理机隔离，同时通过ip地址来区分，a项目的不同微服务之间通过全局统一规划的端口号进行区分。这样能够便于项目和微服务的灵活扩展，避免不同项目不同微服务之间的端口冲突，同时也非常便于开发人员将远程的部分微服务和本地的部分微服务进行联合断点调试。
42.图5是为分布式微服务业务系统构建的高可用架构的运行环境，首先由3个节点构成基础的运行环境，在此基础上搭建kubernetes集群、keepalived集群、haproxy集群、
nacos集群、mariadb集群、redis集群、rabbitmq集群、seata集群、minio集群等，利用vip的方式为业务系统和中间件之间的调用提供动态负载均衡和反向代理能力，同时利用ip漂移的能力避免节点宕机风险。
43.以业务系统项目a为例，如图6所示，假设项目分成了两个开发小组和两个测试小组对项目并行开发和测试，首先在代码仓库中为业务系统项目所有的微服务建立a-master分支，然后为a-group01开发小组创建a-dev-1分支和a-test-1分支，为a-group02开发小组创建a-dev-2分支和a-test-2分支，然后为每个微服务配置好webhook，通过推送事件和合并事件触发属于业务系统项目a的不同分支的自动化构建流水线任务。这些流水线任务主要是在统一流水线任务容器运行环境中，通过jenkins来并行执行多个自动化构建流水线任务，通过对源码编译构建打包成容器镜像，再推送更新部署到统一业务容器开发运行环境，经过开发人员初步自测业务功能后，自行将符合预期的业务功能代码合并到a-test-x分支中，进一步自动触发流水线任务对源码编译构建打包成容器镜像，再推送更新部署到统一业务容器测试运行环境，经过测试人员全面验证通过后封版，最后再由开发负责人将封版的代码从a-test-x分支合并到a-master分支，由运维人员发布更新上线到统一业务容器生产运行环境中。
44.基于gitops系统的执行流程，如图7所示，在gitlab中创建共享库，利用静态资源清单文件对不同项目不同分支的pipeline以及运行环境中的容器状态和环境基本信息进行声明性描述。以此共享库作为运行环境中最终交付结果的单一事实来源，统一高效地对应用程序、基础架构、部署和环境所做的更改都通过git进行管理。开发人员提交代码到gitlab代码仓库，通过webhook触发jenkins对应的流水线执行构建任务，jenkins接收到请求后会拉取共享库中的源代码，同时加载指定目录下的流水线脚本文件，按照脚本文件中规定的执行流程拉取对应分支源码，编译构建打包推送容器镜像，同时更新资源配置共享库中额工作负载镜像标签，最后在业务容器运行环境中拉取最新的源代码文件，按照更改后的静态资源清单文件，获取最新容器镜像，同时滚动更新k8s集群中的工作负载。

技术特征：
1.一种基于容器技术的并行自动化gitops系统，其特征在于包括：统一gitlab代码仓库运行环境模块，基于容器引擎构建，被配置为存放开发人员提交的代码的环境，同时为容器化的中间件服务提供基础运行环境；统一流水线任务容器运行环境模块，基于容器引擎构建，被配置为运行持续集成工具，同时按照所属分支类型为属于不同分支的流水线任务挂载属于该分支单独的仓库；统一业务容器开发运行环境模块，基于容器引擎构建，被配置为提供各个不同业务系统项目的各个小组之间相互资源隔离的自测环境，同时为其中的微服务容器提供映射到宿主机的端口；统一业务容器测试运行环境模块，基于容器引擎构建，被配置为提供各个不同业务系统项目的各个小组之间相互资源隔离的验证环境，同时为其中的微服务容器提供映射到宿主机的端口；统一业务容器生产运行环境模块，基于容器引擎构建，被配置为提供各个不同业务系统项目的各个小组之间相互资源隔离的生产运行环境，同时为其中的微服务容器提供映射到宿主机的端口。2.根据权利要求1所述的一种基于容器技术的并行自动化gitops系统，其特征在于所述容器引擎为kubernetes。3.根据权利要求1所述的一种基于容器技术的并行自动化gitops系统，其特征在于所述基础运行环境包括keepalived集群、haproxy集群、nacos集群、mariadb集群、redis集群、rabbitmq集群、seata集群、minio集群、harbor集群。4.根据权利要求1所述的一种基于容器技术的并行自动化gitops系统，其特征在于所述持续集成工具为jenkins，所述仓库为maven仓库。5.根据权利要求2所述的一种基于容器技术的并行自动化gitops系统，其特征在于所述资源隔离的方法为利用kubernetes的namespace的资源隔离能力实现。6.根据权利要求2所述的一种基于容器技术的并行自动化gitops系统，其特征在于所述为其中的微服务容器提供映射到宿主机的端口的方法为利用kubernetes的nodeport服务实现。

技术总结
本发明涉及软件开发领域，具体涉及一种基于容器技术的并行自动化GitOps系统，包括：统一Gitlab代码仓库运行环境，存放开发人员提交的代码的环境,同时为容器化的中间件服务提供基础运行环境；统一流水线任务容器运行环境，运行持续集成工具，同时按照所属分支类型为属于不同分支的流水线任务挂载属于该分支单独的仓库；统一业务容器开发运行环境，提供各个不同业务系统项目的各个小组之间相互资源隔离的自测环境，同时为其中的微服务容器提供映射到宿主机的端口；统一业务容器测试运行环境；统一业务容器生产运行环境。本发明能够充分利用服务器的计算和存储能力，在保证各个项目没有环境冲突的情况下，能够有效节约服务器资源，提高资源利用率。提高资源利用率。提高资源利用率。


技术研发人员：覃万里 唐宏伟 潘志伟 胡浩
受保护的技术使用者：中科南京信息高铁研究院
技术研发日：2023.05.04
技术公布日：2023/7/22