()一文中，咱们掌握了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. Kubernlogout - 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； 6. 最终整个工程的内容如下：  至此，所有开发工作已经完成，接下来验证执行情况； ### 验证CI 1. 将所有内容提交到GitLab，如果CI环境配置OK的话会立即触发构建，下图是构建成功的效果：  2. 先来看make_jar的执行情况，如下图，SpringBoot工程成功构建出jar文件： ![在这里插入图片描述]