DevOps系列文章 之 SpringBoot整合GitLab-CI实现持续集成
CI/CD属于DevOps,代表持续集成、持续交付/部署。CI/CD 自动化了传统上将新代码从提交到生产(例如构建、测试和部署)以及基础设施配置所需的大部分或全部手动人工干预。借助 CI/CD ,开发人员可以对代码进行更改,然后自动测试并推出以进行交付和部署。以实现停机时间最小化,代码发布速度更快。
在企业开发过程中,我们开发的功能或者是修复的BUG都需要部署到服务器上去,而这部分部署操作又是重复且繁琐的工作,GitLab-CI 持续集成为我们解决了这一痛点,将重复部署的工作自动化,大大的节省了程序员们的宝贵时间。本文详细讲述了 GitLab-CI 持续集成的安装、部署、以及配置。
文中的工具包有需要的话也可以私信博主哟~
一、概述

1.1、什么是CI/CD
CI/CD 属于 DevOps,代表持续集成、持续交付/部署。CI/CD 自动化了传统上将新代码从提交到生产(例如构建、测试和部署)以及基础设施配置所需的大部分或全部手动人工干预。借助 CI/CD ,开发人员可以对代码进行更改,然后自动测试并推出以进行交付和部署。以实现停机时间最小化,代码发布速度更快。
1.2、持续集成(CI)
持续集成是在提交或合并代码时,自动测试每个更改,并自动启动构建。可以大大减少开发和运维人员的重复工作,可以在软件开发生命周期的更早阶段更轻松的发现并修复错误和安全问题。
1.3、持续交付(CD)
持续交付是一种软件开发实践,一般与持续集成结合使用,以自动化基础设置供应和应用程序发布过程。
一旦代码作为 CI 流程的一部分进行了测试和构建,持续交付将在最后阶段接管,以确保可以随时部署并将部署所需要的环境打包在一起。
通过持续交付,可以随时将构建的软件部署到生产环境。可以手动触发部署,也可以进行自动化部署。
二、CI/CD流水线
2.1、Pipeline

Pipeline 相当于构建任务,里面可以包含多个流程,如安装依赖、运行测试、编译、部署测试服务器、部署生产服务器等流程。
任何提交或合并代码都可以触发 Pipeline。
2.2、Stages

Stages 表示构建阶段,可以在一次 Pipeline 中定义多个 Stages。
Stages 有以下特点:
- 所有 Stages 会按照顺序运行,即当一个 Stage 完成后,下一个 Stage 才会开始
- 只有当所有 Stages 完成后,该构建任务 (Pipeline) 才会成功
- 如果任何一个 Stage 失败,那么后面的 Stages 不会执行,该构建任务 (Pipeline) 失败
2.3、Jobs

Jobs 表示构建工作,表示某个 Stage 里面执行的工作。可以在 Stages 里面定义多个 Jobs。
Jobs 有以下特点:
- 相同 Stage 中的 Jobs 会并行执行
- 相同 Stage 中的 Jobs 都执行成功时,该 Stage 才会成功
- 如果任何一个 Job 失败,那么该 Stage 失败,即该构建任务 (Pipeline) 失败
2.4、Runners
Runner 是一个在 GitLab CI/CD 管道中运行作业的应用程序。简而言之,就是由 Runner 来执行这些构建任务。
GitLab Runner 可以安装到不同的机器上,也可以在容器或 Kubernetes 集群中运行。Runner 在安装机器上处理作业,在构建任务运行期间并不会影响到 GitLab 的性能。
三、安装GitLab Runner
3.1、环境准备
创建目录
|
1 |
|
|
1 |
|
下载 jdk-8u341-linux-x64.tar.gz、apache-maven-3.5.3-bin.tar.gz、settings.xml、docker-compose,并将其上传至 environment 目录
|
1 2 3 4 5 6 7 8 |
|
settings.xml 中增加了 maven 部署的 server 节点,否则项目 deploy 时会失败
3.2、创建Dockerfile
在environment目录下创建 daemon.json
|
1 |
|
内容如下:
|
1 2 3 4 5 6 7 8 |
|
registry-mirrors:为镜像加速地址,这里是使用的腾讯云的镜像加速地址。insecure-registries:Docker仓库的IP。
注意:需要提前搭建Docker 私服(Docker Registry)
在environment目录下创建 Dockerfile
|
1 |
|
内容如下:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 |
|
3.3、创建docker-compose
在runner目录下创建 docker-compose.yml
|
1 |
|
内容如下:
|
1 2 3 4 5 6 7 8 9 10 |
|
构建启动
|
1 |
|
启动后,会自动进行构建
3.4、注册Runner
需要将每一个项目都注册 Runner。
进入到我们需要注册Runner的项目

点击设置->CI/CD,在右侧找到Runner,点击展开

可以看到这个项目的 Runner 的详细信息,其中注册令牌是我们接下来注册 Runner 时必须要用到的

在 GitLab Runner 部署服务器上执行命令
|
1 |
|
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
|
配置完后,项目中会显示一个有效可用的 runner

3.4、项目配置
项目中需要添加一个 .gitlab-ci.yml 文件,用于定义要运行的脚本。
3.4.1、依赖管理模块
刚刚在my-project-dependencies项目中配置了 Runner,而 my-project-dependencies 项目只需要将其部署到 Nexus私服中,所以此项目的 .gitlab-ci.yml 文件脚本内容就只需要将其deploy到Nexus即可。

内容如下:
|
1 2 3 4 5 6 7 |
|
项目结构图如下:

提交my-project-dependencies项目,可以在GitLab看到我们刚刚创建的流水线

如果状态一直在运行中,在设置里面的 Runner 中,勾选运行没有标签的作业

3.4.2、通用模块
my-project-common通用模块,也需要注册Runner,这里就不重复赘述了,参考上文。
通用模块持续集成步骤:

- 清理
- 打包
.gitlab-ci.yml 文件内容如下:
|
1 2 3 4 5 6 7 |
|
提交my-project-common通用模块,可以在Nexus中看到上传的jar,持续集成成功。


3.4.3、服务模块
my-project-server项目服务模块,同样需要注册Runner。
项目服务模块持续集成步骤:

- 打包构建Docker镜像
- 推送Docker仓库
- 运行容器
- 清理虚悬镜像
.gitlab-ci.yml 文件内容如下:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
|
docker 仓库地址更改为自己的IP
提交my-project-server项目服务模块,查看构建结果

第一次最后一个步骤构建失败,是因为没有可删除的虚悬镜像,导致删除失败,这个不影响
构建成功,访问查询所有用户接口:
http://IP:8899/sys-user/get/all

可以访问Docker仓库,可以看到刚刚持续集成推送的镜像
|
1 2 |
|
到这里,项目的持续集成就完成啦!!!
更多推荐
所有评论(0)