一种kubernetes集群的应用部署方法及装置与流程

1.本技术涉及云平台技术领域，特别涉及一种kubernetes集群的应用部署方法及装置。


背景技术：

2.现有的devops流程是基于gitlab或者jenkins实现的，所以无法避免开发环境、测试环境、生产环境存在差异，更无法实现持续集成、自动化测试、持续交付、持续部署等流程。并且，现有的devops流程需要的人工工作量较大，效率很低。


技术实现要素：

3.本技术实施例提供了一种云原生平台的集群部署方法及装置，可以保证应用的开发环境、测试环境、生产环境一直，实现持续集成、自动化测试、持续交付、持续部署等自动化流程。
4.第一方面，本技术实施例提供了一种kubernetes集群的应用部署方法，包括：通过kubernetes集群中jenkins主节点调用所述jenkins主节点镜像在所述jenkins主节点部署第一jenkins服务；
5.通过所述第一jenkins服务向jenkins工作节点触发在jenkins工作节点部署第二jenkins服务的指令；
6.通过所述jenkins工作节点调用所述jenkins工作节点镜像在所述jenkins主节点部署第二jenkins服务；
7.通过所述jenkins工作节点的第二jenkin服务从源码仓库获取应用的源代码，根据所述应用的源代码生成所述应用的docker镜像；
8.通过所述jenkins工作节点调用所述第二jenkins服务调用所述应用的docker镜像，以在所述第二jenkins服务部署所述应用。
9.上述方案中，首先在kubernetes集群中部署第一jenkins服务与第二jenkins服务，进而通过部署成功的jenkins服务将应用部署在kubernetes集群中，提高了应用交付的效率，减少了开发人员、测试人员、运维人员的工作量。
10.在一种可能的实现方式中，通过所述第一jenkins服务向jenkins工作节点触发在jenkins工作节点部署第二jenkins服务的指令，包括：
11.在监控到所述源码仓库存在所述应用的源代码更新时，通过所述第一jenkins服务向jenkins工作节点触发在jenkins工作节点部署第二jenkins服务的指令。
12.在监控到所述源码仓库增加所述应用源代码时，通过所述第一jenkins服务向jenkins工作节点触发在jenkins工作节点部署第二jenkins服务的指令。
13.基于上述方案，第一jenkins服务可以自动监控源码仓库中的应用源代码是否有更新或者增加，不需要人工进行干预，减少了人员工作量，提高了效率。
14.在一种可能的实现方式中，通过第一dockerfile文件创建jenkins主节点镜像，并
通过kubernetes集群将所述jenkins主节点镜像推送到镜像仓库中；
15.通过kubernetes集群中jenkins主节点调用jenkins主节点镜像在所述jenkins主节点部署第一jenkins服务，包括：
16.通过kubernetes集群中jenkins主节点从镜像仓库中调用jenkins主节点镜像在所述jenkins主节点部署第一jenkins服务。
17.在一种可能的实现方式中，通过第二dockerfile文件创建jenkins工作节点镜像，并通过kubernetes集群将所述jenkins工作节点镜像推送到镜像仓库中；
18.通过所述jenkins工作节点调用所述jenkins工作节点镜像在所述jenkins主节点部署第二jenkins服务，包括：
19.通过jenkins工作节点从镜像仓库中调用jenkins工作节点镜像在所述jenkins工作节点部署第二jenkins服务。
20.基于上述方案，通过预先编写好的第一dockerfile文件和第二dockerfile文件创建jenkins主节点镜像和工作节点镜像，并将生成的主节点镜像和工作节点镜像都推送到镜像仓库中，可以保证后续测试环境的镜像仓库与开发环境的镜像仓库一致，避免出现误差。
21.在一种可能的实现方式中，所述方法还包括：
22.在所述第二jenkins服务部署所述应用之前，通过第三dockerfile文件创建tomcat镜像，所述tomcat镜像用于保证应用可以在kubernetes集群环境中正常运行；通过kubernetes集群将所述tomcat节点镜像推送到所述镜像仓库中；
23.通过所述jenkins工作节点调用所述jenkins工作节点镜像在所述jenkins主节点部署第二jenkins服务之后，通过所述jenkins工作节点从所述镜像仓库中拉取所述tomcat镜像在所述jenkins工作节点部署所述tomcat服务。
24.基于上述方案，在部署所述应用之前，首先创建tomcat镜像，并在调用应用的docker镜像时同步调用tomcat镜像以保证后续部署的应用可以正常运行在kubernetes集群环境中。
25.第二方面，基于与第一方面同样的发明构思，本技术实施例提供了一种kubernetes集群的应用部署装置，所述kubernetes集群的应用部署装置可以用于实现上述第一方面任一种可能实现的方式，有益效果可以参见第一方面，此处不再赘述。kubernetes集群的应用部署装置包括：
26.处理单元，用于通过kubernetes集群中jenkins主节点调用jenkins主节点镜像在所述jenkins主节点部署第一jenkins服务；
27.所述处理单元，还用于通过所述第一jenkins服务向jenkins工作节点触发在jenkins工作节点部署第二jenkins服务的指令；
28.所述处理单元，还用于通过所述jenkins工作节点调用所述jenkins工作节点镜像在所述jenkins主节点部署第二jenkins服务；
29.获取单元，用于通过所述jenkins工作节点的第二jenkin服务从源码仓库获取应用的源代码；
30.生成单元，用于根据所述应用的源代码生成所述应用的docker镜像；
31.所述处理单元，还用于通过所述jenkins工作节点的所述第二jenkins服务调用所
述应用的docker镜像，以在所述第二jenkins服务部署所述应用。
32.在一种可能的实现方式中，所述处理单元，在向jenkins工作节点触发在jenkins工作节点部署第二jenkins服务的指令时，具体用于：在监控到所述源码仓库存在所述应用的源代码更新时，通过所述第一jenkins服务向jenkins工作节点触发在jenkins工作节点部署第二jenkins服务的指令。
33.在一种可能的实现方式中，所述处理单元，在向jenkins工作节点触发在jenkins工作节点部署第二jenkins服务的指令时，具体用于：在监控到所述源码仓库增加所述应用源代码时，通过所述第一jenkins服务向jenkins工作节点触发在jenkins工作节点部署第二jenkins服务的指令。
34.在一种可能的实现方式中，所述生成单元，还用于通过第一dockerfile文件创建jenkins主节点镜像；
35.所述装置还包括：
36.推送单元，用于将所述jenkins主节点镜像推送到镜像仓库中；
37.所述处理单元，具体用于通过kubernetes集群中jenkins主节点从镜像仓库中调用jenkins主节点镜像在所述jenkins主节点部署第一jenkins服务。
38.在一种可能的实现方式中，所述生成单元，还用于通过第二dockerfile文件创建jenkins工作节点镜像；
39.所述装置还包括：
40.推送单元，用于将所述jenkins工作节点镜像推送到镜像仓库中；
41.所述处理单元，具体用于通过jenkins工作节点从镜像仓库中调用jenkins工作节点镜像在所述jenkins工作节点部署第二jenkins服务。
42.在一种可能的实现方式中，所述生成单元，还用于在所述第二jenkins服务部署所述应用之前，通过第三dockerfile文件创建tomcat镜像，所述tomcat镜像用于保证应用可以在kubernetes集群环境中正常运行；
43.所述装置还包括：
44.推送单元，用于将所述tomcat节点镜像推送到镜像仓库中；
45.所述处理单元，还用于通过所述jenkins工作节点调用所述jenkins工作节点镜像在所述jenkins主节点部署第二jenkins服务之后，通过所述jenkins工作节点从所述镜像仓库中拉取所述tomcat镜像在所述jenkins工作节点部署所述tomcat服务。
46.第三方面，提供了一种电子设备，所述电子设备包括处理器和存储器。存储器用于存储计算机执行指令，处理器执行存储器中的计算机执行指令以利用控制器中的硬件资源执行第一方面或第一方面任一种可能实现方式中方法的操作步骤。
47.第四方面，本技术提供一种计算机可读存储介质，计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述各方面的方法。
48.另外，第二方面至第四方面的有益效果可以参见如第一方面所述的有益效果，此处不再赘述。
附图说明
49.为了更清楚地说明本技术实施例或现有技术中的技术方案，下面将对实施例描述
中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术的一些实施例。
50.图1为本技术实施例提供的一种云原生平台的集群部署方法流程图；
51.图2本技术实施例提供的一种云原生平台的集群部署的装置的结构示意图；
52.图3为本技术实施例提供的一种电子设备的结构示意图。
具体实施方式
53.为了使本技术的目的、技术方案和优点更加清楚，下面将结合附图对本技术作进一步地详细描述，显然，所描述的实施例仅仅是本技术的一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
54.需要说明的是，在本文中提及的“多个或者若干个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。字符“三种一般表示前后关联对象是一种“或”的关系。
55.本技术的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本技术的实施例能够以除了在这里图示或描述的那些以外的顺序实施。
56.对本技术实施例提供的方案描述之前，对本技术涉及的技术术语进行描述。
57.(1)docker是一个开源的应用容器(container)引擎。docker的源代码可以托管在github上，基于go语言并遵从apache2.0协议开源。docker将应用程序与docker程序的依赖，打包在一个文件里面。运行这个打包后的文件，生成一个虚拟容器。程序在这个虚拟容器里运行，就像在真实的物理机上运行一样。
58.(2)kubernetes，简称k8s，是一个开源的容器集群管理系统，可以实现容器集群的自动化部署、自动扩缩容、维护等功能。一个集群有多个节点，每个节点可以创建多个容器，k8s可以用于管理多个节点上创建的容器。k8s在docker技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，是一个完备的分布式系统支撑平台，涵盖了包括开发、部署测试、运维监控在内的各个环节。
59.(3)rancher是一个容器管理平台，可以对k8s集群进行管理。举例来说，rancher具有一套用于管理k8s的组件，用于实现部署容器到k8s集群中。rancher可以创建来自kubernetes托管服务提供商的集群，自动创建节点并安装到kubernetes集群，或者导入任何已经存在的kubernetes集群中。
60.(4)jenkins是一种持续集成和持续交付工具，它可以用来自动构建、测试和部署软件。
61.(5)tomcat是apache软件基金会(apache software foundation)的jakarta项目中的一个核心项目，由apache、sun和其他一些公司及个人共同开发而成。tomcat服务器是一个免费的开放源代码的万维网(world wide web，web)应用服务器，属于轻量级应用服务器，是开发、调试jsp(java server pages)程序的首选。
62.现有的devops流程是基于源码仓库与jenkins实现的，这种实现方式无法避免开发环境、测试环境、生产环境的差异，也就无法实现持续集成、自动化测试、持续交付、持续部署等流程。基于此，本技术提出了一种基于云原生平台的集群部署方法，将应用服务移至云端，可以保证开发环境、测试环境、生产环境的一致，能够实现持续集成、自动化测试、持续交付等自动化流程，无需手动进行干预，减轻人员工作量，是应用服务的测试、交付、部署等流程自动完成。
63.为了便于理解本技术实施例，以图1示出的流程图为例进行具体说明。
64.本技术实施例的方法可以由一个安装有rancher平台和容器编辑软件的客户端设备执行。例如，容器编辑软件可以是jenkins。
65.101，通过k8s集群中jenkins主节点调用jenkins主节点镜像在所述jenkins主节点部署第一jenkins服务。
66.102，通过所述第一jenkins服务向jenkins工作节点触发在jenkins工作节点部署第二jenkins服务的指令。
67.103，通过所述jenkins工作节点调用所述jenkins工作节点镜像在所述jenkins主节点部署第二jenkins服务。
68.104，通过所述jenkins工作节点的第二jenkin服务从源码仓库获取应用的源代码，根据所述应用的源代码生成所述应用的docker镜像。
69.105，通过所述jenkins工作节点调用所述第二jenkins服务调用所述应用的docker镜像，以在所述第二jenkins服务部署所述应用。
70.本技术实施例中，开发人员提交在应用代码仓库提交应用代码后，自动触发jenkins工作节点从代码仓库中获取应用代码，并通过第二jenkins服务构建应用的docker镜像，将构建成功后的docker容器化的应用自动部署在k8s集群中。本技术可以通过rancher结合jenkins进行应用部署流程，可以保证开发环境、测试环境、生产环境的一致，可以实现持续集成、自动化测试、持续交付、持续部署等自动化流程，不再需要手动进行干预，可以实现应用的灰度升级等应用升级策略，减轻运维人员工作量，使服务的测试、交付、部署等流程自动化完成。
71.通过上述方案部署应用后，可以通过邮件的方式通知开发人员和测试人员进行测试，定版后，通过邮件的方式自动通知运维人员进行版本发布。当运维人员需要进行灰度升级或金丝雀升级时，可以直接使用rancher进行对应服务的升级。
72.在执行步骤101之前，首先可以先创建基于k8s集群的jenkins主节点镜像和jenkins工作节点镜像，并通过k8s集群将所述jenkins主节点镜像和所述jenkins工作节点镜像推送到镜像仓库中。进而在jenkins工作节点部署jenkins服务时，可以从镜像仓库拉取jenkins主节点镜像从而实现在jenkins工作节点部署jenkins服务。
73.以容器编辑软件为jenkins为例，在创建k8s基于k8s集群的jenkins主节点镜像和jenkins工作节点镜像之前，可以先通过rke(rancher kubernetes engine)工具创建k8s集群。可选地，k8s集群的功能可以由一个或多个服务器来实现，例如，多个服务器可以包含管理服务器、工作服务器等等。管理服务器可以用于实现jenkins主节点的功能，工作服务器可以用于实现jenkins工作节点的功能。
74.创建jenkins主节点镜像和jenkins工作节点镜像时，可以由主节点根据主节点的
docker配置文件(也可以称为第一dockerfile文件)来创建jenkins主节点镜像，根据工作节点的docker配置文件来创建jenkins工作节点镜像。
75.docker配置文件，比如dockerfile，可以是由开发人员预先编写。dockerfile是由一系列命令和参数构成的脚本。在编写dockerfile时，可将相关的k8s集群组件安装包放至dockerfile所在的目录中。
76.dockerfile中可以配置一些插件源，以便于后续快速下载所需的插件。dockerfile可以根据需求配置所应用的国家的时区，比如中国时区，便于有效查看镜像内的系统时间。dockerfile中还可以所需安装的kubectl工具的配置信息，从而支持在工作节点内执行kubectl apply-f命令，以将镜像服务部署到kubernetes集群中。为了保证环境的一致性，jenkins主节点镜像和jenkins工作节点镜像使用相同的kubectl工具版本，比如统一使用了jdk8u201版本。dockerfile中还可以配置在jenkins主节点和工作节点中安装maven的配置信息，从而支持在工作节点中对java项目进行编译和打包。
77.作为一种举例，主节点的第一dockerfile文件的内容如下：
78.[0079][0080]
作为另一种举例，工作节点的第二dockerfile文件的内容如下：
[0081]
[0082][0083]
可选地，可以通过使用如下docker命令生成jenkins主节点镜像：
[0084]
docker build-t 192.168.15.143:4442/devops/jenkins-kubectl-jdk-maven:20200915.
[0085]
可选地，还可以通过使用如下的docker命令生成jenkins工作节点镜像:
[0086]
docker build-t 192.168.15.143:4442/devops/jnlp-kubectl-jdk-maven:201200915.
[0087]
在一种可能实现的方式中，k8s集群的功能可以由一个或多个服务器来实现的，比如，k8s集群中包括管理服务器和工作服务器。可选地，可以通过管理服务器将创建的jenkins主节点镜像和jenkins工作节点镜像推送到镜像仓库中。所述镜像仓库用于保存镜像文件，比如包括jenkins主节点镜像和jenkins工作节点镜像。当k8s集群中的管理服务器需要应用镜像文件时，可以访问镜像仓库，拉取所需的镜像文件。
[0088]
在步骤102中，部署第一jenkins服务时，可以通过k8s集群中的管理服务器拉取镜像仓库中的jenkins主节点镜像，并采用第一配置文件在jenkins主节点部署第一jenkins服务。
[0089]
本技术具体采用rancher集成外置jenkins，避免了rancher内置的jenkins无法缓存依赖jar包、无法接入第三方镜像仓库等缺点，使用jenkins进行应用的构建、打包、docker容器化，部署到k8s集群，升级服务等内容，提高了应用软件交付的效率，减少了开发人员、测试人员、运维人员的工作量。
[0090]
所述第一配置文件可以采用yaml文件格式。第一配置文件中可以包括k8s集群中的服务账号(service account)，作为jenkins的管理员账户(jenkins-test-admin)。
[0091]
第一配置文件中service account与集群角色(clusterrole)存在绑定关系。clusterrole对象可以授予整个集群范围内资源访问权限。本技术中，将一个clusterrole角色中定义的各种权限授予service account，则该服务账号具有对应绑定的clusterrole定义的权限。同时将该service account赋给deployment(jenkins-test)，这样deployment(jenkins-test)中的容器(jenkins-test)就有了clusterrole(cluster-admin)的权限。
[0092]
在本技术中k8s服务(service)是为正在运行的服务(包含多个服务的实例，即pod)提供了一个统一的接入方式。service的type可以为nodeport，即在每个节点上分配一个端口作为外部访问入口，也就是为在当前宿主机上映射一个物理端口给运行的pod，这样pod中的服务可以通过宿主机ip和宿主机端口提供外部访问。
[0093]
deployment为我们期望的服务状态。描述了该服务使用的基础镜像，该服务的pod的副本数等信息。
[0094]
第一配置文件还包括用于描述所使用的容器(由镜像生成)的容器描述信息，比如可以包括容器暴漏的端口，容器运行需要的内存和中央处理器(central processing unit，cpu)，容器可以使用的最大的内存和cpu，该容器存活状态的检测，该容器需要挂载的目录，或者该容器内部的环境变量等中的一项或多项。
[0095]
第一配置文件还可以包括持久卷声明，比如persistentvolumeclaim。可以通过nfs作为持久卷提供者，也可以使用glusterfs或cephfs等分布式存储作为持久卷提供者。
[0096]
作为一种举例，在所述jenkins主节点部署第一jenkins服务所使用的第一配置文件内容可以包括如下：
[0097]
[0098]
[0099]
[0100][0101]
可选地，基于上述第一配置文件，可以通过执行如下命令在k8s集群的所述jenkins主节点部署第一jenkins服务：
[0102]
kubectl create-f jenkins.yaml
[0103]
作为一种举例，第一配置文件中还可以指定命名空间，进而后续可以通过命名空间快速查看当前运行的节点(pod)。
[0104]
比如，可以通过运行如下脚本中包括的命令kubectl get pod-n jenkins-test来实现查看当前运行的pod：
[0105]
[root@c48-1 jenkins]#kubectl get pod
–
n jenkins-test
[0106]
name ready status restarts age
[0107]
jenkins-test-98c9b6665-nm7nd 1/1 running 1 146m
[0108]
[root@c48-1 jenkins]#
[0109]
作为一种举例，还可以通过命名空间快速查看当前运行的节点所执行的jenkins服务。
[0110]
比如，可以通过运行如下脚本包括的命令kubectl get pod-n jenkins-test来实现查看当前运行的pod的jenkins服务：
[0111]
[root@c48-1 jenkins]#kubectl get svc
–
n jenkins-test
[0112]
name type cluster-ip external-ip port(s)age
[0113]
jenkins-test nodeport 10.105.139.16《none》8080:8080/tcp,50000:50000/tcp 8d
[0114]
[root@c48-1 jenkins]#
[0115]
在一种可能实现的方式中，在所述第二jenkins服务部署所述应用之前，构建tomcat镜像，所述tomcat镜像用于保证应用可以在k8s集群环境中正常运行。可选地，tomcat镜像构建完成后，可以先保存到镜像仓库中，在第二jenkins服务从镜像仓库中拉取应用的docker镜像时，同步拉取tomcat镜像。
[0116]
作为一种举例，构建tomcat镜像的第三dockerfile文件内容包括如下：
[0117]
[0118]
[0119]
[0120]
[0121][0122]
在步骤102中，当第一jenkins服务部署完成后，可以向k8s集群中的jenkins工作节点触发部署第二jenkins服务的指令。
[0123]
第一种可能的实现方式，jenins主节点可以主动轮询源码库，在检测到源码有更新的情况下，向k8s集群中的jenkins工作节点触发部署第二jenkins服务的指令。所述源码库可以是gitlab或者svn仓库，以下以svn仓库为例进行具体说明。
[0124]
第二种可能的实现方式，在svn仓库客户端创建有客户端钩子(hooks)来触发部署第二jenkins服务的指令。创建的客户端钩子可以用于实现通过svn仓库中版本的更新事件来触发部署服务，例如新版本的创建或一个版本的更新。
[0125]
第三种可能的实现方式，在svn仓库服务器端创建有仓库服务器hooks来触发部署第二jenkins服务的指令。
[0126]
下面，以第三种可能的实现方式为例，对svn仓库服务器端创建仓库hooks进行说明。
[0127]
svn仓库服务器创建仓库hooks的原理是：当对svn仓库执行一些操作时，例如，创建一个新的修订版本或者修改一个版本的属性，就会触发hooks目录下的相对应的程序。其中操作的时间(或者时间节点)与所述程序的文件名是相对应的，下面将所述程序文件称为第二配置文件。可选地，第二配置文件可以是post-commit。第二配置文件的代码保存在svn仓库中，如果hooks目录下检测到存在第二配置文件，则该第二配置文件会被触发运行。需要说明的是，所述第二配置文件可以是任意可执行的程序，本技术实施例不作具体限定。例如，程序文件可以是shell脚本、python脚本、二进制程序等等。
[0128]
作为一种具体的举例，在svn服务器上，仓库hooks目录中，创建程序文件，比如可以是post-commit。创建post-commit之后，可以为其赋予可执行的权限，用于自动触发服务部署，比如：touch post-commit&&chomd 755post-commit。
[0129]
例如，post-commit内容可以包括如下：
[0130]
[0131][0132]
需要说明的是，在第二jenkins服务部署完成之后，jenkins服务便成功部署在k8s集群中主节点和工作节点中。应理解的是，在首次完成jenkins服务部署时，可以生成jenkins配置页面，用于通过jenkins配置页面对jenkins服务实现应用的一些信息进行进一步配置。
[0133]
作为一种举例，第二配置文件中checkout脚本代码的生成方式为：开发人员通过点击jenkins服务页面中的pipeline syntax，并填入应用对应的svn地址和svn认证凭证，其中不同的应用对应不同的svn地址和svn认证凭证。继续点击生成流水线脚本，并将脚本替换到第二配置文件中checkout脚本的相应位置即可。进一步地，根据不同的应用，修改上
述页面流水线中的branch、namespace、app、port、replicas等参数即可。
[0134]
当第一jenkins服务与第二jenkins服务在k8s集群中部署完成之后，还可以进一步对jenkins服务进行配置插件以使得jenkins服务支持k8s集群环境。具体地，可以利用jenkins服务页面中的可选插件选项选择需要配置的插件来下载配置jenkins服务支持k8s集群环境所需的插件。比如，插件可以包括：
[0135]
kubernetes cli plugin：该插件支持jenkins服务使用k8s命令行；
[0136]
kubernetes plugin：该插件能够使jenkins支持k8s环境，使用k8s则需要安装该插件；
[0137]
kubernetes continuous deploy plugin：该插件是k8s部署插件，使jenkins结合k8环境能够实现持续部署。
[0138]
具体的，开发人员可以通过在jenkins服务页面中依次点击系统管理-插件管理-可选插件，在可选插件页面点击安装上述插件。
[0139]
k8s集群中的第一jenkins服务与第二jenkins服务部署完成后，还需要给jenkins服务配置源代码库的认证凭证。具体操作包括：在jenkins服务页面中依次点击凭证-全局凭证-添加凭证-填入源代码库的用户名和密码，例如，可以是svn仓库的用户名和密码。
[0140]
完成jenkins服务的部署之后，进一步地，可以创建devops流水线。
[0141]
比如，可以通过jenkins服务的显示页面创建devops流水线。具体的，
[0142]
流水线框中部署如下脚本文件，后续再执行应用的部署时，可以通过如下脚本来自动实现应用的部署：
[0143]
[0144]
[0145]
[0146]
[0147][0148]
作为一种举例，上述脚本文件中的checkout脚本代码可以通过如下方式来实现：
[0149]
在pipeline流水线中，通过pipeline syntax，填入项目的svn地址和svn认证凭据，以生成流水线中的checkout脚本代码。
[0150]
作为另一种举例，上述脚本文件中执行的stage("deploy")需要的配置文件可以包括在devops流水线中用于执行镜像构建操作和服务部署操作所需的文件。比如，用于执行镜像构建所需的文件称为dockerfile1，用于执行服务部署操作所需的文件称为deployment.yaml。
[0151]
比如，dockerfile1的内容可以包括如下：
[0152][0153]
比如，deployment.yaml的文件内容包括如下：
[0154]
[0155][0156]
如上配置成功后，就可以在开发人员提交在应用代码仓库提交应用代码后，自动触发jenkins工作节点从代码仓库中获取应用代码，并通过第二jenkins服务构建应用的docker镜像，将构建成功后的docker容器化的应用自动部署在k8s集群中。可以实现持续集成、自动化测试、持续交付、持续部署等自动化流程，不再需要手动进行干预，可以实现应用的灰度升级等应用升级策略，减轻运维人员工作量。上述配置成功后，可以同时通过邮件的方式通知开发人员和测试人员进行测试，定版后，通过邮件的方式自动通知运维人员进行版本发布。打破了开发人员、测试人员和运维人员的壁垒，开发者和运维人员定期进行密切的合作。运维角色成为成软件的另一个用户群体。提高了软件版本交付速度，减轻软件开
发、测试、运维人员工作量，让软件在市场上更具竞争力。
[0157]
在一种可能实现的方式中，上述配置完成后，用户的具体使用流程如下：
[0158]
a1，项目经理、开发人员等使用禅道工具进行需求梳理、任务拆分。所述禅道工具是一种国产的开源项目管理软件，专注研发项目管理，内置需求管理、任务管理、bug管理、缺陷管理、用例管理、计划发布等功能,实现了软件的完整生命周期管理。
[0159]
a2，开发人员在进行代码编写，自测通过后，将代码提交到源代码仓库，例如svn或者git等。
[0160]
a3，持续集成工具jenkins通过源代码仓库hooks检测到有代码更新，在jenkins工作节点部署第二jenkins服务，第二jenkins服务具体包括b1-b5：
[0161]
b1，从源代码仓库拉取最新的应用代码，进行maven编译，并使用docker工具进行打包，打包的形式可以是war包，也可以是jar包。
[0162]
b2，调用sonarqube平台进行代码质量检测，所述sonarqube平台是一个代码质量管理平台，跟踪并最终提高源代码的质量。这是一个基于web的应用程序，可保留各种指标的历史数据，并为开发人员的所有错误提供领先和滞后的指标趋势。
[0163]
b3，创建应用的docker镜像，并推送到镜像仓库中。
[0164]
b4，进一步地，将docker容器化后的应用部署或者升级到k8s集群环境中。
[0165]
b5，部署成功\失败，触发服务器生成邮件通知开发人员和测试人员部署结果，提醒开发人员或者测试人员修复错误。
[0166]
a4，测试人员根据测试报告，在禅道等系统上将缺席啊或者修改点反馈给开发人员。
[0167]
a5，开发人员根据测试人员的反馈进行bug修改，或者逻辑修改。修改完成后循环进行a2-a5的步骤。
[0168]
a6，在版本定版时，开发人员将稳定版本提交到发布分支，将定版版本自动部署到测试环境中(参考步骤a3)。
[0169]
a7，定版版本部署成功后会发送邮件通知运维人员，将定版信息比如定版服务docker镜像的版本号告知运维人员。
[0170]
a8，k8s集群环境的镜像仓库与生成环境的镜像仓库进行应用的docker镜像同步，将定版应用的docker镜像同步至生产环境。
[0171]
a9，运维人员登陆rancher管理端，输入定版服务镜像版本号及其他信息，进行应用的部署或升级。
[0172]
a10、升级后，运维人员使用rancher的监控、告警、通知等功能监控应用的运行。
[0173]
基于与上述方法的同一构思，如图2所示，提供了一种kubernetes集群的应用部署的装置200。装置200能够执行上述方法中的各个步骤，为了避免重复，此处不再详述。装置200包括：获取单元201、生成单元202、推送单元203、处理单元204。
[0174]
kubernetes集群的应用部署装置200包括：
[0175]
处理单元204，用于通过kubernetes集群中jenkins主节点调用jenkins主节点镜像在所述jenkins主节点部署第一jenkins服务；
[0176]
所述处理单元204，还用于通过所述第一jenkins服务向jenkins工作节点触发在jenkins工作节点部署第二jenkins服务的指令；
[0177]
所述处理单元204，还用于通过所述jenkins工作节点调用所述jenkins工作节点镜像在所述jenkins主节点部署第二jenkins服务；
[0178]
获取单元201，用于通过所述jenkins工作节点的第二jenkin服务从源码仓库获取应用的源代码；
[0179]
生成单元202，用于根据所述应用的源代码生成所述应用的docker镜像；
[0180]
所述处理单元204，还用于通过所述jenkins工作节点的所述第二jenkins服务调用所述应用的docker镜像，以在所述第二jenkins服务部署所述应用。
[0181]
在一种可能的实现方式中，所述处理单元204，在向jenkins工作节点触发在jenkins工作节点部署第二jenkins服务的指令时，具体用于：在监控到所述源码仓库存在所述应用的源代码更新时，通过所述第一jenkins服务向jenkins工作节点触发在jenkins工作节点部署第二jenkins服务的指令。
[0182]
在一种可能的实现方式中，所述处理单元204，在向jenkins工作节点触发在jenkins工作节点部署第二jenkins服务的指令时，具体用于：在监控到所述源码仓库增加所述应用源代码时，通过所述第一jenkins服务向jenkins工作节点触发在jenkins工作节点部署第二jenkins服务的指令。
[0183]
在一种可能的实现方式中，所述生成单元202，还用于通过第一dockerfile文件创建jenkins主节点镜像；
[0184]
推送单元203，用于将所述jenkins主节点镜像推送到镜像仓库中；
[0185]
所述处理单元204，具体用于通过kubernetes集群中jenkins主节点从镜像仓库中调用jenkins主节点镜像在所述jenkins主节点部署第一jenkins服务。
[0186]
在一种可能的实现方式中，所述生成单元202，还用于通过第二dockerfile文件创建jenkins工作节点镜像；
[0187]
推送单元203，用于将所述jenkins工作节点镜像推送到镜像仓库中；
[0188]
所述处理单元204，具体用于通过jenkins工作节点从镜像仓库中调用jenkins工作节点镜像在所述jenkins工作节点部署第二jenkins服务。
[0189]
在一种可能的实现方式中，所述生成单元202，还用于在所述第二jenkins服务部署所述应用之前，通过第三dockerfile文件创建tomcat镜像，所述tomcat镜像用于保证应用可以在kubernetes集群环境中正常运行；
[0190]
推送单元203，用于将所述tomcat节点镜像推送到镜像仓库中；
[0191]
所述处理单元204，还用于通过所述jenkins工作节点调用所述jenkins工作节点镜像在所述jenkins主节点部署第二jenkins服务之后，通过所述jenkins工作节点从所述镜像仓库中拉取所述tomcat镜像在所述jenkins工作节点部署所述tomcat服务。
[0192]
图3示出了本发明实施例提供的电子设备结构示意图。该电子设备可以包括处理器301和存储器302。
[0193]
进一步地，电子设备还可以包括通信接口303。
[0194]
处理器301可以是通用处理器，例如中央处理器(cpu)、数字信号处理器(digital signal processor，dsp)、专用集成电路(application specific integrated circuit，asic)、现场可编程门阵列(field programmable gate array，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件，可以实现或者执行本技术实施例中公开
的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本技术实施例所公开的集群部署方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。
[0195]
存储器302作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块。存储器可以包括至少一种类型的存储介质，例如可以包括闪存、硬盘、多媒体卡、卡型存储器、随机访问存储器(random access memory，ram)、静态随机访问存储器(static random access memory，sram)、可编程只读存储器(programmable read only memory，prom)、只读存储器(read only memory，rom)、带电可擦除可编程只读存储器(electrically erasable programmable read-only memory，eeprom)、磁性存储器、磁盘、光盘等等。存储器是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。本技术实施例中的存储器302还可以是电路或者其它任意能够实现存储功能的装置，用于存储程序指令和/或数据。
[0196]
本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；上述计算机存储介质可以是计算机能够存取的任何可用介质或数据存储设备，包括但不限于：移动存储设备、随机存取存储器(ram，random access memory)、磁性存储器(例如软盘、硬盘、磁带、磁光盘(mo)等)、光学存储器(例如cd、dvd、bd、hvd等)、以及半导体存储器(例如rom、eprom、eeprom、非易失性存储器(nand flash)、固态硬盘(ssd))等各种可以存储程序代码的介质。
[0197]
或者，本技术上述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本技术各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、随机存取存储器(ram，random access memory)、磁性存储器(例如软盘、硬盘、磁带、磁光盘(mo)等)、光学存储器(例如cd、dvd、bd、hvd等)、以及半导体存储器(例如rom、eprom、eeprom、非易失性存储器(nand flash)、固态硬盘(ssd))等各种可以存储程序代码的介质。
[0198]
以上实施例仅用以对本技术的技术方案进行了详细介绍，但以上实施例的说明只是用于帮助理解本技术实施例的方法，不应理解为对本技术实施例的限制。本技术领域的技术人员可轻易想到的变化或替换，都应涵盖在本技术实施例的保护范围之内。