jenkins从gitlab抓代码，jenkins将项目部署到kubernetes中

来源：网络浏览：80 2022-11-08 17:37:01

上节课介绍了将Gitlab CI和Kubernetes组合起来进行CI/CD的完整过程。本课结合上述知识点提供了一个完整的示例，使用jenkinsgitlabharborhelmkubernetes实现完整的CI/CD流水线工作。

其实上节课我学到了Jenkins Pipeline和Kubernetes的完美结合。我们利用Kubernetes动态运行Jenkins Slave节点，可以和好的解决传统Jenkins Slave浪费大量资源的缺点。上一个示例将项目放在Github资源库中，并将Docker镜像推送到Docker Hub。在本课中，您将结合之前学习的知识点使用Jenkins、Gitlab、Harbor、Helm和Kubernetes来实现完整的连续集成和连续部署流水线工作。

过程

下图是当前示例的流程图

1 .开发者向Gitlab代码仓库提交代码2 .在由Gitlab组成的3. Jenkins Webhook上触发Pipeline自动构建3 .触发Jenkins构建任务，根据Pipeline脚本定义按步骤构建4 .先进行代码静态分析单元测试5 .然后maven build ( Java项目)6.根据构建结果docker mirror7) Harbor仓库中的docker mirror 确认服务是否成功更新。项目

该示例项目是基于Spring Boot、Spring Security、JWT、React和Ant Design构建的开源投票APP，项目地址为https://github.com

将部分代码添加到项目中，以执行CI/CD流程。

服务器端

首先，需要更改服务器端的配置。您需要将数据库链接的配置更改为环境变量的格式。写了的话就不能定制了。修改服务器端文件src/main/resources/application.properties，将以下数据库组成部分更改为以下格式：

spring.data source.URL=JDBC:MySQL://$ { db _ host:localhost }:$ { db _ port:3306 }/$ { db _ name:pol Li

为了将项目部署到Kubernetes群集中，需要将服务器端容器化，因此在项目根目录下添加了用于镜像构建的Dockerfile文件。

fromopenjdk:8-JDK-alpinemaintainercnychenvlangen _ us.utf-8 envlanguageen _ us:enen VLC _ Allen _ us.utf-8 enven polls-0.0.1-snapshot.jar/app/polls.jar expose 8080 entry point [ ' Java '， “- DJ ava.security .”“/app/polls.jar”服务器端代码是基于Spring Boot构建的，因此这里使用的是openjdk的基镜像打包的jar包这是Jenkins的Pipeline。这里有两种方法。

首先，如果用于镜像打包的Docker版本大于17.06，则说明墙壁已破裂，建议使用Docker的多阶段构建功能完成镜像打包过程。只需稍微修改上面的Dockerfile文件，就可以将使用maven构建的工作放入同一个文件中。

from maven:3.6-alpineasbuildcopysrc/usr/app/srccopypom.XML/usr/apprunmvn-f/usr/app/POM.xmlcleanpackage-d maven.test.skip=truefromopenjdk:8-JDK-alpinemaintainercnychenvlangen _ us.utf-8 env LAN appcopy-- from=build/usr/app/target/polls-0.0.1-snapshot.jaaps '-DJ ava.security.EGD=file:/dev '/app/polls.jar']上一个课程介绍了Docker的多阶段构建，但我们定义了两个阶段，然后将在此阶段打包并生成的jar软件包文件复制到第二阶段以进行最终镜像

第二种方式是我们的传统方式，在Jenkins Pipeline中添加了maven构建阶段，在第二个Docker构建阶段可以直接获得前面的jar包，镜像的构建工作也很容易完成。为了更清楚地说明Jenkins Pipeline的使用方法，这里采用这个方式。所以Docker

现在可以将服务器端代码推送到Gitlab上。我们仓库的地址是http://git.qik qiak.com/course/polling-app-server.git

在这里，请只注意推送的服务器端代码。

客户端

客户端必须更改API的链接位置，并更改文件src/constants/index.js中API_BASE_URL的地址。同样，通过环境变量进行区分，如果存在环境变量APISERVER_URL，则优先使用该环境变量作为API请求的地址。

letapi _ URL=' http://localhost:8080/API '； if(process.env.Apiserver_URL ) API _ URL=` $ { process.env.apiserver _ URL }/API `； } exportconstapi _ base _ URL=API _ URL；这里的项目使用的是前后分开的体系结构，所以需要单独部署前端代码。此外，由于要在Kubernetes环境中部署项目，因此必须对其进行容器化。同样，在项目根目录下添加Dockerfile文件。

from nginx:1.15.10-alpineaddbuild/usr/share/nginx.conf/etc/nginx/conf.d/default.conf

服务器{ gzip on； listen 80服务器_ name localhost； root /usr/share/nginx/html； location/{ try _ files $ uri/index.html； expires 1h； } error _ page 500502503504/50x.html； location=/50x.html { root/usr/share/nginx/html； }现在，我们将前一页打包到build目录中，将更改目录添加到nginx镜像的/usr/share/nginx/html目录中，并将其放在启动nginx镜像时直接使用的更改文件夹下

所以现在我们需要得到打包的目录build。同样，与上述服务器端项目一样，我们可以通过两种方式完成这项工作。

第一种方法当然是推荐的Docker的多阶段构建。您可以在节点镜像环境中打包前端项目，以便可以修改Dockerfile文件，打包节点，然后启动nginx。

from node:alpineasbuildworkdir/usr/src/apprunmkdir-p/usr/src/appadd./usr/src/apprunpminstall \ npmrunbuildfromnginx:1.15.10-alpinemaintainercnychcopy-- from=build/usr/src/app/build/usr/share/nginging 因为我们采用的是这种方式，所以Dockerfile文件还是用第一个就可以了。

现在可以将客户端代码推送至Gitlab。仓库地址是http://git.qik qiak.com/course/polling-app-client.git

日本火腿斗士队

项目准备好了。现在开始配置Jenkins。我记得以前在Pipeline和Kubernetes组合的过程中使用了Kubernetes的Jenkins插件，但是以前的使用方法有一些缺点。由于Jenkins Pipeline构建任务绑定到固定的Slave Pod，因此Slave Pod必须包含构建所需的一系列依赖关系，如docker、maven、node和java。因此，您需要自己定义巨大的Slave镜像。我们直接在Pipeline上用Slave Pod定制所需的容器模板。这样，所需的镜像只需在Slave Pod Template中声明即可，完全不需要定义巨大的Slave镜像。

首先，删除Jenkins kubernetes插件的Pod Template定义、Jenkins -系统管理-系统设置-云- Kubernetes区域，然后删除下面的Kubernetes Pod Template -保存

接下来，创建一个名为polling-app-server管线( Pipeline )的新任务。

接下来，您需要在此处检查触发远程构建的触发器。在那期间，令牌可以自由地写字符串。然后记住以下URL，并将JENKINS_URL替换为Jenkins地址：这里的地址是http://Jenkins.qik qiak.com/job/polling-app-soling-app-soling

然后，可以在下面的管线区域中选取Pipeline script，并在下面测试管线脚本。在此选择Pipeline script from SCM。这意味着从代码仓库中的Jenkins文件获取Pipeline script脚本定义，并选择SCM源作为Git。为了将仓库地址http://git.qikqiak.com/course/polling-app-server.git配置在显示的列表中，用一个Slave Pod构建，以SSH方式访问Gitlab代码仓库时

在Credentials区域中，单击“添加”按钮添加用于访问Gitlab的用户名和密码。

然后，需要配置用于构建的分支。如果要构建所有分支，只需将“Branch Specifier”区域留空即可。一般来说，不需要频繁构建master、develop、test等不同环境的分支。在此，您不需要频繁构建您平时开发的feature或bugfix分支

然后，在Gitlab中配置项目polling-app-server Webhook、settings - Integrations，并填写上面获得的trigger地址。

保存后，可以直接单击Test - Push Event测试是否可以成功访问Webhook地址。这里需要注意的是，您需要配置Jenkins的安全配置。否则，这里的触发器无权访问Jenkins。系统管理-全局安全配置：防止站点间伪造，并检查匿名用户是否具有读取权限。

如果测试中出现hookexecutedsuccessfully:http 201，则证明Webhook配置成功。否则，您需要验证Jenkins的安全配置是否正确。

配置成功后，只需将代码推送至Gitlab仓库即可触发Pipeline内部版本。然后，将描述管线生成过程的Jenkins文件直接添加到服务端代码仓库的根目录下。

首先，定义最简单的过程。请注意这里和前面路线的不同。在此，我们使用podTemplate来定义在各个阶段使用的容器。有什么样的阶段？

Clone代码-代码静态分析-单元测试- Maven打包- Docker镜像构建/推送- Helm更新服务。

Clone代码放在默认的Slave容器中即可；静态分析和单元测试在这里直接忽略。如果有需要这个阶段的同学，自己添加就可以了。打包Maven肯定需要Maven的集装箱； Docker镜像构建/推送是否需要Docker环境；最后的Helm更新服务不是需要有Helm的容器环境吗？因此，在这里可以很容易地定义podTemplate。定义如下。（

def label=' slave-$ { uuid.random uuid (.tostring ( ) } ' pod template ( label:label，containertemplate ):[ containte ] containertemplate(name:'docker '，image: 'docker '，command: 'cat '，tty containertemplate(name )，kubeCTL )，image command: 'cat '，ttyEnabled: true，volumes:[ hostpathvolume ] [ mount path:'/root/. m2 '，host path:'/var/] hostPath: '/root/.kube '，hostpathvolume:' ' host path:'/var/run/docker.sock ' ( ) )。 { defmyrepo=checkoutscmdefgitcommit=my repo.git _ commitdefgitbranch=my repo.git _ branch stage (单元测试) { echo测试stage ) )构建文档镜像) ) container ) ) Docker ) ) echo )构建文档镜像的阶段) }stage {container(kubeCTL ) } ) { echo ) {echo'helmrelease列表' sh 'helm list' } } }}上的groovy脚本相对简单。请注意volumes区域的定义。在主机上装载容器中的/root/.m2目录是为了在Maven内部版本中添加缓存。否则，每次构建时都必须添加一个缓存.挂载kube目录是为了使kubectl和helm这两个工具能够读取Kubernetes群集的连接信息。否则，将无法访问群集。最后一次挂载/var/run/docker.sock文件是为了让我们这个名为docker的容器能够获取Docker Daemon的信息。 docker镜像只包含客户端的二进制文件，因此必须使用宿主机上的Docker Daemon构建镜像。当然，这些volumes非常重要，因为运行Slave Pod的节点必须包含访问群集的文件，并且每个Stage阶段都需要使用特定的所需容器来编写任务

volumes:[ hostpathvolume:'/root/. m2 '，hostPath: '/var/run/m2，hostpathvolume:mount path hostpathvolume ( mot host path:'/var/run/docker.sock ' ]另一个值得注意的是label标签的定义，这样可以确保Slave Pod的名称每次都不一样。此外，这不会固定为一个Pod。如果以后有多个构建任务，则不再等待。这与前面课程中介绍的固定在label标签上不同。

然后，将上面的Jenkins文件提交到Gitlab代码仓库。

添加$ gitaddjenkinsfile $ git commit-m ' Jenkins file ' $ git push origin master以切换到Jenkins页。通常，您会看到生成的管道任务polling-app-server是触发的，然后返回Kubernetes群集时，以slave开头的Pod增加了一个。其中有五个集装箱。那是我们上面的PodTemplate定义的四个容器和默认的jenkins slave容器。同样，构建任务完成后，此pod也会自动丢弃：

$ kubectlgetpods-nku be-opsnamereadystatusrestartsagejenkins-7 fbf cc5 DDC-xs qmt1/1running 01 d slave-6e 898009-62 a2-42

没有后续了……