CN111309441A - 一种基于Jenkins实现DevOps的微服务部署方法 - Google Patents

Abstract

本发明涉及一种基于Jenkins实现DevOps的微服务部署方法，本发明提供的技术方案，应用的配置文件使用变量的方式，在运行时读取相应的环境变量即可运行起来，这样可以做到多环节运行的应用的配置文件的统一性。通过提前规范和统一化配置，利用gitlab+jenkins流水线完成自动的构建、打包，生成可以管理镜像和配置文件的helm chart，从而部署到各个环境，大大降低了人为的沟通成本和误操作的可能，提高了效率。另外，变量的命名一目了然，让开发人员更方便理解自己使用的环境，让运维人员有更好的维护性和检索性。生成的helm chart和docker images存放到harbor仓库中，因为helm里记录了变量、版本、以及配置文件等相关信息，因此可以做到历史版本的可追溯性。

Description

一种基于Jenkins实现DevOps的微服务部署方法

技术领域

本发明涉及微服务部署技术领域，具体涉及一种基于Jenkins实现DevOps的微服务部署方法。

背景技术

随着docker技术的发展以及kubernetes容器管理平台的出现，给传统的服务架构带来演变和更新，微服务架构被越来越多的企业所青睐。它带来了很多优点：将服务拆分地更细，有利于资源的利用。去中心化、解耦合的设计，使得单个服务更具有可维护性，提高开发效率，迭代周期更短。但由于开发的便利和高效性也导致了微服务的服务数量大大增加，也导致了其服务的治理成本变高。庞大的***、复杂的环境、数量众多的服务，以及生产、开发、测试环境的不对等，大大增加了开发人员对环境和所使用技术的理解和要求，无论是单点到集群的转变，亦或者环境复用带来的对环境用途的不明了，又或者是对环境所使用技术本身的不了解，导致从开发环境到测试环境再到部署生产每一步都变得更加坎坷。人为的沟通成本日益增加，降低了工作的效率，增加了线上部署因人为不确定性导致的故障概率。

因此有着各种各样的解决方案，像kubernetes容器管理平台有着自带的解决方案，通过共同约定的配置信息创建configmap统一管理应用所使用的变量，从而达到服务标准化管理的作用。但跨namespace无法复用性导致了configmap的管理成本升高，无法中心化管理和配置，一旦出现多环境多namespace的管理，其实用性将被大大降低。

由于微服务技术的演变和成熟，使得应用服务变得轻量化、松耦合，加速了应用的可迭代性，为达到敏捷开发、持续集成的目的，Devops有着重要作用。但和传统应用相比，耦合性的拆分导致了服务管理上变得更加复杂。不可胜数的微服务的部署工作，不同环境之前的差异化配置等问题，配置和应用版本无法对应等问题日益凸显，增加了各部门之前的沟通成本，存在人为错误导致上线失败的隐患。

本申请涉及的技术名词解释：

DevOps：DevOps(Development和Operations的组合词)是一组过程、方法与***的统称，用于促进开发(应用程序/软件工程)、技术运营和质量保障(QA)部门之间的沟通、协作与整合。它是一种重视“软件开发人员(Dev)”和“IT运维技术人员(Ops)”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

Kubernetes：简称K8s，是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效(powerful)，Kubernetes提供了应用部署，规划，更新，维护的一种机制。

微服务:微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构(在现有***中分布一个API)区分开来。

Helm：Helm是Kubernetes的包管理器。包管理器类似于我们在Ubuntu中使用的apt、Centos中使用的yum或者Python中的pip一样，能快速查找、下载和安装软件包。

Docker：Docker是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的镜像中，然后发布到任何流行的Linux或Windows机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口。

Jenkins：Jenkins是一个开源软件项目，是基于Java开发的一种持续集成工具，用于监控持续重复的工作，旨在提供一个开放易用的软件平台，使软件的持续集成变成可能。

Gitlab：GitLab是一个用于仓库管理***的开源项目，使用Git作为代码管理工具，并在此基础上搭建起来的web服务。

Namespace:Kubernetes中的命名空间，可以认为namespaces是你kubernetes集群中的虚拟化集群。在一个Kubernetes集群中可以拥有多个命名空间，它们在逻辑上彼此隔离。

Configmap:ConfigMap是用来存储配置文件的kubernetes资源对象，所有的配置内容都存储在etcd中。使用方式可以直接挂在到配置目录用已文件的方式来提供，也可以将其存储的key:values赋予某些变量和方法来使用。

Helm chart：Helm的软件包，采用TAR格式(一种常见的linux打包方式)。类似linux中的包管理工具，如APT的DEB包或者YUM的RPM包。其包含了一组定义Kubernetes资源相关的YAML文件。

deployment、statefulset、daemonset：为Kubernetes中的pod管理器，分别为无状态容器集，有状态容器集，守护型应用集。

发明内容

有鉴于此，本发明的目的在于克服现有技术的不足，提供一种基于Jenki ns实现DevOps的微服务部署方法，以解决现有技术中微服务的数量日益增长，多环境管理的差异化导致复杂度、治理成本及沟通成本越来越高的问题。

为实现以上目的，本发明采用如下技术方案：

一种基于Jenkins实现DevOps的微服务部署方法，包括：

步骤S1、确定待开发的项目所需变量；

步骤S2、提交项目变更到gitlab版本仓库中；

步骤S3、通过jenkins监听gitlab版本库中分支的变化，当变化满足预设条件时触发流水线构建；

步骤S4、根据jenkins从gitlab版本库中提取的变量名称判断项目类型，进行代码编译，并将代码构建成docker image，上传到harbor仓库进行管理；

步骤S5、构建helm chart并上传；

步骤S6、由jenkins调用helm管理工具将应用部署到uat环境进行验证；

步骤S7、helm管理工具在不同的环境下进行差异化部署，根据helm chart中定义的升级方式进行灰度升级做到应用升级无感知；

步骤S8、由jenkins通过邮件发送上线结果说明给相关人员。

优选地，所述步骤S1具体为：

运维人员和开发人员协商项目所使用的变量，由运维人员登录管理平台增加新变量或将已有变量告知开发人员，以使各个环境中变量命名统一，根据环境不同其对应的值各有不同。

优选地，所述步骤S2具体为：

开发人员提交项目变更到gitlab版本仓库中，如需合并到master分支则需相关技术人员审核后再上传到gitlab版本仓库中。

优选地，所述步骤S3具体为：

拉取gitlab仓库中分支项目代码，jenkins程序会找到和开发人员约定好的说明文件及配置文件，读取说明文件，并将说明文件中的内容存入jenkins的变量列表中；

jenkins程序再读取配置文件，jenkins程序通过正则匹配，将配置文件中涉及到的变量名称依次提取到变量列表中保存。

优选地，所述方法，还包括：

确定构建信息，以供jenkins程序调用；

所述构建信息至少包括：

服务名称、数量、部署类型、方式、环境和开发语言信息。

优选地，所述步骤S5具体为：

根据jenkins中变量信息查看helm仓库中是否有该项目，如果存在进行修改，如果不存在则通过基础模板进行创建；

根据之前的配置文件和说明文件中读到的信息，进行helm chart的相关制作，将配置文件制作成configmap；

读取说明文件中生成的变量进行相关chart信息的修改，通过之前获取到的变量列表，通过api的调用了解相关环境的变量的值，并将变量的名称和值记录到helm chart中values文件的env变量里；

当jenkins程序运行时会将相关的变量和值传到kubernetes的deployment、statefulset，daemonset类型的env变量里，其应用配置文件通过configmap挂载到容器的应用配置文件目录，从而使服务运行起来，并且让helm chart具有独立的运行能力，并将其版本上传到harbor仓库中进行保存管理。

优选地，所述步骤S6具体为：

由jenkins调用helm管理工具将应用部署到uat环境进行验证，验证成功后由jenkins自动根据说明文档及git中的代码更新内容向审批人发起上线请求及相关的情况说明，等待审批人审批。

优选地，所述步骤S7具体为：

审批人登录jenkins进行相关审批后，根据之前说明文件中描述，由jenkins调用api读取相关变量，传递给helm管理工具在不通的环境进行差异化的部署,根据helm chart中定义的升级方式进行灰度升级做到应用升级无感知。

优选地，所述步骤S7还包括：

如果是首次上线或有重大更新变化，会有相关提示引起运维人员的注意以便进行相关的沟通和检查，部署成功后相关上线信息存入数据库，部署失败后应用回滚，并将失败原因发送给相关人员，信息保存到数据库中。

优选地，所述步骤S8具体为：

由jenkins通过邮件发送上线结果说明给相关人员，内容包含jenkins上的http构建链接、项目名称、操作记录、触发时间、运行时间、触发原因、代码修改的描述和说明，如果失败会有失败的原因和描述信息。

本发明采用以上技术方案，至少具备以下有益效果：

本发明提供的技术方案，应用的配置文件使用变量的方式，在运行时读取相应的环境变量即可运行起来，这样可以做到多环节运行的应用的配置文件的统一性。通过提前规范和统一化配置，利用gitlab+jenkins流水线完成自动的构建、打包，生成可以管理镜像和配置文件的helm chart，从而部署到各个环境，大大降低了人为的沟通成本和误操作的可能，提高了效率。

另外，变量的命名一目了然，让开发人员更方便理解自己使用的环境，让运维人员有更好的维护性和检索性。生成的helm chart和docker images存放到harbor仓库中，因为helm里记录了变量、版本、以及配置文件等相关信息，因此可以做到历史版本的可追溯性。本方法并没有使用helm传统的模板替换方式，而且使用变量+模板的方式来解决，目的是解决开发人员在本地环境中的测试问题。由于本地环境可能并非使用helm工具来管理，因此通过调用相关api将变量实时更新到自己的开发环境中，大大的降低了开发人员的工作成本。

通过本发明提供的技术方案，可快速实现应用服务的部署工作，解决了微服务的环境及配置的差异问题和应用版本留存追溯的问题，通过版本的控制和审批的机制，为开发，测试，审批，上线，回退都带来了极大便利，降低了沟通成本，提高了工作效率。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明一实施例提供的一种基于Jenkins实现DevOps的微服务部署方法的流程图；

图2为本发明一实施例提供的一种基于Jenkins实现DevOps的微服务部署方法的逻辑流程图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将对本发明的技术方案进行详细的描述。显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所得到的所有其它实施方式，都属于本发明所保护的范围。

下面通过附图和实施例，对本发明的技术方案做进一步的详细描述。

参见图1和图2，本发明一实施例提供的一种基于Jenkins实现DevOps的微服务部署方法，包括：

步骤S1、确定待开发的项目所需变量；

步骤S2、提交项目变更到gitlab版本仓库中；

步骤S3、通过jenkins监听gitlab版本库中分支的变化，当变化满足预设条件时触发流水线构建；

步骤S4、根据jenkins从gitlab版本库中提取的变量名称判断项目类型，进行代码编译，并将代码构建成docker image，上传到harbor仓库进行管理；

步骤S5、构建helm chart并上传；

步骤S6、由jenkins调用helm管理工具将应用部署到uat环境进行验证；

步骤S7、helm管理工具在不同的环境下进行差异化部署，根据helm chart中定义的升级方式进行灰度升级做到应用升级无感知；

步骤S8、由jenkins通过邮件发送上线结果说明给相关人员。

可以理解的是，本发明提供的技术方案，应用的配置文件使用变量的方式，在运行时读取相应的环境变量即可运行起来，这样可以做到多环节运行的应用的配置文件的统一性。通过提前规范和统一化配置，利用gitlab+jenkins流水线完成自动的构建、打包，生成可以管理镜像和配置文件的helm chart，从而部署到各个环境，大大降低了人为的沟通成本和误操作的可能，提高了效率。

另外，变量的命名一目了然，让开发人员更方便理解自己使用的环境，让运维人员有更好的维护性和检索性。生成的helm chart和docker images存放到harbor仓库中，因为helm里记录了变量、版本、以及配置文件等相关信息，因此可以做到历史版本的可追溯性。本方法并没有使用helm传统的模板替换方式，而且使用变量+模板的方式来解决，目的是解决开发人员在本地环境中的测试问题。由于本地环境可能并非使用helm工具来管理，因此通过调用相关api将变量实时更新到自己的开发环境中，大大的降低了开发人员的工作成本。

通过本发明提供的技术方案，可快速实现应用服务的部署工作，解决了微服务的环境及配置的差异问题和应用版本留存追溯的问题，通过版本的控制和审批的机制，为开发，测试，审批，上线，回退都带来了极大便利，降低了沟通成本，提高了工作效率。

优选地，所述步骤S1具体为：

运维人员和开发人员协商项目所使用的变量，由运维人员登录管理平台增加新变量或将已有变量告知开发人员，以使各个环境中变量命名统一，根据环境不同其对应的值各有不同。

优选地，所述步骤S2具体为：

开发人员提交项目变更到gitlab版本仓库中，如需合并到master分支则需相关技术人员审核后再上传到gitlab版本仓库中。

优选地，所述步骤S3具体为：

拉取gitlab仓库中分支项目代码，jenkins程序会找到和开发人员约定好的说明文件及配置文件，读取说明文件，并将说明文件中的内容存入jenkins的变量列表中；

jenkins程序再读取配置文件，jenkins程序通过正则匹配，将配置文件中涉及到的变量名称依次提取到变量列表中保存。

优选地，所述方法，还包括：

确定构建信息，以供jenkins程序调用；

所述构建信息至少包括：

服务名称、数量、部署类型、方式、环境和开发语言信息。

可以理解的是，通过jenkins监听到gitlab版本库中分支的变化，当条件满足时触发流水线构建。

拉取gitlab仓库中分支项目代码，jenkins程序会找到和开发人员约定好的说明文件及配置文件。读取说明文件，将说明文件中的内容存入jenkins变量中，确定构建的服务名称、数量、部署类型、方式、环境、和开发语言等信息。再读取配置文件，由于相关规范约定不同环境间差异化的变量有特殊的写法，例如${DB_MYSQL_PLATFORM}变量为三段式描述：类型、服务、应用场景，看上去简单易懂，提高了管理便捷性。之后jenkins通过正则匹配，将配置文件中涉及到变量的名称依次提取到变量列表中保存。

优选地，所述步骤S5具体为：

根据jenkins中变量信息查看helm仓库中是否有该项目，如果存在进行修改，如果不存在则通过基础模板进行创建；

根据之前的配置文件和说明文件中读到的信息，进行helm chart的相关制作，将配置文件制作成configmap；

读取说明文件中生成的变量进行相关chart信息的修改，通过之前获取到的变量列表，通过api的调用了解相关环境的变量的值，并将变量的名称和值记录到helm chart中values文件的env变量里；

当jenkins程序运行时会将相关的变量和值传到kubernetes的deployment、statefulset，daemonset类型的env变量里，其应用配置文件通过configmap挂载到容器的应用配置文件目录，从而使服务运行起来，并且让helm chart具有独立的运行能力，并将其版本上传到harbor仓库中进行保存管理。

可以理解的是，由于配置文件里引用了变量，而变量已经通过env注入的方式加载到了docker容器中，从而使服务运行起来，并且让helm chart具有独立的运行能力，并将其版本上传到harbor仓库中进行保存管理，做到版本历史可追溯，配置文件和应用镜像统一，可独立运行和查看。

优选地，所述步骤S6具体为：

由jenkins调用helm管理工具将应用部署到uat环境进行验证，验证成功后由jenkins自动根据说明文档及git中的代码更新内容向审批人发起上线请求及相关的情况说明，等待审批人审批。

优选地，所述步骤S7具体为：

审批人登录jenkins进行相关审批后，根据之前说明文件中描述，由jenkins调用api读取相关变量，传递给helm管理工具在不通的环境进行差异化的部署,根据helm chart中定义的升级方式进行灰度升级做到应用升级无感知。

优选地，所述步骤S7还包括：

如果是首次上线或有重大更新变化，会有相关提示引起运维人员的注意以便进行相关的沟通和检查，部署成功后相关上线信息存入数据库，部署失败后应用回滚，并将失败原因发送给相关人员，信息保存到数据库中。

优选地，所述步骤S8具体为：

由jenkins通过邮件发送上线结果说明给相关人员，内容包含jenkins上的http构建链接、项目名称、操作记录、触发时间、运行时间、触发原因、代码修改的描述和说明，如果失败会有失败的原因和描述信息。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性。术语“多个”指两个或两个以上，除非另有明确的限定。

Claims (10)

1.一种基于Jenkins实现DevOps的微服务部署方法，其特征在于，包括：

步骤S1、确定待开发的项目所需变量；

步骤S2、提交项目变更到gitlab版本仓库中；

步骤S3、通过jenkins监听gitlab版本库中分支的变化，当变化满足预设条件时触发流水线构建；

步骤S4、根据jenkins从gitlab版本库中提取的变量名称判断项目类型，进行代码编译，并将代码构建成docker image，上传到harbor仓库进行管理；

步骤S5、构建helm chart并上传；

步骤S6、由jenkins调用helm管理工具将应用部署到uat环境进行验证；

步骤S7、helm管理工具在不同的环境下进行差异化部署，根据helm chart中定义的升级方式进行灰度升级做到应用升级无感知；

步骤S8、由jenkins通过邮件发送上线结果说明给相关人员。

2.根据权利要求1所述的方法，其特征在于，所述步骤S1具体为：

运维人员和开发人员协商项目所使用的变量，由运维人员登录管理平台增加新变量或将已有变量告知开发人员，以使各个环境中变量命名统一，根据环境不同其对应的值各有不同。

3.根据权利要求2所述的方法，其特征在于，所述步骤S2具体为：

开发人员提交项目变更到gitlab版本仓库中，如需合并到master分支则需相关技术人员审核后再上传到gitlab版本仓库中。

4.根据权利要求3所述的方法，其特征在于，所述步骤S3具体为：

拉取gitlab仓库中分支项目代码，jenkins程序会找到和开发人员约定好的说明文件及配置文件，读取说明文件，并将说明文件中的内容存入jenkins的变量列表中；

jenkins程序再读取配置文件，jenkins程序通过正则匹配，将配置文件中涉及到的变量名称依次提取到变量列表中保存。

5.根据权利要求4所述的方法，其特征在于，还包括：

确定构建信息，以供jenkins程序调用；

所述构建信息至少包括：

服务名称、数量、部署类型、方式、环境和开发语言信息。

6.根据权利要求4所述的方法，其特征在于，所述步骤S5具体为：

根据jenkins中变量信息查看helm仓库中是否有该项目，如果存在进行修改，如果不存在则通过基础模板进行创建；

根据之前的配置文件和说明文件中读到的信息，进行helm chart的相关制作，将配置文件制作成configmap；

读取说明文件中生成的变量进行相关chart信息的修改，通过之前获取到的变量列表，通过api的调用了解相关环境的变量的值，并将变量的名称和值记录到helm chart中values文件的env变量里；

当jenkins程序运行时会将相关的变量和值传到kubernetes的deployment、statefulset，daemonset类型的env变量里，其应用配置文件通过configmap挂载到容器的应用配置文件目录，从而使服务运行起来，并且让helm chart具有独立的运行能力，并将其版本上传到harbor仓库中进行保存管理。

7.根据权利要求6所述的方法，其特征在于，所述步骤S6具体为：

由jenkins调用helm管理工具将应用部署到uat环境进行验证，验证成功后由jenkins自动根据说明文档及git中的代码更新内容向审批人发起上线请求及相关的情况说明，等待审批人审批。

8.根据权利要求7所述的方法，其特征在于，所述步骤S7具体为：

审批人登录jenkins进行相关审批后，根据之前说明文件中描述，由jenkins调用api读取相关变量，传递给helm管理工具在不通的环境进行差异化的部署,根据helm chart中定义的升级方式进行灰度升级做到应用升级无感知。

9.根据权利要求8所述的方法，其特征在于，所述步骤S7还包括：

如果是首次上线或有重大更新变化，会有相关提示引起运维人员的注意以便进行相关的沟通和检查，部署成功后相关上线信息存入数据库，部署失败后应用回滚，并将失败原因发送给相关人员，信息保存到数据库中。

10.根据权利要求8所述的方法，其特征在于，所述步骤S8具体为：

由jenkins通过邮件发送上线结果说明给相关人员，内容包含jenkins上的http构建链接、项目名称、操作记录、触发时间、运行时间、触发原因、代码修改的描述和说明，如果失败会有失败的原因和描述信息。

Images