jenkins的cicd操作

cicd概念

持续集成（ Continuous Integration）

持续频繁的（每天多次）将本地代码“集成”到主干分支，并保证主干分支可用

持续交付（Continuous Delivery）

是持续集成的下一步，持续频繁地将软件的新版本交付到类生产环境（类似于预发），交付给测试、产品验收。
持续交付强调的是“交付”，不管怎么更新，软件是随时随地可以交付的，相比持续集成，持续交付除了交付到类生产环境之外，还会执行一些集成测试、API测试等等，确保交付的产物可以直接交付部署

持续部署（Continuous Deployment）

是持续交付的下一步，“自动”将代码部署到生产环境

持续部署强调的是“部署”，它的目标是，代码在任何时刻都是可部署的，可以进入生产阶段。

持续部署和持续交付触发方式的区别是，持续部署是自动完成的，持续交付是手动完成的

1 jenkins CICD操作

前提：

gitlab安装，并创建了一个项目，gitlab安装了相应插件，参见上一篇文章 

说明：

下面步骤为一步一步进行，确保每一步都没有问题后进行下一步操作，从而得到一个比较完整的jenkinscicd操作，为后续使用jenkins pipeline项目奠定基础

项目以一个简单的springboot项目为基础，进行操作

目前操作仅为jenkins操作，未接入到k8s中，接入操作在jenkins pipeline项目时进行

1.1 jenkins拉取gitlab代码

步骤

先在jenkins中创建一个自由风格的项目

 

 

在源码管理中添加git，远程仓库名称和登陆凭证

 点击立即构建

 验证是否拉取成功

可以查看控制台输出日志

也可以进入jenkisn服务器中查看是否拉取到代码，操作如下：

进入服务器【jenkins安装的服务器】，进入容器查看【拉取的本地项目都会存放到当前用户目录的workspace目录下】

 # 1.进入容器sudo docker exec -it jenkins bash# 2.进入用户目录cd ~# 3.进入workspacecd workspace/# 4.查看项目是否已经拉去到本地
jenkins@fe5b68bad9e1:~/workspace$ cd test
jenkins@fe5b68bad9e1:~/workspace/test$ ls
pom.xml  src

发现拉取到gitlab的代码，说明该项测试没有问题

1.2 调用maven打包 

再次进入项目管理，在build steps中增加构建步骤，选择调用顶层maven目标

 

选择之前添加的maven

命令为clean package -DskipTests 打包并跳过测试

 点击立即构建 

构建完成后，进入服务器查看是否有jar包

jenkins@fe5b68bad9e1:~/workspace$ cd test
jenkins@fe5b68bad9e1:~/workspace/test$ ls
pom.xml  src  target
jenkins@fe5b68bad9e1:~/workspace/test$ cd target/
jenkins@fe5b68bad9e1:~/workspace/test/target$ ls
classes		   generated-test-sources  maven-status		    test-0.0.1-SNAPSHOT.jar.original
generated-sources  maven-archiver	   test-0.0.1-SNAPSHOT.jar  test-classes

1.3 将jar包发送到目标服务器

编辑项目配置

选择构建后操作

添加send build artifacts over ssh

选择之前配置的ssh

将target/的jar包发送到目标服务器

ssh server为上一篇中jenkisn安装插件后配置

transfers中source files为jenkisn中target目录下所有jar文件

 选择构建后在目标服务器中查看

[root@k8s-master target]# pwd
/usr/local/k8s/target
[root@k8s-master target]# ls
test-0.0.1-SNAPSHOT.jar

发现已经发送过来该jar文件

1.4 将jar构建docker镜像

在代码中添加dockerfile和docker-compose.yml

Dockerfile

FROM eclipse-temurin:8-jre
LABEL org.opencontainers.image.authors="[e-mail]"
COPY mytest.jar /usr/local/
WORKDIR /usr/local
CMD java -jar mytest.jar

Docker-compose.yml

version: 'v1.0.0'
services:mytest:build:context: ./dockerfile: Dockerfileimage: mytest:v1.0.0container_name: mytestports:- 8080:8080

在pom.xml中添加固定名称，让其打包后固定名称为mytest 

jenkins中项目配置中构建后配置添加

在jenkins项目配置中增加命令 

命令为将target目录下的jar文件复制到docker目录下【保存dockerfile文件目录，在源码中创建】，再执行构建

在目标服务器上查看 

[root@k8s-master docker]# docker images |grep test
mytest                                                                        v1.0.0              5178b6e1eab7   12 minutes ago   239MB
[root@k8s-master docker]# docker ps |grep test
f8f5be867460   mytest:v1.0.0                                       "/bin/sh -c 'java -j…"   12 minutes ago   Up 12 minutes   0.0.0.0:8080->8080/tcp, :::8080->8080/tcp   mytest

发现已经运行了镜像

访问

 1.5 修改代码，重新发布

修改代码，将返回信息为 版本为1.0.2

 提交代码到gitlab，jenkins重新进行构建

构建完成后访问

1.6 参数化构建 

修改代码，将版本输出为v2.0.0

 

修改docker-compose.yml 

将image设置为v2.0.0，version也设置为v2.0.0

 上传代码到gitlab，并打上标签为v2.0.0

jenkins中当前任务中进行配置

在general中选择参数化构建过程

选择git 参数【之前下载的Git paremeter插件】

 

名称为tag【自定义，但后续需要使用】

参数类型选择标签 

默认值选择main分支

 在build setp中添加咨询shell操作

 

添加切换分支命令

并移动该步骤到第一步 $tag可以获取到parameters中配置的参数tag

 查看项目，发现自动拉取了gitlab的标签

 选择构建v1.0.0，输出为之前修改的v1.0.2

选择构建v2.0.0，输出为当前修改的v2.0.0

 

2 总结 

至此，jenkins拉取gitlab，并可以参数化构建代码，发布到目标机完成

但是当前操作缺点也很明显，需要docker file，每次发布标签修改修改多处内容；发布过程的操作修改进入jenkins中进行设置和修改

后续将使用pipeline项目将jenkins发布操作集成到一个Jenkins文件中，该文件在项目源码中，这样只需要修改该文件，即可完成对发布操作的修改，也不需要修改多处地方来替换tag

也将使用k8s来进行发布项目