GitLab CI构建SpringBoot-2.3应用
2020-06-26
加入收藏
欢迎访问我的GitHub
https://github.com/zq2599/blog_demos
内容：所有原创文章分类和汇总，及配套源码，涉及JAVA、Docker、Kubernetes、DevOPS等；
关于GitLab CI
在《体验SpringBoot(2.3)应用制作Docker镜像(官方方案)》一文中，咱们掌握了SpringBoot官方推荐的镜像构建方案，接下来要体验的是GitLab的CI能力，它负责把代码变成私有仓库中的镜像，咱们可以专心编码了；
GitLab CI的作用如下图，开发者提交代码到GitLab后，就会触发编译、构建、制作镜像、推送到仓库这些事情，然后K8S环境就能用上最新的镜像了：
本文内容
本文继续坚持实战的风格，和大家一起完成以下操作：
- 准备一个SpringBoot-2.3应用；
- 编写GitLab的pipeline脚本；
- 提交代码触发pipeline脚本的工作；
- K8S环境使用最新镜像；
- 体验GitLab如何将最新镜像自动部署到K8S环境；
环境信息
- GitLab：Community Edition 13.0.6
- GilLab Runner：13.1.0
- kubernetes：1.15.3
- SpringBoot：2.3.0.RELEASE
- JDK：1.8.0_121
- Maven：3.3.9
- Docker：19.03.8
- 操作系统：centos linux release 7.8.2003
准备
实战前需要您准备好以下环境：
- GitLab，参考《群晖DS218+部署GitLab》
- 私有镜像仓库，参考《群晖DS218+部署Harbor(1.10.3)》
- GitLab Runner，参考《GitLab Runner部署(kubernetes环境)》
- Kubernetes
SpringBoot应用源码
本次实战用的是普通的SpringBoot工程，如果您不想写代码，整个系列的源码可在GitHub下载到，地址和链接信息如下表所示(
https://github.com/zq2599/blog_demos)：
这个git项目中有多个文件夹，本章的应用在dockerlayerdemo文件夹下，如下图红框所示：
实战操作
- 创建名为dockerlayerdemo的SpringBoot项目，SpringBoot版本号为2.3.0.RELEASE，pom.xml内容如下：
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.Apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.3.0.RELEASE</version>
<relativePath/> <!-- lookup parent from repository -->
</parent>
<groupId>com.bolingcavalry</groupId>
<artifactId>dockerlayerdemo</artifactId>
<version>0.0.1-SNAPSHOT</version>
<name>dockerlayerdemo</name>
<description>Demo project for Spring Boot layer docker image</description>
<properties>
<java.version>1.8</java.version>
</properties>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
<exclusions>
<exclusion>
<groupId>org.junit.vintage</groupId>
<artifactId>junit-vintage-engine</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<version>2.3.0.RELEASE</version>
<configuration>
<layers>
<enabled>true</enabled>
</layers>
</configuration>
</plugin>
</plugins>
</build>
</project>
- java代码并非重点，在Application类中加了个http接口：
package com.bolingcavalry.dockerlayerdemo;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
import java.util.Date;
@SpringBootApplication
@RestController
public class DockerlayerdemoApplication {
public static void main(String[] args) {
SpringApplication.run(DockerlayerdemoApplication.class, args);
}
@RequestMapping(value = "/hello")
public String hello(){
return "hello " + new Date();
}
}
- pom.xml所在目录增加文件夹.m2，里面放入settings.xml，这是maven的配置文件，可以设置您的特殊的maven信息；
- pom.xml所在目录增加Dockerfile文件，用于制作镜像：
# 指定基础镜像，这是分阶段构建的前期阶段
FROM openjdk:8u212-jdk-stretch as builder
# 执行工作目录
WORKDIR application
# 配置参数
ARG JAR_FILE=target/*.jar
# 将编译构建得到的jar文件复制到镜像空间中
COPY ${JAR_FILE} application.jar
# 通过工具spring-boot-jarmode-layertools从application.jar中提取拆分后的构建结果
RUN java -Djarmode=layertools -jar application.jar extract
# 正式构建镜像
FROM openjdk:8u212-jdk-stretch
WORKDIR application
# 前一阶段从jar中提取除了多个文件，这里分别执行COPY命令复制到镜像空间中，每次COPY都是一个layer
COPY --from=builder application/dependencies/ ./
COPY --from=builder application/spring-boot-loader/ ./
COPY --from=builder application/snapshot-dependencies/ ./
COPY --from=builder application/application/ ./
ENTRYPOINT ["java", "org.springframework.boot.loader.JarLauncher"]
- pom.xml所在目录增加.gitlab-ci.yml文件，这就是CI时的pipeline脚本：
image: maven:3.6.3-jdk-8
variables:
MAVEN_CLI_OPTS: "-s .m2/settings.xml --batch-mode"
MAVEN_OPTS: "-Dmaven.repo.local=.m2/repository"
# 定义缓存
# 如果gitlab runner是shell或者docker，此缓存功能没有问题
# 如果是k8s环境，要确保已经设置了分布式文件服务作为缓存
cache:
key: dockerlayerdemo-ci-cache
paths:
- .m2/repository/
- target/*.jar
# 本次构建的阶段：build package
stages:
- package
- build
# 生产jar的job
make_jar:
image: maven:3.6.3-jdk-8
stage: package
tags:
- k8s
script:
- echo "=============== 开始编译源码，在target目录生成jar文件 ==============="
- mvn $MAVEN_CLI_OPTS clean compile package -Dmaven.test.skip=true
- echo "target文件夹" `ls target/`
# 生产镜像的job
make_image:
image: docker:latest
stage: build
tags:
- k8s
script:
- echo "从缓存中恢复的target文件夹" `ls target/`
- echo "=============== 登录Harbor ==============="
- docker login 192.168.50.43:5888 -u admin -p Harbor12345
- echo "=============== 打包Docker镜像 ： " gitlabci-java-demo:$CI_COMMIT_SHORT_SHA "==============="
- docker build -t 192.168.50.43:5888/common/gitlabci-java-demo:$CI_COMMIT_SHORT_SHA .
- echo "=============== 推送到镜像仓库 ==============="
- docker push 192.168.50.43:5888/common/gitlabci-java-demo:$CI_COMMIT_SHORT_SHA
- echo "=============== 登出 ==============="
- docker logout
- echo "清理掉本次构建的jar文件"
- rm -rf target/*.jar
关于以上pipeline脚本，有下面五点需要注意：
第一：关于cache，如果您的gitlab runner是shell或者docker类型就无需关注，cache是直接生效的，但如果您的gitlab runner是K8S那就要注意了，需要在gitlab runner中填写cache相关的配置，让分布式文件服务作为cache的底层实现；
第二：一共定义了两个stage：package和build，顺序是先package再build，注意生成jar的job一定要是package，使用jar构建镜像的job要是build，这样在构建镜像的时候才能顺利从缓存中取得jar；
第三：make_image这个job的脚本中，会执行登录私有镜像仓库的操作，为了操作方便，登录的账号密码都是直接写在脚本里面的，实际使用时请不要这样做，建议使用Harbor的机器人账号密码，并且写入GitLab CI的环境变量配置页面，而不是直接写在pipeline脚本中
第四：tags参数用来和已有的GitLab Runner匹配，请按照您自己的runner的情况设置；
第五：生成docker镜像的tag等于$CI_COMMIT_SHORT_SHA，这是本次提交的commit id，因此，每次提交都会导致镜像仓库中多一个镜像，其tag等于commit id；
- 最终整个工程的内容如下：
至此，所有开发工作已经完成，接下来验证执行情况；
验证CI
- 将所有内容提交到GitLab，如果CI环境配置OK的话会立即触发构建，下图是构建成功的效果：
- 先来看make_jar的执行情况，如下图，SpringBoot工程成功构建出jar文件：
- 再看make_image执行情况，如下图：
- 镜像制作成功后，开始推送到harbor：
- 最终完成推送，并且清理残留文件：
- 最后看看pipeline的整体情况，如下图：
- 从上图可知commit id是02307851，因此Harbor中应该有tag等于02307851的镜像，登录Harbor查看，如下图红框：
在K8S环境验证
接下来要在K8S环境验证之前的镜像可以正常运行：
- SSH登录K8S环境，执行以下命令，用最新的镜像创建deployment：
kubectl create deployment dockerlayerdemo
--image=192.168.50.43:5888/common/gitlabci-java-demo:02307851
- 执行以下命令创建NodePort类型的service：
kubectl create service nodeport
dockerlayerdemo --tcp 8080:8080
- 执行kubectl get svc查服务，如下图红框，可见容器的8080端口被映射到宿主机的31685端口：
- 浏览器访问http://192.168.50.135:31685/hello ，其中192.168.50.135是K8S宿主机的IP地址，如下图，可以正常访问SpringBoot服务：
GitLab CI的价值
文章看到这里，咱们pipeline脚本也写了，镜像有了，K8S上部署的服务也验证了，这就结束了吗？
---还没有，咱们来感受一下从修改代码到K8S环境上生效的流程：
- 修改java代码，如下图：
- 提交代码：
- 顺利生成镜像：
- 在K8S环境执行以下命令即可完成镜像更新：
kubectl set image deployment dockerlayerdemo
gitlabci-java-demo=192.168.50.43:5888/common/gitlabci-java-demo:8735c78d
- 上述命令中的gitlabci-java-demo来自kubectl describe deployment dockerlayerdemo结果中，显示的容器名称，如下图红框：
- 系统提示更新成功：
- 再次用浏览器访问相同的地址，如下图红框，修改的代码已经生效：
可见借助GitLab CI，编码到部署之间的过程已被简化，可以更加专注的撸码了；
体验CD？
除了持续集成(CI)，还可以把持续部署(CD)也加入到pipeline脚本中，这样我们只需提交代码，对应的镜像会被自动部署到K8S环境；
打开.gitlab-ci.yml，增加一个stage定义deploy，如下所示，现在一共有三个stage了：
stages:
- package
- build
- deploy
- 再在尾部增加一个job，如下所示，镜像名为ictu/sshpass:latest，该镜像内置了sshpass，可以ssh连接到K8S环境，执行kubectl set image XXX命令更新镜像，注意包裹kubectl set image命令的是双引号，这个很重要，只有用双引号时里面的$TAG才会被替换成对应的值：
# 生产镜像的job
deploy_k8s:
# 禁用cache，避免上传、下载、压缩、解压缩带来的开销
cache: {}
image: ictu/sshpass:latest
stage: deploy
tags:
- k8s
script:
- export TAG=$CI_COMMIT_SHORT_SHA
- echo "TAG is "$TAG
- sshpass -p 888888 ssh -o "StrictHostKeyChecking no" root@192.168.50.135 "kubectl set image deployment dockerlayerdemo gitlabci-java-demo=192.168.50.43:5888/common/gitlabci-java-demo:$TAG"
- 再次提醒，上面的脚本中，账号、IP和密码都应该放入GitLab的参数设置页面，而不该直接写入pipeline脚本中；
- 如下图，再次修改java文件，将hello返回结果改为abcdef：
- 打开浏览器试试，果然已经更新：
至此，CI和CD都验证通过，可见GitLab的CI能力给我们的日常开发带来了不少便利，也希望本文能给您带来一些参考；
