个人亲自录制全套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="[email protected]"
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="[email protected]"
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",点击进入即可选择对应的标签或分支。
标签:实战,demo,Gitlab,jar,DevOps,构建,jenkins,镜像,docker From: https://blog.51cto.com/u_15909716/5996659
遇到的第一个坑:
我是通过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的脚本节点即可。