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-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="fooleryang@139.com"
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: 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来进行发布项目