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.进入workspace
cd 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-classes1.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="[email protected]"
COPY mytest.jar /usr/local/
WORKDIR /usr/local
CMD java -jar mytest.jarDocker-compose.yml
version: 'v1.0.0'
services:
mytest:
build:
context: ./
dockerfile: Dockerfile
image: mytest:v1.0.0
container_name: mytest
ports:
- 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来进行发布项目