CN109032645A - 基于Kubernetes的持续集成与部署的方法和系统 - Google Patents

Abstract

本发明提供一种基于Kubernetes的持续集成与部署的方法和系统，所述方法包括：S1：响应于接收到任意一个功能模块，对其所对应的源代码文件进行验证，如果源代码文件通过验证，生成一测试任务；S2：创建一测试节点，将所述测试任务分配至该测试节点以对所述源代码文件进行功能测试；S3：响应于所述测试任务对应的源代码文件通过功能测试，针对该源代码文件所对应的功能模块生成至少一个容器镜像，根据预定的部署策略以将该功能模块推送至Kubernetes平台进行服务部署。本发明能够自动对功能模块的源代码文件进行测试，测试通过后生成容器镜像，并推送到Kubernetes平台之上按照预定的升级策略进行服务部署。

Description

基于Kubernetes的持续集成与部署的方法和系统

技术领域

本发明涉及软件开发领域，属于一种基于Kubernetes的持续集成与部署的方法和系统。

背景技术

Kubernetes是一种容器编排引擎，是Google多年大规模容器管理技术的开源版本，可以帮助用户轻松管理集群，自动分发和调度容器应用程序。

持续集成与持续部署(CICD)是当前比较流行的软件开发流程。CICD与DevOps理念相结合，能够让软件在短周期内产出，确保软件随时可以被可靠地发布。

目前一套完整的CICD系统包含众多的服务，如果每个服务都手工进行安装和配置，则部署起来较复杂，需要时间较长，同时，部署至平台的服务程序受节点状态影响较大，容易发生故障。

发明内容

本发明的目的在于提供一种基于Kubernetes的持续集成与部署的方法和系统，能够对需要部署的功能模块所对应的源代码文件进行测试，如果该功能模块的源代码文件通过测试，生成至少一个与之相对应的容器镜像，并推送到Kubernetes平台之上按照预定的升级策略进行服务部署，以上过程全部为自动执行，极大地提高了软件开发以及软件部署的速度和效率。

为达到上述目的，本发明提供如下技术方案：

一种基于Kubernetes的持续集成与部署方法，所述方法包括：

S1：响应于接收到任意一个功能模块，对其所对应的源代码文件进行验证，如果源代码文件通过验证，生成一测试任务；

S2：创建一测试节点，将所述测试任务分配至该测试节点以对所述源代码文件进行功能测试；

S3：响应于所述测试任务对应的源代码文件通过功能测试，针对该源代码文件所对应的功能模块生成至少一个容器镜像，根据预定的部署策略以将该功能模块推送至Kubernetes平台进行服务部署。

进一步的，所述方法还包括：

响应于任意一个测试任务完成，删除与该测试任务对应的测试节点。

进一步的，所述预定的部署策略是指，

将通过测试的功能模块冗余地部署在Kubernetes平台上。

进一步的，所述预定的部署策略是指，

将通过测试的功能服务部署在Kubernetes平台的至少一个服务节点上；

所述至少一个服务节点属性相同。

进一步的，所述预定的部署策略是指，

采用helm引擎以进行功能模块的部署。

进一步的，所述方法还包括：

提供一用以对验证未通过的功能模块的源代码文件进行记录和追踪的问题跟踪模块，S1中，如果源代码文件未通过验证，将该源代码文件发送至该问题跟踪模块。

进一步的，所述方法还包括：

响应于接收到的任意一个功能模块被推送至Kubernetes平台、和/或被发送至问题跟踪模块，生成一开发文档以记录该功能模块的测试过程。

本发明还提及一种基于前述方法的基于Kubernetes的持续集成与部署的系统，所述系统包括代码仓库模块、代码审阅模块、任务引擎模块、功能测试模块、服务部署模块；

所述代码仓库模块用以接收功能模块、并且对接收的功能模块的源代码文件进行管理；

所述代码审阅模块用以对代码仓库中的源代码文件进行验证，如果源代码文件通过验证，生成一测试任务并且发送至任务引擎模块；

所述任务引擎模块用以创建测试节点，接收代码审阅模块发送的测试任务并且将测试任务分配至该测试节点；

所述功能测试模块用以对测试节点中的源代码文件进行功能测试；

所述服务部署模块响应于测试任务对应的源代码文件通过功能测试，针对该源代码文件所对应的功能模块生成至少一个容器镜像，根据预定的部署策略以将该功能模块推送至Kubernetes平台进行服务部署。

本发明的有益效果在于：

(1)采用helm引擎以实现功能模块的服务程序的快速部署。

(2)采用Kubernetes提供的服务冗余机制，实现功能模块的冗余部署，提高服务程序的稳定性。

(3)根据测试任务的数量以生成对应数量的测试节点，测试完成后删除对应的测试节点，能够同时进行多个功能模块的功能测试，实现功能测试的自动扩缩容。

(4)实现服务程序的自动测试和自动部署功能。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，并可依照说明书的内容予以实施，以下以本发明的较佳实施例并配合附图详细说明如后。

附图说明

图1为本发明的基于Kubernetes的持续集成与部署的方法流程图。

图2为本发明的基于Kubernetes的持续集成与部署的系统结构图。

图3为本发明的服务程序的冗余部署的示意图。

具体实施方式

下面结合附图和实施例，对本发明的具体实施方式作进一步详细描述。以下实施例用于说明本发明，但不用来限制本发明的范围。

持续部署是CICD的核心功能之一，并且Kubernetes也支持服务的升级回滚等持续部署操作。

本发明结合了这两个特性，针对当前CICD系统运行在Kubernetes之上的特点，提出一个基于Kubernetes的持续集成与部署的系统。利用此系统，当接收到一功能模块时，对该功能模块对应的源代码文件进行测试，如果该功能模块的源代码文件通过测试，生成至少一个与之相对应的容器镜像，并推送到Kubernetes平台之上按照预定的升级策略进行服务部署，以上过程全部为自动执行，极大地提高了软件开发以及软件部署的速度和效率。

结合图1、图2，本发明提出一种基于Kubernetes的持续集成与部署方法，所述方法包括：

S1：响应于接收到任意一个功能模块，对其所对应的源代码文件进行验证，如果源代码文件通过验证，生成一测试任务。

S2：创建一测试节点，将所述测试任务分配至该测试节点以对所述源代码文件进行功能测试。

S3：响应于所述测试任务对应的源代码文件通过功能测试，针对该源代码文件所对应的功能模块生成至少一个容器镜像，根据预定的部署策略以将该功能模块推送至Kubernetes平台进行服务部署。

基于前述方法，本发明还提及一种基于Kubernetes的持续集成与部署的系统，所述系统包括代码仓库模块、代码审阅模块、任务引擎模块、功能测试模块、服务部署模块。

所述代码仓库模块用以接收功能模块、并且对接收的功能模块的源代码文件进行管理。

所述代码审阅模块用以对代码仓库中的源代码文件进行验证，如果源代码文件通过验证，生成一测试任务并且发送至任务引擎模块。

所述任务引擎模块用以创建测试节点，接收代码审阅模块发送的测试任务并且将测试任务分配至该测试节点。

所述功能测试模块用以对测试节点中的源代码文件进行功能测试。

所述服务部署模块响应于测试任务对应的源代码文件通过功能测试，针对该源代码文件所对应的功能模块生成至少一个容器镜像，根据预定的部署策略以将该功能模块推送至Kubernetes平台进行服务部署。

在一些例子中，所述预定的部署策略是指，将通过测试的功能模块冗余地部署在Kubernetes平台上。

此处的冗余部署具有多种方式，本发明提出其中一种冗余部署方式，即将通过测试的功能服务部署在Kubernetes平台的至少一个服务节点上，所述至少一个服务节点属性相同。

事实上，Kubernetes的Deployment模块(部署模块)能够提供服务冗余机制，通过该机制，可以把CICD系统中的服务冗余地部署在平台之上。

结合图3，用户访问服务时，流量可以平均地分布在冗余地多个服务上。以代码仓库为例，Git服务1和Git服务2本身是无状态的，可以分布在2个节点上。他们共享后端的数据库和文件存储。当Git服务1所在的节点故障时，Git服务2仍能提供服务，达到了服务高可用的目的，提高了服务程序的可靠性。

进一步的，在另一些例子中，所述预定的部署策略是指，采用helm引擎以进行功能模块的部署。

一套完整的CICD系统包含众多的服务，如果每个服务都手工进行安装和配置，则部署起来较复杂，需要时间较长。Kubernetes的核心运行时是Docker，一种镜像化的容器方案，相比其它容器方案来说，能做到快速部署和快速启动。Kubernetes提供应用模板(helm)的功能，可以根据所需要的服务预先定制应用模板文件。

helm作为Kubernetes一个包管理引擎，基于chart的概念，有效的对Kubernetes上应用的部署进行了优化。Chart通过模板引擎，下方对接Kubernetes中services模型，上端打造包管理仓库。最后的使得Kubernetes中，对应用的部署能够达到像使用apt-get和yum一样简单易用。

例如：

使用此应用模板文件，可以做到CICD系统一键部署到Kubernetes平台之上，达到了快速部署的目的。

所述方法还包括：

响应于任意一个测试任务完成，删除与该测试任务对应的测试节点。

当测试任务发布到了任务引擎之后，任务引擎可以选择测试节点来执行测试任务。此处可以利用容器技术的优势，通过Kubernetes快速启动一个Pod来执行测试任务，等待测试任务执行完成后，快速销毁这个Pod。通过这种方式，任务引擎可以同时批量创建多个Pod进行测试，并且，由于Kubernetes中集群内部的每一个pod被指定了唯一的IP地址，用户程序可以通过相应的端口号无冲突地连接各个pod，达到了测试自动扩缩容的目的。

用户可以通过Kubernetes API手动管理pod，或者把管理工作交给一个管理器。

进一步的实施例中，所述方法还包括：

提供一用以对验证未通过的功能模块的源代码文件进行记录和追踪的问题跟踪模块，S1中，如果源代码文件未通过验证，将该源代码文件发送至该问题跟踪模块。

在另一些实施例中，为了对前述软件开发过程和软件部署功能做记录以便于管理，所述方法还包括：

响应于接收到的任意一个功能模块被推送至Kubernetes平台、和/或被发送至问题跟踪模块，生成一开发文档以记录该功能模块的测试过程。

以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本发明的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。因此，本发明专利的保护范围应以所附权利要求为准。

Claims (8)

1.一种基于Kubernetes的持续集成与部署方法，其特征在于，所述方法包括：

S1：响应于接收到任意一个功能模块，对其所对应的源代码文件进行验证，如果源代码文件通过验证，生成一测试任务；

S2：创建一测试节点，将所述测试任务分配至该测试节点以对所述源代码文件进行功能测试；

S3：响应于所述测试任务对应的源代码文件通过功能测试，针对该源代码文件所对应的功能模块生成至少一个容器镜像，根据预定的部署策略以将该功能模块推送至Kubernetes平台进行服务部署。

2.根据权利要求1所述的基于Kubernetes的持续集成与部署方法，其特征在于，所述方法还包括：

响应于任意一个测试任务完成，删除与该测试任务对应的测试节点。

3.根据权利要求1所述的基于Kubernetes的持续集成与部署方法，其特征在于，所述预定的部署策略是指，

将通过测试的功能模块冗余地部署在Kubernetes平台上。

4.根据权利要求3所述的基于Kubernetes的持续集成与部署方法，其特征在于，所述预定的部署策略是指，

将通过测试的功能服务部署在Kubernetes平台的至少一个服务节点上；

所述至少一个服务节点属性相同。

5.根据权利要求3或者4所述的基于Kubernetes的持续集成与部署方法，其特征在于，所述预定的部署策略是指，

采用helm引擎以进行功能模块的部署。

6.根据权利要求1所述的基于Kubernetes的持续集成与部署方法，其特征在于，所述方法还包括：

提供一用以对验证未通过的功能模块的源代码文件进行记录和追踪的问题跟踪模块，S1中，如果源代码文件未通过验证，将该源代码文件发送至该问题跟踪模块。

7.根据权利要求6所述的基于Kubernetes的持续集成与部署方法，其特征在于，所述方法还包括：

响应于接收到的任意一个功能模块被推送至Kubernetes平台、和/或被发送至问题跟踪模块，生成一开发文档以记录该功能模块的测试过程。

8.一种基于Kubernetes的持续集成与部署的系统，其特征在于，所述系统包括代码仓库模块、代码审阅模块、任务引擎模块、功能测试模块、服务部署模块；

所述代码仓库模块用以接收功能模块、并且对接收的功能模块的源代码文件进行管理；

所述代码审阅模块用以对代码仓库中的源代码文件进行验证，如果源代码文件通过验证，生成一测试任务并且发送至任务引擎模块；

所述任务引擎模块用以创建测试节点，接收代码审阅模块发送的测试任务并且将测试任务分配至该测试节点；

所述功能测试模块用以对测试节点中的源代码文件进行功能测试；

所述服务部署模块响应于测试任务对应的源代码文件通过功能测试，针对该源代码文件所对应的功能模块生成至少一个容器镜像，根据预定的部署策略以将该功能模块推送至Kubernetes平台进行服务部署。