关于云计算:GitLab-CI构建SpringBoot23应用

5次阅读

共计 8173 个字符,预计需要花费 21 分钟才能阅读完成。

欢送拜访我的 GitHub

https://github.com/zq2599/blog_demos

内容:所有原创文章分类汇总及配套源码,波及 Java、Docker、Kubernetes、DevOPS 等;

对于 GitLab CI

在《体验 SpringBoot(2.3)利用制作 Docker 镜像(官网计划)》一文中,咱们把握了 SpringBoot 官网举荐的镜像构建计划,接下来要体验的是 GitLab 的 CI 能力,它负责把代码变成公有仓库中的镜像,咱们能够分心编码了;

GitLab CI 的作用如下图,开发者提交代码到 GitLab 后,就会触发编译、构建、制作镜像、推送到仓库这些事件,而后 K8S 环境就能用上最新的镜像了:

本文内容

本文持续保持实战的格调,和大家一起实现以下操作:

  1. 筹备一个 SpringBoot-2.3 利用;
  2. 编写 GitLab 的 pipeline 脚本;
  3. 提交代码触发 pipeline 脚本的工作;
  4. K8S 环境应用最新镜像;
  5. 体验 GitLab 如何将最新镜像主动部署到 K8S 环境;

环境信息

  1. GitLab:Community Edition 13.0.6
  2. GilLab Runner:13.1.0
  3. kubernetes:1.15.3
  4. SpringBoot:2.3.0.RELEASE
  5. JDK:1.8.0_121
  6. Maven:3.3.9
  7. Docker:19.03.8
  8. 操作系统:CentOS Linux release 7.8.2003

筹备

实战前须要您筹备好以下环境:

  1. GitLab,参考《群晖 DS218+ 部署 GitLab》
  2. 公有镜像仓库,参考《群晖 DS218+ 部署 Harbor(1.10.3)》
  3. GitLab Runner,参考《GitLab Runner 部署(kubernetes 环境)》
  4. Kubernetes,参考《kubespray2.11 装置 kubernetes1.15》

SpringBoot 利用源码

本次实战用的是一般的 SpringBoot 工程,如果您不打算写代码,也能够从 GitHub 上下载本次实战的源码,地址和链接信息如下表所示:

名称 链接 备注
我的项目主页 https://github.com/zq2599/blo… 该我的项目在 GitHub 上的主页
git 仓库地址(https) https://github.com/zq2599/blo… 该我的项目源码的仓库地址,https 协定
git 仓库地址(ssh) git@github.com:zq2599/blog_demos.git 该我的项目源码的仓库地址,ssh 协定

这个 git 我的项目中有多个文件夹,本章的利用在 <font color=”blue”>dockerlayerdemo</font> 文件夹下,如下图所示:

实战操作

  1. 创立名为 <font color=”blue”>dockerlayerdemo</font> 的 SpringBoot 我的项目,SpringBoot 版本号为 <font color=”red”>2.3.0.RELEASE</font>,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>
  1. 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();
    }
}
  1. pom.xml 所在目录减少文件夹 <font color=”blue”>.m2</font>,外面放入 <font color=”blue”>settings.xml</font>,这是 maven 的配置文件,能够设置您的非凡的 maven 信息;
  2. pom.xml 所在目录减少 <font color=”blue”>Dockerfile</font> 文件,用于制作镜像:
# 指定根底镜像,这是分阶段构建的后期阶段
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"]
  1. pom.xml 所在目录减少 <font color=”blue”>.gitlab-ci.yml</font> 文件,这就是 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 是间接失效的,<font color=”red”> 但如果您的 gitlab runner 是 K8S 那就要留神了 </font>,须要在 gitlab runner 中填写 cache 相干的配置,让分布式文件服务作为 cache 的底层实现;

第二:一共定义了两个 stage:package 和 build,程序是先 package 再 build,留神生成 jar 的 job 肯定要是 package,应用 jar 构建镜像的 job 要是 build,这样在构建镜像的时候能力顺利从缓存中获得 jar;

第三:make_image 这个 job 的脚本中,会执行登录公有镜像仓库的操作,为了操作不便,登录的账号密码都是间接写在脚本外面的,理论应用时请不要这样做,倡议应用 Harbor 的机器人账号密码,并且 <font color=”blue”> 写入 GitLab CI 的环境变量配置页面,而不是间接写在 pipeline 脚本中 </font>

第四:<font color=”blue”>tags</font> 参数用来和已有的 GitLab Runner 匹配,请依照您本人的 runner 的状况设置;

第五:生成 docker 镜像的 tag 等于 <font color=”blue”>$CI_COMMIT_SHORT_SHA</font>,这是本次提交的 commit id,因而,每次提交都会导致镜像仓库中多一个镜像,其 tag 等于 commit id;

  1. 最终整个工程的内容如下:


至此,所有开发工作曾经实现,接下来验证执行状况;

验证 CI

  1. 将所有内容提交到 GitLab,如果 CI 环境配置 OK 的话会立刻触发构建,下图是构建胜利的成果:

  1. 先来看 make_jar 的执行状况,如下图,SpringBoot 工程胜利构建出 jar 文件:

  1. 再看 make_image 执行状况,如下图:

  1. 镜像制作胜利后,开始推送到 harbor:

  1. 最终实现推送,并且清理残留文件:

  1. 最初看看 pipeline 的整体状况,如下图:

  1. 从上图可知 commit id 是 <font color=”blue”>02307851</font>,因而 Harbor 中应该有 tag 等于 02307851 的镜像,登录 Harbor 查看,如下图红框:

在 K8S 环境验证

接下来要在 K8S 环境验证之前的镜像能够失常运行:

  1. SSH 登录 K8S 环境,执行以下命令,用最新的镜像创立 deployment:
kubectl create deployment dockerlayerdemo \
--image=192.168.50.43:5888/common/gitlabci-java-demo:02307851
  1. 执行以下命令创立 NodePort 类型的 service:
kubectl create service nodeport \
dockerlayerdemo --tcp 8080:8080
  1. 浏览器拜访 <font color=”blue”>http://192.168.50.135:31685/hello</font>,其中 192.168.50.135 是 K8S 宿主机的 IP 地址,如下图,能够失常拜访 SpringBoot 服务:

GitLab CI 的价值

文章看到这里,咱们 pipeline 脚本也写了,镜像有了,K8S 上部署的服务也验证了,这就完结了吗?

— 还没有,咱们来感受一下从批改代码到 K8S 环境上失效的流程:

  1. 批改 java 代码,如下图:

  1. 提交代码:

  1. 顺利生成镜像:

  1. 在 K8S 环境执行以下命令即可实现镜像更新:
kubectl set image deployment dockerlayerdemo \
gitlabci-java-demo=192.168.50.43:5888/common/gitlabci-java-demo:8735c78d
  1. 上述命令中的 <font color=”red”>gitlabci-java-demo</font> 来自 <font color=”blue”>kubectl describe deployment dockerlayerdemo</font> 后果中,显示的容器名称,如下图红框:

  1. 零碎提醒更新胜利:

  1. 再次用浏览器拜访雷同的地址,如下图红框,批改的代码曾经失效:

可见借助 GitLab CI,编码到部署之间的过程已被简化,能够更加专一的撸码了;

体验 CD?

除了继续集成 (CI),还能够把继续部署(CD) 也退出到 pipeline 脚本中,这样咱们只需提交代码,对应的镜像会被主动部署到 K8S 环境;

  1. 关上 <font color=”blue”>.gitlab-ci.yml</font>,减少一个 stage 定义 <font color=”red”>deploy</font>,如下所示,当初一共有三个 stage 了:
stages:
- package
- build
- deploy
  1. 再在尾部减少一个 <font color=”blue”>job</font>,如下所示,镜像名为 <font color=”blue”>ictu/sshpass:latest</font>,该镜像内置了 <font color=”blue”>sshpass</font>,能够 ssh 连贯到 K8S 环境,执行 <font color=”blue”>kubectl set image XXX</font> 命令更新镜像,<font color=”red”> 留神包裹 kubectl set image 命令的是双引号 </font>,这个很重要,只有用双引号时外面的 $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"
  1. 再次揭示,下面的脚本中,账号、IP 和明码都应该放入 GitLab 的参数设置页面,而不该间接写入 pipeline 脚本中;
  2. 如下图,再次批改 java 文件,将 hello 返回后果改为 <font color=”blue”>abcdef</font>:

  1. 提交代码后,能够在 CI 页面察看新增 job 的执行过程;
  2. 脚本实现后,关上浏览器试试,果然曾经更新:

至此,CI 和 CD 都验证通过,可见 GitLab 的 CI 能力给咱们的日常开发带来了不少便当,也心愿本文能给您带来一些参考;

你不孤独,欣宸原创一路相伴

  1. Java 系列
  2. Spring 系列
  3. Docker 系列
  4. kubernetes 系列
  5. 数据库 + 中间件系列
  6. DevOps 系列

欢送关注公众号:程序员欣宸

微信搜寻「程序员欣宸」,我是欣宸,期待与您一起畅游 Java 世界 …
https://github.com/zq2599/blog_demos

正文完
 0