k8s springboot 文件_GitLab CI构建SpringBoot-2.3应用

欢迎访问我的GitHub

https://github.com/zq2599/blog_demos

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

关于GitLab CI

在《体验SpringBoot(2.3)应用制作Docker镜像(官方方案)》一文中,咱们掌握了SpringBoot官方推荐的镜像构建方案,接下来要体验的是GitLab的CI能力,它负责把代码变成私有仓库中的镜像,咱们可以专心编码了;

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

d755ce44e88d9e05532ea11aef772a98.png

本文内容

本文继续坚持实战的风格,和大家一起完成以下操作:

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

环境信息

GitLab:Community Edition 13.0.6GilLab Runner:13.1.0kubernetes:1.15.3SpringBoot:2.3.0.RELEASEJDK:1.8.0_121Maven:3.3.9Docker:19.03.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

SpringBoot应用源码

本次实战用的是普通的SpringBoot工程,如果您不想写代码,整个系列的源码可在GitHub下载到,地址和链接信息如下表所示(https://github.com/zq2599/blog_demos):

441230afdf2051d07ae17f3d337a1f76.png

这个git项目中有多个文件夹,本章的应用在dockerlayerdemo文件夹下,如下图红框所示:

5c26b7047c8829d3f302622c946482a2.png

实战操作

  • 创建名为dockerlayerdemo的SpringBoot项目,SpringBoot版本号为2.3.0.RELEASE,pom.xml内容如下:
<?xml version="1.0" encoding="UTF-8"?>4.0.0org.springframework.bootspring-boot-starter-parent2.3.0.RELEASEcom.bolingcavalrydockerlayerdemo0.0.1-SNAPSHOTdockerlayerdemoDemo project for Spring Boot layer docker image1.8org.springframework.bootspring-boot-starter-weborg.springframework.bootspring-boot-starter-testtestorg.junit.vintagejunit-vintage-engineorg.springframework.bootspring-boot-maven-plugin2.3.0.RELEASEtrue
  • 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@RestControllerpublic 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-stretchWORKDIR application# 前一阶段从jar中提取除了多个文件,这里分别执行COPY命令复制到镜像空间中,每次COPY都是一个layerCOPY --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-8variables:  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 packagestages:- package- build# 生产jar的jobmake_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/`# 生产镜像的jobmake_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;

  • 最终整个工程的内容如下:
ee94162dcb0456fd4c2603b34d13bbba.png

至此,所有开发工作已经完成,接下来验证执行情况;

验证CI

  • 将所有内容提交到GitLab,如果CI环境配置OK的话会立即触发构建,下图是构建成功的效果:
75dbc52bc61442672960fe87969e0609.png
  • 先来看make_jar的执行情况,如下图,SpringBoot工程成功构建出jar文件:
8358fb5b9ee72eeb5efebeeff5f61f5a.png
  • 再看make_image执行情况,如下图:
51bc544095c76061008eb4e39ba3477e.png
  • 镜像制作成功后,开始推送到harbor:
f520e325d13ffeed4305750746bb211c.png
  • 最终完成推送,并且清理残留文件:
308f2760cb71591654048ff54d15104b.png
  • 最后看看pipeline的整体情况,如下图:
bf4a2b55ef55f20d9d319093c2047729.png
  • 从上图可知commit id是02307851,因此Harbor中应该有tag等于02307851的镜像,登录Harbor查看,如下图红框:
6b8aa91f751e69892ecfcd53e90f5ac5.png

在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端口:
ddd27a459d67be43b3568e7ba4bc0cc2.png
  • 浏览器访问http://192.168.50.135:31685/hello ,其中192.168.50.135是K8S宿主机的IP地址,如下图,可以正常访问SpringBoot服务:
d0eed5055cae0d9b49bf05d4c39d95ee.png

GitLab CI的价值

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

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

  • 修改java代码,如下图:
2ed8a45655c3d28731cdc8cee6236fb8.png
  • 提交代码:
96eb6166ba78e73843325d3a800ddf17.png
  • 顺利生成镜像:
11f71cf05649412f86c28cdb29e271c7.png
  • 在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结果中,显示的容器名称,如下图红框:
95932057517892354d38dc4934afa2d6.png
  • 系统提示更新成功:
ba649066e5becfa8a45841d7eeeac403.png
  • 再次用浏览器访问相同的地址,如下图红框,修改的代码已经生效:
59e96c7a9c2a655159b002148ec120ab.png

可见借助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才会被替换成对应的值:
# 生产镜像的jobdeploy_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
d04a9e8a722315a38c2767253ee3d0fa.png
  • 打开浏览器试试,果然已经更新:
2ab811dbfb0bae0fab3f1d65cbe8954c.png

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

欢迎关注我的公众号:程序员欣宸

8ad04b77931a98a06902ab205af38cea.png
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值