DevOps实战系列【第五章】:基于Gitlab/Maven/Jenkins/Docker实战案例详解

个人亲自录制全套DevOps系列实战教程手把手教你玩转DevOps全栈技术

在这里插入图片描述

从创建Jenkins的job开始

1.gitlab设置:

我们从新建一个jenkins任务开始,建一个自由风格项目,我们暂时只让他能拉取git的代码。

路径:从gitlab上新建一个工程demo -> Idea创建Springboot项目demo,并提交至gitlab -> jenkins中指定拉取的仓库和鉴权信息。
在这里插入图片描述
因为我的仓库是private,所以需要输入用户名、密码才可以,从Credentials选项添加即可(也可通过”凭证“功能单独添加)。点击构建进行测试,如果输出如下内容表示git配置成功。
在这里插入图片描述

2.maven设置:

其实之前讲的”全局“配置中已经对maven做了配置,在jenkins的job中只需引用即可,并添加自己的构建命令。

路径:找到job的”构建“节点,然后选择之前配置的maven,在”目标“中指定构建命令,如:-DskipTests=true clean install
在这里插入图片描述
再次点击构建,我们发现log中是成功的,并在构建到目录:/var/jenkins_home/workspace/test/target/demo-0.0.1-SNAPSHOT.jar

注意:第一次构建时会比较慢,因为会去中心仓库下载大量的依赖到本地私服(可以到nexus中查看)并且下载到jenkins本地(maven客户端),之后再次构建将会直接使用jenkins本地的依赖,就会很快了。

优化:我们发现打包后的jar包名字不太好记,这个是maven的设置,只需在springboot工程的pom.xml中增加<build>标签:通过fileName指定即可

<build>
   <! -- 打包后的jar包为:demo.jar -- >
   <finalName>demo</finalName>
   <plugins>
     <! -- springboot专用构建插件,如果不配置,打出来的jar包,通过java -jar不能找到main方法 -- >
       <plugin>
           <groupId>org.springframework.boot</groupId>
           <artifactId>spring-boot-maven-plugin</artifactId>
       </plugin>
   </plugins>
</build>
3.ssh发布:

这里我们先使用【最简单的ssh命令方法来】发布服务,后边会讲解pipeline流水线的发布方法。

根据流程我们已经完成了git项目的拉取、maven的构建打包,最后就是将打包后的springboot部署到docker容器并运行。

我们知道运行docker之前要先有镜像,而因为我们需要的是包含springboot jar包的镜像,所以我们只能先构建这么一个镜像,然后再运行镜像。

此处我们暂时不介入docker仓库,而是直接在docker本地构建镜像后启动运行容器
需要做的事情:

  • 将构建的jar包拷贝到宿主机指定目录(如:/share/jenkins/demo)
  • 在springboot工程创建Dockerfile文件,用于构建镜像(放到宿主机存放jar包所在目录)
  • 在springboot工程创建docker-compose.yml文件,用于启动容器(放到宿主机存放jar包所在目录)
  • 在jenkins构建后执行的脚本(可以写入脚本文件),执行内容主要目的就是运行docker-compose up -d来启动容器。


操作路径:”构建后操作“ -> ”Send build artifacts over SSH“
在这里插入图片描述
如上配置,打包后会将jar包通过ssh发布到宿主机的/share/jenkins/demo/target/demo.jar目录,/share/jenkins是我们在系统设置中设置ssh时指定的目录,

/demo则是"Remote directory"属性的含义,target/demo.jar则是匹配"Source files"属性。

虽然不会将springboot的docker目录打包,但已经通过git拉取到了jenkins的目录,所以此处可以将docker目录一起发布到ssh远程目录,

这样我们就可以通过ssh脚本来执行构建并运行容器了。

问题:如上配置,经过多次对demo构建后,虽然镜像和容器都是最新构建和部署的,但是会产生多个镜像名为none的镜像,这是因为我们每次都会构建新镜像,而原有镜像没有删除,此时docker会更名他们为none,所以我们对脚本进行优化,就是构建前先把老镜像删除,因为我们每次都是重新打jar包,所以镜像也不会相同,所以老镜像直接删除即可。
在这里插入图片描述

# docker-compose down 停止容器并删除镜像,这个也不太合适,因为构建起见容器不可用,虽然k8s可以热部署,但这里我们也不希望让服务不可用时间过长

set -e \
&& cd /share/jenkins/demo/docker \
&& mv ../target/demo.jar . \
&& docker-compose up -d --build \
&& docker image prune -f
# 好处:这样操作容器的不可服务时间会很短,因为没有停掉原有容器的操作,这样在构建期间将会临时创建新容器,构建完成后替换掉原有容器。

悬空镜像:就是新构建的镜像替换了原有镜像的标签,而原有镜像的标签将会变成none,这些镜像docker并不会自动删除,我们可以通过命令查出这样的镜像手动删除

# 查找悬空镜像命令:
docker images -f "dangling=true" -q

# 删除悬空镜像命令:
docker image prune  
# 也可以,其中-f是不需要确认
docker rmi $(docker images -f "dangling=true" -q) 

官网参考:
https://docs.docker.com/engine/reference/commandline/image_prune/

4.Springboot:工程名为demo

在这里插入图片描述
Dockerfile文件:我没找到合适的java 1.8版本的镜像,所以这里选择基于centos7构建了带有jdk8和jar包的镜像,如果大家自己能找到合适的镜像自行替换就行,

只要保障有java环境即可,我这个构建完后有800M+,如果希望轻量级也可以基于alpine内核来构建。

FROM centos:centos7
LABEL maintainer="xxx@126.com"
USER root
COPY * /docker/
WORKDIR /usr/local
RUN set -e \
   && cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime \
   && echo 'Asia/Shanghai' > /etc/timezone \
   && chmod 755 /docker/* \
   && mv -f /docker/jdk-8u181-linux-x64.tar.gz ./ \
   && tar -zxf jdk-8u181-linux-x64.tar.gz \
   && rm -f jdk-8u181-linux-x64.tar.gz \
   && echo "jdk install is complete!" \
   && echo "try to run server ..." \
   && mkdir packages \
   && mv -f /docker/*.jar ./packages
ENV JAVA_HOME /usr/local/jdk1.8.0_181
ENV CLASSPATH .:$JAVA_HOME/lib
ENV PATH $JAVA_HOME/bin:$PATH
# 暴露端口
EXPOSE 8080
# 执行脚本
ENTRYPOINT ["java","-jar","/usr/local/packages/demo.jar"]

当然也可以基于openjdk来构建:【更简单】

FROM openjdk:8u181-jdk
LABEL maintainer="xxx@126.com"
COPY * /usr/local/packages
# 暴露端口
EXPOSE 8080
# 执行脚本
ENTRYPOINT ["java","-jar","/usr/local/packages/demo.jar"]

docker-compose.yml文件:

version: '3'
services:
 demo:
   build:
     context: .
     dockerfile: Dockerfile
   image: 'lij/centos:java8u181-centos7'
   restart: always
   container_name: 'demo'
   hostname: 'demo'
   ports:
     - '9099:8080'
   networks:
     - 'exist-net-bloom'
   volumes:
     # - '/data/logs:/data/logs' # 用来映射微服务日志
     - '/etc/timezone:/etc/timezone:ro'
     - '/etc/localtime:/etc/localtime:ro'
networks:
 exist-net-bloom:
   external:
     name: devops

增加git parameter构建

通过指定git的分支、标签等进行构建,该方式为jenkins的一个插件,通过插件管理安装git-parameter即可,也可手动离线安装:

源码地址:https://github.com/jenkinsci/git-parameter-plugin,可自行构建后离线安装,直接将jpi文件放入Jenkins的home目录的plugins文件夹下

官方插件地址:http://mirror.xmission.com/jenkins/plugins/git-parameter,可直接下载hpi文件离线安装

配置方式:
General -> “参数化构建过程” -> “Git参数”

在这里插入图片描述
配置完后保存,在job面板会多出一个"Build With Parameters",点击进入即可选择对应的标签或分支。
在这里插入图片描述

遇到的第一个坑:我是通过jenkins的插件管理,自动安装的最新版git-parameter插件,为0.9.18,而这个版本配置完“参数化构建”后出现无法拉取tag和branch的现象。
在这里插入图片描述
解决方法:以上问题并未发现明显的报错日志,因为毕竟最新版插件可能存在兼容问题,于是逐个更换旧版本插件,知道更换到0.9.15版本才正常。

插件下载地址:http://mirror.xmission.com/jenkins/plugins/git-parameter/0.9.15/git-parameter.hpi

离线安装:将插件下载后采用上传离线安装即可,“系统管理”->“插件管理”->“高级”->“Deploy Plugin”
在这里插入图片描述
在这里插入图片描述
安装完成后记得重启,在进入就没问题了。

第二个坑:按照上边配置完后,选择合适的参数构建,但发现拉取的git代码并不是指定的分支,而是仍然为默认分支的代码?

我们需要在jenkins拉取代码构建之前先"手动切换"到选中的分支或标签。
在这里插入图片描述
配置完后再进行构建,结果是成功的,并且通过log日志可以看出,在Maven构建之前执行了切换分支的操作。
在这里插入图片描述

问题:从日志中看出,其实拉取的还是master分支,只是后来切换到我们选择的$branch分支,所以其实我们应该直接在git拉取时直接使用$branch,而无需通过ssh切换到$branch分支。以上配置的问题在于,如果master无更新,则不会拉取内容,则即便选择的$branch分支有更新,也不会拉到本地。
在这里插入图片描述

配置完删除执行git checkout $branch的脚本节点即可。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

上树的蜗牛儿

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值