欢送拜访我的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,参考《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>文件夹下,如下图所示:
实战操作
- 创立名为<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>
- 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所在目录减少文件夹<font color="blue">.m2</font>,外面放入<font color="blue">settings.xml</font>,这是maven的配置文件,能够设置您的非凡的maven信息;
- 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-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所在目录减少<font color="blue">.gitlab-ci.yml</font>文件,这就是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是间接失效的,<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;
- 最终整个工程的内容如下:
至此,所有开发工作曾经实现,接下来验证执行状况;
验证CI
- 将所有内容提交到GitLab,如果CI环境配置OK的话会立刻触发构建,下图是构建胜利的成果:
- 先来看make_jar的执行状况,如下图,SpringBoot工程胜利构建出jar文件:
- 再看make_image执行状况,如下图:
- 镜像制作胜利后,开始推送到harbor:
- 最终实现推送,并且清理残留文件:
- 最初看看pipeline的整体状况,如下图:
- 从上图可知commit id是<font color="blue">02307851</font>,因而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
- 浏览器拜访<font color="blue">http://192.168.50.135:31685/hello</font> ,其中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
- 上述命令中的<font color="red">gitlabci-java-demo</font>来自<font color="blue">kubectl describe deployment dockerlayerdemo</font>后果中,显示的容器名称,如下图红框:
- 零碎提醒更新胜利:
- 再次用浏览器拜访雷同的地址,如下图红框,批改的代码曾经失效:
可见借助GitLab CI,编码到部署之间的过程已被简化,能够更加专一的撸码了;
体验CD?
除了继续集成(CI),还能够把继续部署(CD)也退出到pipeline脚本中,这样咱们只需提交代码,对应的镜像会被主动部署到K8S环境;
- 关上<font color="blue">.gitlab-ci.yml</font>,减少一个stage定义<font color="red">deploy</font>,如下所示,当初一共有三个stage了:
stages:- package- build- deploy
- 再在尾部减少一个<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才会被替换成对应的值:
# 生产镜像的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返回后果改为<font color="blue">abcdef</font>:
- 提交代码后,能够在CI页面察看新增job的执行过程;
- 脚本实现后,关上浏览器试试,果然曾经更新:
至此,CI和CD都验证通过,可见GitLab的CI能力给咱们的日常开发带来了不少便当,也心愿本文能给您带来一些参考;
你不孤独,欣宸原创一路相伴
- Java系列
- Spring系列
- Docker系列
- kubernetes系列
- 数据库+中间件系列
- DevOps系列
欢送关注公众号:程序员欣宸
微信搜寻「程序员欣宸」,我是欣宸,期待与您一起畅游Java世界...
https://github.com/zq2599/blog_demos