CN106407101A - 基于lxc的持续集成方法及装置 - Google Patents

Abstract

本发明提供了一种基于LXC的持续集成方法及装置，其中该方法包括：LXC服务器中的一个LXC接收控制台发起的一个持续集成任务以及持续集成任务的配置信息；LXC依据配置信息从源代码中克隆一份与持续集成任务对应的代码以及从镜像服务器中获取与持续集成任务对应的镜像；LXC依据代码和镜像生成用于运行持续集成任务的运行环境；LXC在运行环境中对持续集成任务的测试，并发送测试报告。通过本发明，解决了相关技术中Hudson的任务都是在一个或者多个任务代理中执行的，无法实现针对用户进行资源隔离的问题，达到了操作系统层面的安全性更高的效果。

Description

基于LXC的持续集成方法及装置

技术领域

本发明涉及通信领域，具体而言，涉及一种基于LXC的持续集成方法及装置。

背景技术

持续集成是一种软件开发实践，即团队开发成员经常集成它们的工作，通过每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建(包括编译，发布，自动化测试)来验证，从而尽早地发现集成错误，

极限编程中一项建议实践便是持续集成，持续集成是指在开发阶段，对项目进行持续性自动化编译、测试，以达到控制代码质量的手段。

持续集成提供了及时发现问题、追踪问题、修复问题的机制，他替代了传统的在所有代码编写完毕后才提交质量保证(Quality Assurance简称为QA)部门进行测试的方法。

持续集成对单元测试较为依赖，测试覆盖率越高，单元测试越准确，越能体现持续集成的效果。持续集成主要在以下方面提供好处；

1、持续自动化测试(持续集成可通过时间间隔触发，或其他方式触发)；

2、跟踪工程健康状况；

3、强制性单元测试用例，验收测试用例等；

4、静态代码检测，生成测试报告；

Hudson是一款轻量级、易扩展、易配置的持续集成平台，该集成平台maven2有良好的支持，并且扩展插件丰富，包括findbug,PMD静态分析插件、emma单元测试覆盖率插件、junit测试报告插件等等

图1是相关技术中执行持续集成任务的模块示意图，如图1所示，通过一个或者多个中控，发布构建任务在任务代理上执行。对于相关技术中的方案至少存在以下问题：

由于Hudson的任务都是在一个或者多个任务代理中执行的，无法实现针对用户进行资源隔离，由于目标机器环境是动态的，依赖的基础环境是不同的，无法从相同的代码中构建出一个依赖基础环境的应用，无法实现不同的用户构建出不同的包。每次都要重复修改相同的配置项才能让应用跑起来，或者需要安装应用的上下文依赖环境，无法实现一次安装配置，多个地方使用。

针对相关技术中Hudson的任务都是在一个或者多个任务代理中执行的，无法实现针对用户进行资源隔离的问题，目前尚未提出有效的解决方案。

发明内容

本发明提供了一种基于LXC的持续集成方法及装置，以至少解决相关技术中Hudson的任务都是在一个或者多个任务代理中执行的，无法实现针对用户进行资源隔离的问题。

根据本发明的一个方面，提供了一种基于LXC的持续集成方法，包括：LXC服务器中的一个LXC接收控制台发起的一个持续集成任务以及所述持续集成任务的配置信息；所述LXC依据所述配置信息从源代码中克隆一份与所述持续集成任务对应的代码以及从镜像服务器中获取与所述持续集成任务对应的镜像；所述LXC依据所述代码和所述镜像生成用于运行所述持续集成任务的运行环境；所述LXC在所述运行环境中对所述持续集成任务的测试，并发送测试报告。

进一步地，所述LXC依据所述代码和所述镜像生成用于运行所述持续集成任务的运行环境包括：所述LXC依据从所述配置信息中获取编译工具和打包工具；所述LXC通过所述编译工具对所述代码进行编译，并通过所述打包工具对编译完成的代码进行打包；所述LXC将编译并打包后的代码与所述镜像进行整合生成用于运行所述持续集成任务的运行环境。

进一步地，在所述LXC上报测试报告之后，所述方法还包括：所述LXC得到对所述持续集成任务的测试成功的多个应用包，并将所述多个应用包上传到存储服务器。

进一步地，在将所述多个应用包上传到存储服务器之后，所述方法还包括：所述LXC向所述存储服务器发送用于获取应用包的多个请求，其中，一个所述请求用于获取所述存储服务器中与该请求对应的一个应用包；所述LXC将依据多个所述请求获取到的多个应用包分别部署到与应用包对应的应用服务器上。

进一步地，在所述LXC将所述多个应用包上传到存储服务器之后，所述方法还包括：所述LXC接收所述LXC服务器用于销毁所述LXC和回收资源的请求。

根据本发明的另一个方面，提供了一种基于LXC的持续集成装置，应用于LXC服务器中的一个LXC侧，包括：第一接收模块，用于接收控制台发起的一个持续集成任务以及所述持续集成任务的配置信息；克隆模块，用于依据所述配置信息从源代码中克隆一份与所述持续集成任务对应的代码以及从镜像服务器中获取与所述持续集成任务对应的镜像；生成模块，用于依据所述代码和所述镜像生成用于运行所述持续集成任务的运行环境；运行模块，用于在所述运行环境中对所述持续集成任务的测试，并发送测试报告。

进一步地，所述生成模块包括：获取单元，用于依据从所述配置信息中获取编译工具和打包工具；处理单元，用于通过所述编译工具对所述代码进行编译，并通过所述打包工具对编译完成的代码进行打包；生成单元，用于将编译并打包后的代码与所述镜像进行整合生成用于运行所述持续集成任务的运行环境。

进一步地，在上报测试报告之后，所述装置还包括：处理模块，用于所述LXC得到对所述持续集成任务的测试成功的多个应用包，并将所述多个应用包上传到存储服务器。

进一步地，在将所述多个应用包上传到存储服务器之后，所述装置还包括：发送模块，用于向所述存储服务器发送用于获取应用包的多个请求，其中，一个所述请求用于获取所述存储服务器中与该请求对应的一个应用包；部署模块，用于将依据多个所述请求获取到的多个应用包分别部署到与应用包对应的应用服务器上。

进一步地，在将所述多个应用包上传到存储服务器之后，所述装置还包括：第二接收模块，用于接收所述LXC服务器用于销毁所述LXC和回收资源的请求。

在本发明中，采用LXC接收控制台发起的一个持续集成任务以及该持续集成任务的配置信息，并依据该配置信息从源代码中克隆一份与持续集成任务对应的代码以及从镜像服务器中获取与持续集成任务对应的镜像，该LXC通过该代码和镜像生成用于运行持续集成任务的运行环境，并在该运行环境中对持续集成任务进行测试，并上报测试报告；可见，在发明中通过LXC使得持续集成任务有自身相对应的配置信息，执行持续集成任务时配置信息不回相互影响，解决了相关技术中Hudson的任务都是在一个或者多个任务代理中执行的，无法实现针对用户进行资源隔离的问题，达到了操作系统层面的安全性更高的效果。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是相关技术中执行持续集成任务的模块示意图；

图2是根据本发明实施例的基于LXC的持续集成方法的流程图；

图3是根据本发明实施例的基于LXC的持续集成装置结构框图；

图4是根据本发明实施例的基于LXC的持续集成装置可选结构框图一；

图5是根据本发明实施例的基于LXC的持续集成装置可选结构框图二；

图6是根据本发明可选实施例的基于容器持续集成的系统结构框图；

图7是根据本发明可选实施例的持续构建的交互示意图；

图8是根据本发明可选实施例的版本发布的交互示意图。

具体实施方式

下文中将参考附图并结合实施例来详细说明本发明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。

在本实施例中提供了一种基于LXC的持续集成方法，图2是根据本发明实施例的基于LXC的持续集成方法的流程图，如图2所示，该流程包括如下步骤：

步骤S202：LXC服务器中的一个LXC接收控制台发起的一个持续集成任务以及该持续集成任务的配置信息；

步骤S204：LXC依据该配置信息从源代码中克隆一份与持续集成任务对应的代码以及从镜像服务器中获取与持续集成任务对应的镜像；

步骤S206：LXC依据代码和镜像生成用于运行持续集成任务的运行环境；

步骤S208：LXC在该运行环境中对持续集成任务的测试，并发送测试报告。

通过本实施例中的步骤S202至步骤S208，采用LXC接收控制台发起的一个持续集成任务以及该持续集成任务的配置信息，并依据该配置信息从源代码中克隆一份与持续集成任务对应的代码以及从镜像服务器中获取与持续集成任务对应的镜像，该LXC通过该代码和镜像生成用于运行持续集成任务的运行环境，并在该运行环境中对持续集成任务进行测试，并上报测试报告；可见，在本实施例中通过LXC使得持续集成任务有自身相对应的配置信息，执行持续集成任务时配置信息不回相互影响，解决了相关技术中Hudson的任务都是在一个或者多个任务代理中执行的，无法实现针对用户进行资源隔离的问题，达到了操作系统层面的安全性更高的效果。

需要说明的是，本实施例中的LXC为Linux Container，即Linux容器，也就是linux的上虚拟机，是一种内核虚拟化技术，可以提供轻量级的虚拟化。

对于本实施例步骤S206中涉及到的LXC依据代码和镜像生成用于运行持续集成任务的运行环境的方式，在本实施例的一个可选实施方式中可以是包括：

步骤S11：LXC依据从配置信息中获取编译工具和打包工具；

步骤S12：LXC通过编译工具对代码进行编译，并通过打包工具对编译完成的代码进行打包；

步骤S13：LXC将编译并打包后的代码与镜像进行整合生成用于运行持续集成任务的运行环境。

对于上述步骤S11和步骤S13中的方式，在本实施例的一个应用场景中可以是：对得到的代码进行静态检查，对检查的代码生成检查报告；通过从配置信息得到编译工具，对代码进行编译，如果存在编译错误，那么生成错误信息，并反馈给配置用户；通过获取配置信息的打包工具，对编译完成的代码进行打包；把编译生成的包，和镜像进行整合，再合并一个整体运行环境。

此外，在本实施例步骤S208中的LXC上报测试报告之后，本实施例涉及到的方法还可以包括：LXC得到对持续集成任务的测试成功的多个应用包，并将多个应用包上传到存储服务器。

而在将多个应用包上传到存储服务器之后，本实施例的方法可以还包括LXC并行处理应用包的方法，该方法的步骤包括：

步骤S21：LXC向存储服务器发送用于获取应用包的多个请求，其中，一个请求用于获取存储服务器中与该请求对应的一个应用包；

步骤S22：LXC将依据多个请求获取到的多个应用包分别部署到与应用包对应的应用服务器上。

通过上述步骤S21和步骤S22，可知LXC可以获取到的多个应用包分别部署到应用服务器上，也就是说可以并行处理多个应用包，在本实施例的一个应用场景中以两个应用为例进行说明：从存储服务器获取一个应用包1，并将该应用包1部署在app server 1上；从容器发起一个获取一个应用包2的请求，并从存储服务器获取一个应用包2，并将该应用包2部署在app server 2上；当然在该应用场景中仅仅只是用2个应用包进行了举例，在有大于2个应用包的时候，该LXC也是依据上述方式来并行处理多个应用包。

而在LXC将多个应用包上传到存储服务器之后，本实施例的方法还可以包括：LXC接收LXC服务器用于销毁LXC和回收资源的请求。也就是说，销毁LXC，回收LXC资源。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

在本实施例中还提供了一种基于LXC的持续集成装置，该装置用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述。如以下所使用的，术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

图3是根据本发明实施例的基于LXC的持续集成装置结构框图，该装置应用于LXC服务器中的一个LXC侧，需要说明的是，该一个LXC并不特指某一个LXC，而是泛指LXC服务器任一LXC，如图3所示，该装置包括：第一接收模块32，用于接收控制台发起的一个持续集成任务以及持续集成任务的配置信息；克隆模块34，与第一接收模块32耦合连接，用于依据配置信息从源代码中克隆一份与持续集成任务对应的代码以及从镜像服务器中获取与持续集成任务对应的镜像；生成模块36，与克隆模块34耦合连接，用于依据代码和镜像生成用于运行持续集成任务的运行环境；运行模块38，与生成模块36耦合连接，用于依据运行环境对持续集成任务的测试，并发送测试报告。

图4是根据本发明实施例的基于LXC的持续集成装置可选结构框图一，如图4所示，生成模块36包括：获取单元42，用于依据从配置信息中获取编译工具和打包工具；处理单元44，与获取单元42耦合连接，用于通过编译工具对代码进行编译，并通过打包工具对编译完成的代码进行打包；生成单元46，与处理单元44耦合连接，用于将编译并打包后的代码与镜像进行整合生成用于运行持续集成任务的运行环境。

图5是根据本发明实施例的基于LXC的持续集成装置可选结构框图二，如图5所示，在上报测试报告之后，本实施例的装置还可以包括：处理模块52，与运行模块38耦合连接，用于LXC得到对持续集成任务的测试成功的多个应用包，并将多个应用包上传到存储服务器；发送模块54，与处理模块52耦合连接，用于向存储服务器发送用于获取应用包的多个请求，其中，一个请求用于获取存储服务器中与该请求对应的一个应用包；部署模块56，与发送模块54耦合连接，用于将依据多个请求获取到的多个应用包分别部署到与应用包对应的应用服务器上。

可选地，在将多个应用包上传到存储服务器之后，本实施例的装置还可以包括：第二接收模块，与部署模块56耦合连接，用于接收LXC服务器用于销毁LXC和回收资源的请求。

下面将结合本发明的可选实施例对本发明进行举例说明；

本可选实施例提供了一种基于容器持续集成的系统，该系统用于实现基于容器持续集成的方法，图6是根据本发明可选实施例的基于容器持续集成的系统结构框图，如图6所示，该系统包括：控制台、容器、源代码模块、镜像模块、存储服模块、应用服务器，其中，本可选实施例的方法可以通过如下方式来实现：

首先，控制台配置一个任务，任务可以指定源的来源，如镜像来源、配置信息等等；

其次，控制台接收来用户的操作指令，并读取任务配置选项，发起一个持续集成任务，任务队列接收来自控制分包的任务，并从队列的底部获取一个持续集成任务，在容器服务器启动一个容器；该容器获取来自控制台的配置信息，其中，该容器是基于LXC的一种低层技术。基于LXC的技术获取操作系统内核cgroup操作权限，这种操作不依赖任何外部的库，从而达到用户之间的隔离，通过这种操作系统上半虚拟化技术，可以做到用户之间的配置，互相不会影响；

然后，读取来自控制台的配置信息，从源代码服务器拉取指定代码。读取环境配置信息，从镜像服务器克隆一个镜像其中，该镜像包括但不限于：环境变量、用户变量，以及依赖环境，例如redhat+jdk+tomcat+mysql或者Ubuntu+Django等等；

在次，通过获取的源代码克隆，进行静态校验，编译，打包，并和上下文镜像进行整合；在整合得到的运行环境中执行自动化测试用例，输出测试报告，通过邮件发送接口，发送测试报告到控制台配置接收人邮箱。

最后，当包验证完成之后，上传发布包到存储服务器。

另外，从控制台发起一个发布任务，指定该发布包部署到生产环境的地址，从存储服务器获取发布包，依次部署到生产环境中。

通过上述实施例可以看到，通过基于LXC的技术，能够解决相关技术中，用户的资源隔离，并可以带来操作系统层面的安全性；以及可以让容器并行处理，提高单机的业务处理容量。

下面结合附图对本可选实施例进行详细的描述；

图7是根据本发明可选实施例的持续构建的交互示意图，如图7所示，该流程的步骤包括：

步骤S701，设置任务配置信息；

步骤S702，接收用户提交代码或者定时触发构建任务；

步骤S703，从控制台发起集成任务，构建任务进入任务队列；

步骤S704，从任务队列底部得到一个任务实例，获取任务的配置信息；

步骤S705，在容器服务器，初始化一个容器；

步骤S706，读取配置新信息；

步骤S707，获取配置信息，从源代码git拉取代码克隆；

步骤S708，得到一份代码克隆；

步骤S709，读取配置信息，从镜像服务器获取一个镜像；

步骤S710，镜像服务器返回镜像给容器；

步骤S711，对得到的代码进行静态检查，对检查的代码生成检查报告；

步骤S712，通过从配置信息得到编译工具，对代码进行编译；

其中，如果存在编译错误，那么生成错误信息，并反馈给配置用户；

步骤S713，通过获取配置信息的打包工具，对编译完成的代码进行打包；

步骤S714，把编译生成的包，和镜像进行整合，再合并一个整体运行环境；

步骤S715，执行自动化单元测试用例；

步骤S716，得到测试报告；

步骤S717，发送测试报告给配置用户；

步骤S718，上传应用包到存储服务器；

步骤S719，销毁容器，回收容器资源。

图8是根据本发明可选实施例的版本发布的交互示意图，如图8所示，该流程的步骤包括：

步骤S801，运维人员发设置配置信息，包括单不限于目标机器的地址，用户信息等；

步骤S802，手动或定时触发一个任务；

步骤S803，发起一个发布任务实例，加入发布队列；

步骤S804，从队列底部获取一个发布任务；

步骤S805，启动服务容器，初始化一个容器；

步骤S806，读取发布任务的配置信息；

步骤S807，从容器发起一个获取一个发布包1的请求；

步骤S808，从存储服务器获取一个发布包1；

步骤S809，发布包1部署app server1；

步骤S810，从容器发起一个获取一个发布包2的请求；

步骤S811，从存储服务器获取一个发布包2；

步骤S812，发布包2部署app server2；

步骤S813，从容器发起一个获取一个发布包n的请求；

步骤S814，从存储服务器获取一个发布包n；

步骤S815，发布包n部署app server n。

通过上述可选实施例，可知在保证用户数据之间的全性，以及减少用户重复的配置，减少部署方面的工作量，对于提高运维人员的工作效率有明显的效果，提高整个软件研发效率，与质量，其次可以提高单机处理容量，提高资源利用率。

需要说明的是，上述各个模块是可以通过软件或硬件来实现的，对于后者，可以通过以下方式实现，但不限于此：上述模块均位于同一处理器中；或者，上述模块分别位于多个处理器中。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种基于LXC的持续集成方法，其特征在于，包括：

LXC服务器中的一个LXC接收控制台发起的一个持续集成任务以及所述持续集成任务的配置信息；

所述LXC依据所述配置信息从源代码中克隆一份与所述持续集成任务对应的代码以及从镜像服务器中获取与所述持续集成任务对应的镜像；

所述LXC依据所述代码和所述镜像生成用于运行所述持续集成任务的运行环境；

所述LXC在所述运行环境中对所述持续集成任务的测试，并发送测试报告。

2.根据权利要求1所述的方法，其特征在于，所述LXC依据所述代码和所述镜像生成用于运行所述持续集成任务的运行环境包括：

所述LXC依据从所述配置信息中获取编译工具和打包工具；

所述LXC通过所述编译工具对所述代码进行编译，并通过所述打包工具对编译完成的代码进行打包；

所述LXC将编译并打包后的代码与所述镜像进行整合生成用于运行所述持续集成任务的运行环境。

3.根据权利要求1所述的方法，其特征在于，在所述LXC上报测试报告之后，所述方法还包括：

所述LXC得到对所述持续集成任务的测试成功的多个应用包，并将所述多个应用包上传到存储服务器。

4.根据权利要求3所述的方法，其特征在于，在将所述多个应用包上传到存储服务器之后，所述方法还包括：

所述LXC向所述存储服务器发送用于获取应用包的多个请求，其中，一个所述请求用于获取所述存储服务器中与该请求对应的一个应用包；

所述LXC将依据多个所述请求获取到的多个应用包分别部署到与应用包对应的应用服务器上。

5.根据权利要求3所述的方法，其特征在于，在所述LXC将所述多个应用包上传到存储服务器之后，所述方法还包括：

所述LXC接收所述LXC服务器用于销毁所述LXC和回收资源的请求。

6.一种基于LXC的持续集成装置，应用于LXC服务器中的一个LXC侧，其特征在于，包括：

第一接收模块，用于接收控制台发起的一个持续集成任务以及所述持续集成任务的配置信息；

克隆模块，用于依据所述配置信息从源代码中克隆一份与所述持续集成任务对应的代码以及从镜像服务器中获取与所述持续集成任务对应的镜像；

生成模块，用于依据所述代码和所述镜像生成用于运行所述持续集成任务的运行环境；

运行模块，用于在所述运行环境中对所述持续集成任务的测试，并发送测试报告。

7.根据权利要求6所述的装置，其特征在于，所述生成模块包括：

获取单元，用于依据从所述配置信息中获取编译工具和打包工具；

处理单元，用于通过所述编译工具对所述代码进行编译，并通过所述打包工具对编译完成的代码进行打包；

生成单元，用于将编译并打包后的代码与所述镜像进行整合生成用于运行所述持续集成任务的运行环境。

8.根据权利要求6所述的装置，其特征在于，在上报测试报告之后，所述装置还包括：

处理模块，用于所述LXC得到对所述持续集成任务的测试成功的多个应用包，并将所述多个应用包上传到存储服务器。

9.根据权利要求8所述的装置，其特征在于，在将所述多个应用包上传到存储服务器之后，所述装置还包括：

发送模块，用于向所述存储服务器发送用于获取应用包的多个请求，其中，一个所述请求用于获取所述存储服务器中与该请求对应的一个应用包；

部署模块，用于将依据多个所述请求获取到的多个应用包分别部署到与应用包对应的应用服务器上。

10.根据权利要求8所述的装置，其特征在于，在将所述多个应用包上传到存储服务器之后，所述装置还包括：

第二接收模块，用于接收所述LXC服务器用于销毁所述LXC和回收资源的请求。