GitLab CI/CD 自动化构建与发布实践

前端市界
713 阅读4分钟

GitLab CI是GitLab为了提升自动化，按照DevOps理念而设计的Pipeline运行流程。 和Jenkins相比，GitLab本身，就相当于Jenkins的Master。

GitLab Runner类似Jenkins的Agent（Slave），可以理解为运行Job的容器或管理者。是运行 Pipeline 构建任务的进程。

GitLab CI/CD 介绍

  • 持续集成(Continuous Integration) ：频繁地(一天多次)将代码集成到主干。让产品可以快速迭代，同时还能保持高质量。它的核心措施是，代码集成到主干之前，必须通过自动化测试。
  • 持续交付(Continuous Delivery) ：频繁地将软件的新版本，交付给质量团队或者用户，以供评审。如果评审通过，代码就进入生产阶段。持续交付可以看作持续集成的下一步。它强调的是，不管怎么更新，软件是随时随地可以交付的。
  • 持续部署(continuous Deployment) ：代码通过评审以后，自动部署到生产环境。持续部署是持续交付的下一步，持续部署的目标是，代码在任何时刻都是可部署的，可以进入生产阶段。

Gitlab CI/CD工作流程

让我们来全局性的了解Gitlab CI/CD的工作流程，如下图所示：

20200216232000.png

Gitlab CI/CD的三个阶段：

  1. 校验: 在该步骤中Gitlab 主要完成CI功能：
  • 开发人员提交代码到一个特定的分支，该分支具有Gitlab CI
  • Gitlab CI完整构建在其中有代码扫描，性能测试，单元测试，容器扫描，依赖扫描等
  • 在其中Gitlab的那个stage失败后，需要开发者去进行对应修复，直到该分支的pipeline都构建和测试正常
  1. 打包: 之后可以通过应用进行预览应用，最终将成功的进行制品管理
  • 通过Container Registry存储docker镜像
  • 通过NPM Registry存储NPM包
  • 通过Maven Repository存储Maven工件
  1. 发布: 持续部署，将通过测试和构建的分支merge 到主分支
  • 通过手动确认审批部署将应用部署进入正式环境，进行应用发布
  • 通过GitLab Pages部署静态网站
  • 进行金丝雀发布，让一定比例的用户群新功能
  • 通过GitLab Releases增加发新的记录

相关概念

  1. Job

表示构建工作，可以在一个 Stage 中定义多个 Job

Job 具有如下特点：

  • 相同 Stage 中的 Jobs 会并行执行
  • 相同 Stage 中的 Jobs 都执行成功，该 Stage 才会成功
  • 任何一个 Job 失败，那么该 Stage 失败，那么构建任务 Pipeline 也失败
  1. Stage

表示构建阶段，可以在一次 Pipeline 中定义多个 Stage

Job 运行在 Stage 中

Stage 具有如下特点：

  • 所有 Stage 按顺序运行，一个接着一个
  • 所有 Stage 完成后，构建任务才会成功
  • 任何一个 Stage 失败，后面的 Stage 都不会执行，构建任务失败
  1. Pipeline

表示构建任务

是一组运行在各个 Stage 中的 Job 集合

可以包含多个流程：编译、测试、部署等等

任何提交 或 Merge Request 都能触发 Pipeline

Job、Stage 和 Pipeline 的关系

gitlab-ci-cd-practice-2.png

利用docker来安装配置 gitlab runner...

拉取镜像：

docker pull gitlab/gitlab-runner:latest

创建 volume:

docker volume create --name gitlab_runner_config
docker volume create --name gitlab_runner_docker_sock

运行：

docker run -d --name gitlab-runner --restart always  -v gitlab_runner_config:/etc/gitlab-runner  -v gitlab_runner_docker_sock:/var/run/docker.sock gitlab/gitlab-runner:latest

image.png

GitLab Runner的三种类型

  1. 共享Runner(shared)：运行整个平台项目的作业(gitlab)
  2. 群组Runner(group)：运行特定group下的所有项目的作业(group)
  3. 项目Runner(specific)：运行指定的项目作业(project)

为项目soanrqube_react注册runner:

# 执行注册runner命令，根据提示填写信息
gitlab-runner register
Enter the GitLab instance URL (for example, https://gitlab.com/):
http://192.168.1.104:10008/
Enter the registration token:
GR1348941DKfHGyzyjm4MbwfSSNAg
Enter a description for the runner:
[AdministratordeMacBook-Pro.local]: soanrqube_react
Enter tags for the runner (comma-separated):
sonarqube_react
Enter optional maintenance note for the runner:
sonarqube_react
Registering runner... succeeded                     runner=GR1348941DKfHGyzy
Enter an executor: docker-ssh, parallels, ssh, virtualbox, docker+machine, docker-ssh+machine, instance, docker, shell, kubernetes, custom:
shell
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!
Configuration (with the authentication token) was saved in "/Users/administrator/.gitlab-runner/config.toml"

其中URL：http://192.168.1.104:10008/, token: GR1348941DKfHGyzyjm4MbwfSSNAg来自gitlab 的项目sonarqube-react下的runner 配置信息

image.png

运行未标记的作业

image.png

gitlab-ci.yml:

字段及描述参见：docs.gitlab.com/ee/ci/yaml/

.gitlab-ci.yml是用来配置CI在我们的项目中做些什么工作。它位于项目的根目录。

CI/CD 流水线举例

image.png

下图是Gitlab对阶段和阶段状态的展示：

5-22dd902da729237ee3eba85859eebdd7.png 图片来源：www.zknow.com/choerodon/b…

GitRunner 时序图：

22188-ad32a139bac93669.webp 图片来源：www.cnblogs.com/gtea/p/1627…

执行时序：

  1. 变动代码推送到GitLab上
  2. GitLab 将这个变动通知GitLab-CI
  3. GitLab-CI找出这个工程相关联的gitlab-runner
  4. gitlab-runner把代码更新到本地
  5. 根据预设置的条件配置好环境
  6. 根据预定义的脚本(一般是.gitlab-ci.yml)执行
  7. 把执行结果通知给GitLab
  8. GitLab显示最终执行的结果
avatar
文章
阅读
粉丝