基于Jenkins的构建任务处理方法、装置、电子设备和介质与流程

基于jenkins的构建任务处理方法、装置、电子设备和介质
技术领域
1.本公开涉及计算机技术领域或金融科技领域，更具体地，涉及一种基于jenkins的构建任务处理方法、装置、电子设备和介质。


背景技术：

2.随着云计算技术在行业内的实践发展，云原生架构完成了it架构在云计算时代的进化升级。在云端进行项目构建时，现阶段用的最多的构建调度工具是开源软件jenkins，jenkins用于自动化各种任务，包括构建、测试和软件部署。为此jenkins的稳定性不只决定了整个云平台的构建的平稳运行，还决定了整个平台的构建效率问题，因此jenkins的高可用性便成为云计算构建技术的重中之重。
3.在实现本公开构思的过程中，发明人发现相关技术中至少存在如下问题：jenkins自身包括master主节点和slave节点，master主节点一般作为控制节点，slave一般作为任务执行节点，一般在master主节点下挂载slave节点，主节点只进行任务的调度工作，构建任务则是在slave节点上进行。在进行构建任务作业时，如果挂载的slave节点数量较少，则不能满足大并发数的性能要求，作业需要长时间在队列中等待；如果挂载了大量slave节点，则在空闲时间会造成大量资源浪费，而且后期维护成本也很高。


技术实现要素：

4.有鉴于此，本公开提供了一种基于jenkins的构建任务处理方法、装置、电子设备、可读存储介质和计算机程序产品。
5.本公开的一个方面提供了一种基于jenkins的构建任务处理方法，包括：响应于来自构建任务分发平台的目标构建任务，查询容器集群中的多个工作节点的资源消耗状态，以从多个上述工作节点中确定目标工作节点；向上述目标工作节点发送上述目标构建任务，以在上述目标工作节点中确定目标部署单元；向上述目标部署单元发送jenkins镜像，以在上述目标部署单元中加载上述jenkins镜像，得到jenkins容器；以及控制上述目标工作节点向上述目标部署单元发送上述目标构建任务，以控制上述jenkins容器处理上述目标构建任务。
6.根据本公开的实施例，上述基于jenkins的构建任务处理方法还包括：基于jenkins主应用构建得到上述jenkins镜像；以及将上述jenkins镜像存储在镜像仓库中，其中，上述容器集群的控制节点在上述镜像仓库中拉取上述jenkins镜像。
7.根据本公开的实施例，上述基于jenkins主应用构建得到上述jenkins镜像，包括：利用上述jenkins主应用中与任务构建相关的组件，在基础镜像上构建得到上述jenkins镜像，其中，上述基础镜像中配置有预设操作系统内核。
8.根据本公开的实施例，上述查询容器集群中的多个工作节点的资源消耗状态，以从多个上述工作节点中确定目标工作节点，包括：获取多个上述工作节点的运行信息，其中，上述运行信息由上述工作节点的代理组件向上述容器集群的控制节点周期性发送；基
于多个上述工作节点的运行信息，确定多个上述工作节点的资源消耗状态；以及利用预设负载均衡策略，从多个上述工作节点中确定上述目标工作节点。
9.根据本公开的实施例，上述工作节点中配置有预设数量的处于长链接状态的第一部署单元；其中，上述在上述目标工作节点中确定目标部署单元，包括：查询上述目标工作节点中的第一部署单元的工作状态；在确定上述目标工作节点中存在处于空闲状态的目标第一部署单元的情况下，确定上述目标第一部署单元为上述目标部署单元；以及在确定上述目标工作节点中的第一部署单元均不处于上述空闲状态的情况下，在上述目标工作节点中创建第二部署单元，并确定上述第二部署单元为上述目标部署单元。
10.根据本公开的实施例，上述第一部署单元中运行有处于长链接状态的jenkins容器；上述方法还包括：在确定上述目标第一部署单元为上述目标部署单元之后，控制上述目标工作节点向上述目标第一部署单元发送上述目标构建任务，以控制上述目标第一部署单元中处于长链接状态的jenkins容器处理上述目标构建任务。
11.根据本公开的实施例，上述基于jenkins的构建任务处理方法还包括：在上述jenkins容器完成上述目标构建任务的处理的情况下，控制上述jenkins容器停止运行，并回收上述jenkins容器占用的资源。
12.本公开的另一个方面还提供了一种基于jenkins的构建任务处理装置，包括：查询模块，用于响应于来自构建任务分发平台的目标构建任务，查询容器集群中的多个工作节点的资源消耗状态，以从多个上述工作节点中确定目标工作节点；第一发送模块，用于向上述目标工作节点发送上述目标构建任务，以在上述目标工作节点中确定目标部署单元；第二发送模块，用于向上述目标部署单元发送jenkins镜像，以在上述目标部署单元中加载上述jenkins镜像，得到jenkins容器；以及控制模块，用于控制上述目标工作节点向上述目标部署单元发送上述目标构建任务，以控制上述jenkins容器处理上述目标构建任务。
13.本公开的另一个方面还提供了一种电子设备，包括：一个或多个处理器；存储器，用于存储一个或多个指令，其中，当上述一个或多个指令被上述一个或多个处理器执行时，使得上述一个或多个处理器实现上述的基于jenkins的构建任务处理方法。
14.本公开的另一方面还提供了一种计算机可读存储介质，其上存储有可执行指令，上述可执行指令被处理器执行时使处理器实现上述基于jenkins的构建任务处理方法。
15.本公开的另一个方面还提供了一种计算机程序产品，上述计算机程序产品包括计算机可执行指令，上述计算机可执行指令在被执行时用于实现上述基于jenkins的构建任务处理方法。
16.根据本公开的实施例，通过将jenkins构建为容器，并控制jenkins容器处理目标构建任务。在接收到目标构建任务时，因为利用了容器集群对jenkins容器进行管理，容器集群中的控制节点可以控制该容器集群的目标部署单元运行jenkins容器，进而控制该jenkins容器处理目标构建任务，实现对jenkins容器的动态创建和使用，进而实现了jenkins的池化高可用，降低jenkins的维护成本，至少部分地克服了相关技术中维护成本高、资源浪费率高的技术问题，进而达到了降低jenkins的维护成本、提高构建资源利用率的技术效果。
附图说明
17.通过以下参照附图对本公开实施例的描述，本公开的上述以及其他目的、特征和优点将更为清楚，在附图中：
18.图1示意性示出了根据本公开实施例的基于jenkins的构建任务处理方法和装置的示例性系统架构图；
19.图2示意性示出了根据本公开实施例的基于jenkins的构建任务处理方法的流程图；
20.图3示意性示出了根据本公开另一实施例的基于jenkins的构建任务处理方法的流程图；
21.图4示意性示出了根据本公开的实施例的基于jenkins的构建任务处理装置的框图；
22.图5示意性示出了根据本公开实施例的适于实现基于jenkins的构建任务处理方法的电子设备的框图。
具体实施方式
23.以下，将参照附图来描述本公开的实施例。但是应该理解，这些描述只是示例性的，而并非要限制本公开的范围。在下面的详细描述中，为便于解释，阐述了许多具体的细节以提供对本公开实施例的全面理解。然而，明显地，一个或多个实施例在没有这些具体细节的情况下也可以被实施。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本公开的概念。
24.在此使用的术语仅仅是为了描述具体实施例，而并非意在限制本公开。在此使用的术语“包括”、“包含”等表明了所述特征、步骤、操作和/或部件的存在，但是并不排除存在或添加一个或多个其他特征、步骤、操作或部件。
25.在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义，除非另外定义。应注意，这里使用的术语应解释为具有与本说明书的上下文相一致的含义，而不应以理想化或过于刻板的方式来解释。
26.在使用类似于“a、b和c等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有a、b和c中至少一个的系统”应包括但不限于单独具有a、单独具有b、单独具有c、具有a和b、具有a和c、具有b和c、和/或具有a、b、c的系统等)。在使用类似于“a、b或c等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有a、b或c中至少一个的系统”应包括但不限于单独具有a、单独具有b、单独具有c、具有a和b、具有a和c、具有b和c、和/或具有a、b、c的系统等)。
27.过去十年，云计算技术风起云涌，云的形态也在不断演进。随着云原生技术理念在行业内进一步的实践发展，云原生架构完成了it架构在云计算时代的进化升级。以ci/cd、devops、微服务架构为代表的云原生技术以其高效稳定、快速响应的特点驱动引领企业的业务发展，帮助企业构建更加适合用于云上的应用服务。在云端进行项目构建时，现阶段用的最多的构建调度工具是开源软件jenkins。jenkins自身是支持master主节点/slave节点方案，该方案是在master主节点下挂载slave节点，主节点只进行任务的调度工作，构建任
务则是在slave节点上进行。这样相较于单纯的使用master主节点去构建，解决了master主节点服务内存和cpu资源占用过高，导致master主节点崩溃和构建效率过低的问题。但是，各应用版本部署作业通常只在特定时间点进行，例如一周一次或一月一次，而且，在该特定时间各应用版本部署作业运行并发数可能非常高。在进行构建任务作业时，如果挂载的slave节点数量较少，则不能满足大并发数的性能要求，作业需要长时间在队列中等待；如果挂载了大量slave节点，则在空闲时间会造成大量资源浪费，而且后期维护成本也很高。
28.有鉴于此，本公共提出一种jenkins池化高可用方案，不再采用master主节点做任务调度，slave节点执行编译构建任务的方式。对所有的jenkins进行容器化，统一使用kubernetes进行统一管理，并通过kubernetes对jenkins镜像进行统一的启动、挂载和回收。每一个jenkins只有在有任务需要执行的时候才会被运行起来，并不像区分master主节点和slave节点方案中master主节点一直处于运行状态。这样可以更好的实现资源利用的最大化，以及节省不必要的浪费，并且减少由于master主节点调度slave节点而存在的时间消耗。
29.具体地，本公开提供了一种基于jenkins的构建任务处理方法、一种基于jenkins的构建任务处理装置、一种电子设备、一种可读存储介质和一种计算机程序产品。用于降低维护成本，提高资源的利用率。该方法包括：响应于来自构建任务分发平台的目标构建任务，查询容器集群中的多个工作节点的资源消耗状态，以从多个工作节点中确定目标工作节点；向目标工作节点发送目标构建任务，以在目标工作节点中确定目标部署单元；向目标部署单元发送jenkins镜像，以在目标部署单元中加载jenkins镜像，得到jenkins容器；以及控制目标工作节点向目标部署单元发送目标构建任务，以控制jenkins容器处理目标构建任务。
30.需要说明的是，本公开实施例确定的基于jenkins的构建任务处理方法和装置可用于计算机技术领域或金融科技领域。本公开实施例确定的基于jenkins的构建任务处理方法和装置也可用于除计算机技术领域和金融科技领域之外的任意领域。本公开实施例对确定的基于jenkins的构建任务处理方法和装置的应用领域不做限定。
31.在本公开的技术方案中，所涉及的用户个人信息的获取，存储和应用等，均符合相关法律法规的规定，采取了必要保密措施，且不违背公序良俗。在本公开的技术方案中，在获取或采集用户个人信息之前，均获取了用户的授权或同意。
32.图1示意性示出了根据本公开实施例的可以应用基于jenkins的构建任务处理方法和装置的示例性系统架构图。需要注意的是，图1所示仅为可以应用本公开实施例的系统架构的示例，以帮助本领域技术人员理解本公开的技术内容，但并不意味着本公开实施例不可以用于其他设备、系统、环境或场景。
33.如图1所示，根据该实施例的系统架构100可以包括终端设备101、102、103，构建任务分发平台104和服务器105。
34.终端设备101、102、103可以是处于公共环境或各种独立环境中的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。
35.终端设备上可以安装有各种通讯客户端应用，例如购物类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端和/或社交平台软件等(仅为示例)。
36.用户可以通过在终端设备101、102、103的客户端应用中进行操作，例如完成代码
的编译等操作，以执行业务功能，并提交至构建任务分发平台104执行构建目标构建任务。
37.构建任务分发平台104在终端设备101、102、103和服务器105之间可以通过有线和/或无线通信链路等方式进行链接。
38.服务器105可以是提供各种服务的服务器，例如云服务器，云服务器中维持有容器集群，该容器集群可以对构建任务分发平台所提交的目标构建任务提供分析处理。具体地，容器集群中的控制节点可以根据该目标构建任务，从查询容器集群中的多个工作节点中确定目标工作节点，在目标工作节点中确定目前部署单元，在目标部署单元中得到jenkins容器，以使得在jenkins容器中处理目标构建任务。
39.需要说明的是，本公开实施例所提供的基于jenkins的构建任务处理方法一般可以由服务器105执行。相应地，本公开实施例所提供的基于jenkins的构建任务处理装置一般可以设置于服务器105中。本公开实施例所提供的基于jenkins的构建任务处理方法也可以由不同于服务器105且能够与构建任务分发平台104和/或服务器105通信的服务器或服务器集群执行。相应地，本公开实施例所提供的基于jenkins的构建任务处理装置也可以设置于不同于服务器105且能够与构建任务分发平台104和/或服务器105通信的服务器或服务器集群中。或者，本公开实施例所提供的基于jenkins的构建任务处理方法也可以由构建任务分发平台104执行，或者也可以由不同于构建任务分发平台104的其他构建任务分发平台执行。相应地，本公开实施例所提供的基于jenkins的构建任务处理装置也可以设置于构建任务分发平台104中，或设置于不同于构建任务分发平台104的其他构建任务分发平台设备中。
40.应该理解，图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。
41.图2示意性示出了根据本公开实施例的基于jenkins的构建任务处理方法的流程图。
42.如图2所示，该方法包括操作s201～s204。
43.在操作s201，响应于来自构建任务分发平台的目标构建任务，查询容器集群中的多个工作节点的资源消耗状态，以从多个工作节点中确定目标工作节点。
44.在操作s202，向目标工作节点发送目标构建任务，以在目标工作节点中确定目标部署单元。
45.在操作s203，向目标部署单元发送jenkins镜像，以在目标部署单元中加载jenkins镜像，得到jenkins容器。
46.在操作s204，控制目标工作节点向目标部署单元发送目标构建任务，以控制jenkins容器处理目标构建任务。
47.根据本公开的实施例，目标构建任务可以是构建任务分发平台独立创建的构建任务，也可以是构建任务分发平台响应来自终端设备的构建任务请求得到的。具体地，在容器集群(kubernetes)中有两类节点：master节点、工作节点，其中master节点可以作为控制节点，可以至少部署1个(为了提高系统的可用性还可以部署多个)。工作节点作为负载节点，可以根据系统需求部署多个，以支持动态增加、删除。在master节点中可以有四个关键进程：kube-controller-manager、kube-apiserver、kube-scheduler、etcd。其中kube-apiserver与kube-controller-manager及、kube-scheduler间存在交互。用户可以通过
kubectl命令可以与kube-apiserver进行交互。kube-apiserver提供了http rest接口的关键服务进程，是kubernetes里所有资源增、删、改、查等操作的唯一入口，也是进kubernetes集群控制的入口进程；kube-controller-manager为kubernetes里所有资源对象的自动化控制中心，可以理解为资源对象的“总管”；kube-scheduler负责资源调度(部署单元调度)进程，相当于公交公司的“调度室”。构建任务分发平台可以通过master节点的kube-apiserver发送关于目标构建任务的任务处理请求。
48.根据本公开的实施例，目标工作节点可以是kubernetes集群的多个工作节点中尚有资源可以被利用的空闲工作节点，该空闲的工作节点可以用于处理目标构建任务。具体地，工作节点可以是一个虚拟机或者物理机器，可以根据kubernetes集群的种类进行适应性调整。工作节点上的服务可以包括docker engine、kubelet和kube-proxy。工作节点可以在运行期间动态增加到kubernetes集群中，前提是这个节点上已经正确安装、配置和启动了上述关键进程。在默认情况下kubelet会向master节点注册自己，这也是kubernetes集群推荐的工作节点管理方式。一旦工作节点被纳入kubernetes集群管理范围，kubelet进程就会定时向master节点汇报自己的情况，例如操作系统、docker版本、机器的cpu和内存情况以及当前有哪些部署单元在运行等，这样master节点可以获知每个工作节点的资源使用情况，并实现高效均衡的资源调度策略。
49.根据本公开的实施例，工作节点内可以包括多个部署单元。部署单元是kubernetes集群的基本构件，是在kubernetes集群中能够创建或部署的最小对象。一个部署单元代表群集中一个正在运行的进程。一个部署单元相当于一个共享context的配置组，在同一个context下，应用可还会有独立的cgroup隔离机制，一个部署单元是一个容器环境下的“逻辑主机”，它可能包含一个或多个紧密相连的应用，这些应用可能是在同一个物理主机或虚拟机上。每个工作节点都可以有用于运行部署单元的必要服务，并由master节点的组件管理。目标部署单元可以是目标工作节点的多个部署单元中处于空闲状态的部署单元，也可以是在现有的部署单元均是非空闲状态的情况下，创建的新的部署单元。
50.根据本公开的实施例，部署单元将一个应用程序容器(在某些情况下可以是多个容器，要在部署单元的yaml文件中做定义)、存储资源、唯一的网络ip以及控制容器应该如何运行的配置封装在一起。kubernetes集群中单个应用程序实例，可能包含单个容器或少量紧密耦合且共享资源的容器。jenkins容器便是运行在部署单元中，当有任务时便可以运行一个jenkins容器到部署单元中，构建任务结束时便可以通过kubernetes容器回收机制将运行的容器进行停止，从而实现资源的回收。
51.根据本公开的实施例，jenkins容器可以用于负责执行构建任务。在有目标构建任务出现的情况下，构建任务分发平台通过在kubernetes集群的部署单元上运行一个jenkins容器，该jenkins容器可以执行拉取代码、编译打包、代码质量扫描等构建任务。
52.根据本公开的实施例，通过将jenkins构建为容器，并控制jenkins容器处理目标构建任务。在接收到目标构建任务时，因为利用了容器集群对jenkins容器进行管理，容器集群中的控制节点可以控制该容器集群的目标部署单元运行jenkins容器，进而控制该jenkins容器处理目标构建任务，实现对jenkins容器的动态创建和使用，进而实现了jenkins的池化高可用，降低jenkins的维护成本，至少部分地克服了相关技术中维护成本高、资源浪费率高的技术问题，进而达到了降低jenkins的维护成本、提高构建资源利用率
的技术效果。
53.根据本公开的实施例，基于jenkins主应用构建得到jenkins镜像；以及将jenkins镜像存储在镜像仓库中，其中，容器集群的控制节点在镜像仓库中拉取jenkins镜像。
54.根据本公开的实施例，基于jenkins主应用构建得到jenkins镜像，包括：利用jenkins主应用中与任务构建相关的组件，在基础镜像上构建得到jenkins镜像，其中，基础镜像中配置有预设操作系统内核。
55.根据本公开得实施例，由于jenkins容器主要作用的来执行构建任务，因此jenkins镜像中可以包括与任务构建相关组件。与任务构建相关的组件可以包括maven、jdk、sonarscanner等。预设操作系统内核可以包括centos操作系统的linux内核、ubuntu操作系统的linux内核。基础镜像可以时包括预设操作系统内核的镜像。
56.根据本公开的实施例，搭建后的jenkins容器存储在统一的镜像仓库中，比如harbor镜像仓库，镜像仓库，可以对镜像进行统一的管理和存储。在以实施例中，在master节点上还可以部署一个etcd服务，因为kubernetes里的所有资源对象的数据都是保存在etcd中的，所以在使用该jenkins容器时可以通过kubernetes集群的master节点上的etcd服务从harbor镜像仓库中拉取jenkins镜像。该jenkins镜像在执行构建任务时，是运行在kubernets的部署单元中，每一个部署单元都是一个封闭的容器环境，提供了只供该jenkins镜像独立运行的所有资源。
57.根据本公开的实施例，操作s201还可以包括如下操作：获取多个工作节点的运行信息，其中，运行信息由工作节点的代理组件向容器集群的控制节点周期性发送；基于多个工作节点的运行信息，确定多个工作节点的资源消耗状态；以及利用预设负载均衡策略，从多个工作节点中确定目标工作节点。
58.根据本公开的实施例，代理组件可以包括docker engine、kubelet、kube-proxy等。例如，一旦工作节点被纳入kubernetes集群管理范围，kubelet进程就会定时向master节点汇报自己的情况，例如操作系统、docker版本、机器的cpu和内存情况，以及当前有哪些部署单元在运行等，这样master节点可以获知每个工作节点的资源使用情况，并实现高效均衡的资源调度策略。
59.根据本公开的实施例，预设负载均衡策略用于kubernetes集群中的master节点将处理构建任务的请求分发到与构建任务对应的各个工作节点上，以使得kubernetes集群中的各个工作节点的负载能够达到均衡状态。
60.根据本公开的实施例，当有构建任务需求时，kubernets集群的master节点会查询工作节点的资源使用情况，然后根据预设负载均衡策略确定还可以继续被调用的工作节点，以及在该工作节点创建部署单元，并利用该部署单元运行jenkins镜像，从而使jenkins镜像执行具体的构建任务。当有多个任务时，kubernetes可以启动多个容器，并且多个容器的启动可以通过不同端口进行区分。
61.根据本公开的实施例，工作节点中还可以配置有预设数量的处于长链接状态的第一部署单元。操作s202还可以包括如下操作：查询目标工作节点中的第一部署单元的工作状态；在确定目标工作节点中存在处于空闲状态的目标第一部署单元的情况下，确定目标第一部署单元为目标部署单元；以及在确定目标工作节点中的第一部署单元均不处于空闲状态的情况下，在目标工作节点中创建第二部署单元，并确定第二部署单元为目标部署单
元。
62.根据本公开的实施例，部署单元可以是是kubernets集群中的部署单元。为保证构建任务的时效性，可以在工作节点中保持10～20个的部署单元处于长链接状态。后期kubernets集群可根据构建任务数量动态增加部署单元数量，以及自动伸缩节点资源。预设数量还可以根据实际需要进行适应性调整。
63.根据本公开的实施例，在当前的部署单元处于空闲状态时，可以利用该部署单元运行jenkins容器；在当前的部署单元处于非空闲状态时，kubernets集群会创建一个新部署单元，利用该新建的部署单元运行jenkins容器。具体地，在构建任务调度时，kubernets集群会在工作节点中创建一个部署单元，该pod中运行jenkins容器，用来执行实际的构建任务，以使得对jenkins节点进行伸缩、启停和容器回收等操作。
64.根据本公开的实施例，传统的采用将jenkins master主节点和slave节点全部部署在虚拟机或物理机的模式，当构建任务数量大于jenkinsslave节点数量时，构建将会出现任务堵塞，从而导致构建效率降低，这样只能通过增加虚拟机或物理机数量来解决。而根据本公开的实施例，只需要增加kubernetes的部署单元数量，在每一个部署单元里面运行jenkins容器即可，并且每一个部署单元里面理论上最多可以运行130个容器，相较于传统方案中每一台物理机或虚拟机上运行一个构建任务的方式，资源利用率上得到了显著的提升。
65.根据本公开的实施例，第一部署单元中运行有处于长链接状态的jenkins容器；在确定目标第一部署单元为目标部署单元之后，控制目标工作节点向目标第一部署单元发送目标构建任务，以控制目标第一部署单元中处于长链接状态的jenkins容器处理目标构建任务。
66.根据本公开的实施例，为保证构建任务的时效性，还可以在部署单元中保持10～20个的jenkins容器处于长链接状态，后期kubernets集群可根据构建任务数量动态增加jenkins容器数量，以及自动伸缩容器资源。预设数量还可以根据实际需要进行适应性调整。
67.根据本公开的实施例，处于长链接状态的jenkins处理目标构建任务的操作可以包括拉取代码、编译打包、代码质量扫描等功能。
68.根据本公开的实施例，在jenkins容器完成目标构建任务的处理的情况下，控制jenkins容器停止运行，并回收jenkins容器占用的资源。
69.根据本公开的实施例，当构建任务结束时，可以直接调用kubernetes对容器进行停止，并回收该容器所占用的资源。具体地，使用kubectl命令启动jenkins容器命令，当jenkins上的任务执行结束后，可以使用命令，kubectl stop rc jenkins可以将容器进行停止，同时也将占用的资源进行回收。
70.图3示意性示出了根据本公开另一实施例的基于jenkins的构建任务处理方法的流程图。
71.如图3所示，本公开另一实施例的的基于jenkins的构建任务处理方法可以包括如下操作。
72.搭建kubernetes集群，用来对jenkins容器进行任务调度的控制，由于jenkins容器主要作用的来执行构建任务，因此jenkins镜像中只需要包含任务构建相关组件即可，比
如：maven、jdk、sonarscanner等。而jenkins镜像构建的基础镜像只需要是linux内核的基础镜像即可，比如像centos、ubuntu等操作系统均可。为保证构建任务的时效性，可以保持10-20个jenkins容器处于长链接状态，后期kubernets集群可根据构建任务数量动态增加jenkins容器数量，以及自动伸缩容器资源。
73.搭建一个jenkins容器，并将容器化后的镜像存储在统一的镜像仓库中，比如harbor镜像仓库。该jenkins镜像在执行构建任务时，是运行在kubernets的pod节点中，每一个pod节点都是一个封闭的容器环境，提供了只供该jenkins镜像独立运行的所有资源。
74.构建任务调度，kubernets集群会创建在node工作节点中创建一个pod节点，该pod节点中运行jenkins容器，用来执行实际的构建任务。对jenkins节点进行伸缩、启停和容器回收等操作，具体步骤如下。
75.当有构建任务需求时，kubernets集群的master节点会查询node工作节点的资源使用情况，然后确定node工作节点创建pod节点运行jenkins镜像，从而执行具体的构建任务；当有多个任务时，kubernetes便启动多个容器，并且多个容器启动通过不同端口来进行区分。
76.当构建任务结束时，直接调用kubernetes对容器进行停止，并回收该容器所占用的资源。使用kubectl命令启动jenkins容器命令如下所示：kubectl run jenkins
‑‑
image＝jenkins-image
‑‑
replicas＝2
‑‑
port＝80。这条命令是是用kubectl命令创建两个实例的jenkins-image pod，同时创建了两个运行实例，来保证始终有两个pod节点在运行，从而实现该基于jenkins的构建任务处理方法的高可用性。
77.一旦pod节点被创建成功后，便可以查看所有pod节点的启动和运行状态，使用kubectl get pods命令可以查看所有pod节点的启动和运行状态。
78.当jenkins上的任务执行结束后，可以使用命令：kubectl stop rc jenkins将容器进行停止，同时也将占用的资源进行回收。
79.根据本公开的实施例，传统的jenkins高可用主要采用的是虚拟机或物理机模式的主从方案，jenkins master主节点和jenkins slave节点都是部署在虚拟机或物理机上，当有jenkins高可用性资源不足时需要不断增加jenkins slave节点来提升运行效率，这就会导致slave节点的数量越来越多，维护的成本也会越来越高。而根据本公开实施例的jenkins完全容器化的方式，不区分master主节点和slave节点，全部容器用于执行构建任务。只有在有构建任务出现时，通过kubernetes集群创建jenkins容器；当构建任务结束时，可以将jenkins容器进行回收，这样对于执行节点的维护全部交由kubernetes集群进行管理，大大降低了维护成本。
80.根据本公开的实施例，在任务构建过程中，传统的高可用方案中当jenkins slave节点出现宕机时，该构建任务也就没法进行下去，需要运维人员手动的去启动slave节点再次进行构建才能进行。而根据本公开实施例的kubernetes管理执行节点的方式，当容器出现宕机的情况时，kubernetes会自动对容器进行重启，再次执行构建任务，这样可以解放人力，降低运维成本。
81.根据本公开的实施例，通过结合kubernetes可以实现对jenkins容器的动态创建、停止以及资源的回收利用，降低了对jenkins的维护成本，并且提高了对构建资源的利用率。
82.需要说明的是，本公开实施例中的流程图所示的操作除非明确说明不同操作之间存在执行的先后顺序，或者不同操作在技术实现上存在执行的先后顺序，否则，多个操作之间的执行顺序可以不分先后，多个操作也可以同时执行。
83.图4示意性示出了根据本公开的实施例的基于jenkins的构建任务处理装置的框图。
84.如图4所示，基于jenkins的构建任务处理装置400查询模块410、第一发送模块420、第二发送模块430、控制模块440。
85.查询模块410，用于响应于来自构建任务分发平台的目标构建任务，查询容器集群中的多个工作节点的资源消耗状态，以从多个工作节点中确定目标工作节点。
86.第一发送模块420，用于向目标工作节点发送目标构建任务，以在目标工作节点中确定目标部署单元。
87.第二发送模块430，用于向目标部署单元发送jenkins镜像，以在目标部署单元中加载jenkins镜像，得到jenkins容器。
88.控制模块440，用于控制目标工作节点向目标部署单元发送目标构建任务，以控制jenkins容器处理目标构建任务。
89.根据本公开的实施例，通过将jenkins构建为容器，并控制jenkins容器处理目标构建任务。在接收到目标构建任务时，因为利用了容器集群对jenkins容器进行管理，容器集群中的控制节点可以控制该容器集群的目标部署单元运行jenkins容器，进而控制该jenkins容器处理目标构建任务，实现对jenkins容器的动态创建和使用，进而实现了jenkins的池化高可用，降低jenkins的维护成本，至少部分地克服了相关技术中维护成本高、资源浪费率高的技术问题，进而达到了降低jenkins的维护成本、提高构建资源利用率的技术效果。
90.根据本公开的实施例，基于jenkins的构建任务处理装置还包括构建模块、存储模块。
91.构建模块，用于基于jenkins主应用构建得到jenkins镜像。
92.存储模块，用于将jenkins镜像存储在镜像仓库中，其中，容器集群的控制节点在镜像仓库中拉取jenkins镜像。
93.根据本公开的实施例，构建模块还包括构建单元。
94.构建单元，用于利用jenkins主应用中与任务构建相关的组件，在基础镜像上构建得到jenkins镜像，其中，基础镜像中配置有预设操作系统内核。
95.根据本公开的实施例，查询模块还包括：获取单元、第一确定单元、第二确定单元。
96.获取单元，用于获取多个工作节点的运行信息，其中，运行信息由工作节点的代理组件向容器集群的控制节点周期性发送。
97.第一确定单元，用于基于多个工作节点的运行信息，确定多个工作节点的资源消耗状态。
98.第二确定单元，用于利用预设负载均衡策略，从多个工作节点中确定目标工作节点。
99.根据本公开的实施例，第一发送模块还可以包括查询单元、第一创建单元、第二创建单元。
100.查询单元，用于查询目标工作节点中的第一部署单元的工作状态。
101.第一创建单元，用于在确定目标工作节点中存在处于空闲状态的目标第一部署单元的情况下，确定目标第一部署单元为目标部署单元。
102.第二创建单元，用于在确定目标工作节点中的第一部署单元均不处于空闲状态的情况下，在目标工作节点中创建第二部署单元，并确定第二部署单元为目标部署单元。
103.根据本公开的实施例，基于jenkins的构建任务处理装置还包括控制单元。
104.控制单元用于在确定目标第一部署单元为目标部署单元之后，控制目标工作节点向目标第一部署单元发送目标构建任务，以控制目标第一部署单元中处于长链接状态的jenkins容器处理目标构建任务。
105.根据本公开的实施例，基于jenkins的构建任务处理装置还包括回收模块。
106.回收模块，用于在jenkins容器完成目标构建任务的处理的情况下，控制jenkins容器停止运行，并回收jenkins容器占用的资源。
107.根据本公开的实施例的模块、子模块、单元、子单元中的任意多个、或其中任意多个的至少部分功能可以在一个模块中实现。根据本公开实施例的模块、子模块、单元、子单元中的任意一个或多个可以被拆分成多个模块来实现。根据本公开实施例的模块、子模块、单元、子单元中的任意一个或多个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(fpga)、可编程逻辑阵列(pla)、片上系统、基板上的系统、封装上的系统、专用集成电路(asic)，或可以通过对电路进行集成或封装的任何其他的合理方式的硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，根据本公开实施例的模块、子模块、单元、子单元中的一个或多个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。
108.例如，查询模块410、第一发送模块420、第二发送模块430、控制模块440中的任意多个可以合并在一个模块/单元/子单元中实现，或者其中的任意一个模块/单元/子单元可以被拆分成多个模块/单元/子单元。或者，这些模块/单元/子单元中的一个或多个模块/单元/子单元的至少部分功能可以与其他模块/单元/子单元的至少部分功能相结合，并在一个模块/单元/子单元中实现。根据本公开的实施例，查询模块410、第一发送模块420、第二发送模块430、控制模块440中的至少一个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(fpga)、可编程逻辑阵列(pla)、片上系统、基板上的系统、封装上的系统、专用集成电路(asic)，或可以通过对电路进行集成或封装的任何其他的合理方式等硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，查询模块410、第一发送模块420、第二发送模块430、控制模块440中的至少一个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。
109.需要说明的是，本公开的实施例中基于jenkins的构建任务处理装置部分与本公开的实施例中基于jenkins的构建任务处理方法部分是相对应的，基于jenkins的构建任务处理装置部分的描述具体参考基于jenkins的构建任务处理方法部分，在此不再赘述。
110.图5示意性示出了根据本公开实施例的适于实现基于jenkins的构建任务处理方法的电子设备的框图。图5示出的电子设备仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。
111.如图5所示，根据本公开实施例的计算机电子设备500包括处理器501，其可以根据存储在只读存储器(rom)502中的程序或者从存储部分508加载到随机访问存储器(ram)503中的程序而执行各种适当的动作和处理。处理器501例如可以包括通用微处理器(例如cpu)、指令集处理器和/或相关芯片组和/或专用微处理器(例如，专用集成电路(asic))，等等。处理器501还可以包括用于缓存用途的板载存储器。处理器501可以包括用于执行根据本公开实施例的方法流程的不同动作的单一处理单元或者是多个处理单元。
112.在ram 503中，存储有电子设备500操作所需的各种程序和数据。处理器501、rom 502以及ram 503通过总线504彼此相连。处理器501通过执行rom 502和/或ram 503中的程序来执行根据本公开实施例的方法流程的各种操作。需要注意，所述程序也可以存储在除rom502和ram 503以外的一个或多个存储器中。处理器501也可以通过执行存储在所述一个或多个存储器中的程序来执行根据本公开实施例的方法流程的各种操作。
113.根据本公开的实施例，电子设备500还可以包括输入/输出(i/o)接口，输入/输出(i/o)接口也连接至总线504。电子设备500还可以包括连接至i/o接口的以下部件中的一项或多项：包括键盘、鼠标等的输入部分506；包括诸如阴极射线管(crt)、液晶显示器(lcd)等以及扬声器等的输出部分507；包括硬盘等的存储部分508；以及包括诸如lan卡、调制解调器等的网络接口卡的通信部分509。通信部分509经由诸如因特网的网络执行通信处理。驱动器510也根据需要连接至i/o接口。可拆卸介质511，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器510上，以便于从其上读出的计算机程序根据需要被安装入存储部分508。
114.根据本公开的实施例，根据本公开实施例的方法流程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读存储介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分509从网络上被下载和安装，和/或从可拆卸介质511被安装。在该计算机程序被处理器501执行时，执行本公开实施例的系统中限定的上述功能。根据本公开的实施例，上文描述的系统、设备、装置、模块、单元等可以通过计算机程序模块来实现。
115.本公开还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中描述的设备/装置/系统中所包含的；也可以是单独存在，而未装配入该设备/装置/系统中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被执行时，实现根据本公开实施例的方法。
116.根据本公开的实施例，计算机可读存储介质可以是非易失性的计算机可读存储介质。例如可以包括但不限于：便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、便携式紧凑磁盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。
117.例如，根据本公开的实施例，计算机可读存储介质可以包括上文描述的rom 502和/或ram 503和/或rom 502和ram 503以外的一个或多个存储器。
118.本公开的实施例还包括一种计算机程序产品，其包括计算机程序，该计算机程序
包含用于执行本公开实施例所提供的方法的程序代码，当计算机程序产品在电子设备上运行时，该程序代码用于使电子设备实现本公开实施例所提供的基于jenkins的构建任务处理方法。
119.在该计算机程序被处理器501执行时，执行本公开实施例的系统/装置中限定的上述功能。根据本公开的实施例，上文描述的系统、装置、模块、单元等可以通过计算机程序模块来实现。
120.在一种实施例中，该计算机程序可以依托于光存储器件、磁存储器件等有形存储介质。在另一种实施例中，该计算机程序也可以在网络介质上以信号的形式进行传输、分发，并通过通信部分509被下载和安装，和/或从可拆卸介质511被安装。该计算机程序包含的程序代码可以用任何适当的网络介质传输，包括但不限于：无线、有线等等，或者上述的任意合适的组合。
121.根据本公开的实施例，可以以一种或多种程序设计语言的任意组合来编写用于执行本公开实施例提供的计算机程序的程序代码，具体地，可以利用高级过程和/或面向对象的编程语言、和/或汇编/机器语言来实施这些计算程序。程序设计语言包括但不限于诸如java，c++，python，“c”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(lan)或广域网(wan)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。
122.附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。本领域技术人员可以理解，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合，即使这样的组合或结合没有明确记载于本公开中。特别地，在不脱离本公开精神和教导的情况下，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合。所有这些组合和/或结合均落入本公开的范围。
123.以上对本公开的实施例进行了描述。但是，这些实施例仅仅是为了说明的目的，而并非为了限制本公开的范围。尽管在以上分别描述了各实施例，但是这并不意味着各个实施例中的措施不能有利地结合使用。本公开的范围由所附权利要求及其等同物限定。不脱离本公开的范围，本领域技术人员可以做出多种替代和修改，这些替代和修改都应落在本公开的范围之内。