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",点击进入即可选择对应的标签或分支。

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

遇到的第一个坑：我是通过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的脚本节点即可。