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-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="[email protected]"
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来进行发布项目 

猜你喜欢

转载自blog.csdn.net/hey_lie/article/details/132105003