当谈到 GitLab CI 的时候，我们该聊些什么（上篇）

“微服务”这个概念近两年非常热，正在慢慢改变 DevOps 的思路。微服务架构把一个庞大的业务系统拆解开来，每一个组件变得更加独立自治、松耦合。但是，同时也伴随着部署单元粒度越来越小，对交付效率要求也越来越高。一套高效、灵活、高可用的 CI/CD 系统就很关键。所以说 CI/CD 是微服务架构下必不可少的一部分。

这方面有很多的开源项目和工具，比如 Jenkins、Github 默认支持的 Travis 以及本文主要介绍的GitLab CI。

那么“当谈到 GitLab CI 的时候，我们都该聊些什么？”

什么是 GitLab WorkFlow

本章主要讲了 GitLab WorkFlow 从研发到发布交付的一个流程，介绍 CI/CD 所做的事情。

图1

图 1 来自 GitLab 官方文档，可以让我们更加方便的了解 CI/CD 做了哪些事情。

从左往右看，首先研发人员完成需求提交代码到 GitLab。GitLab 触发一次 Build，构建好服务，然后开始跑单元测试、集成测试。等待测试结果通过后，再由负责该项目的同事进行 CodeReview，灰度发布，正式部署到线上。CI/CD 就是指测试和发布环节，如果能够做到自动化，那么就可以大大加快开发迭代的速度。

如何配置 GitLab Runner 如何把项目接入 CI

GitLab CI 相关术语

在介绍 GitLab 之前，先介绍一下本文主要涉及到术语。

Job/Build，它是最小的任务单元，只负责一件事情，要么编译，要么测试等；
Stage，阶段，每一个 Job 都会有一个阶段，一个阶段可以包含多个 Job。阶段是有先后顺序的。通过 stage 可以间接的控制 Job 执行的先后顺序；
Pipeline，多个 Stage 有顺序的排列就是 Pipeline，流水线；
GitLab Runner，是实际处理 Job 的，每个 Runner 可以单独配置，Runner 支持多种类型的 Job，同一时间单个 runner 只能处理一个 Job；
GitLab Multi Runner，是一个 GitLab 的开源项目，用来统一管理 Runner；
Executor，每个 Runner 都需要指定一个 Executor，来决定 runner 最终使用哪个执行器进行处理。

图2

图 2 是一个典型的 Pipeline，一共有 5 个阶段，Build，Test，Release， Staging， Production，每个阶段里都至少有一个 Job，Test 中有两个 Job。GitLab 会从左往右依次把任务给到 Runner 处理，如果中途有一个任务没有处理成功的话，整个 Pipeline 就会退出。这就是持续集成（CI）、持续发布（CD）的一个流程。

如何使用 GitLab CI

注册 Runner

图3

GitLab 中提供了两种 Runner 的类型，图 3 这个界面可以在 GitLab 项目设置页中找到的，一个是特定的 Specific Runner，另一个是共享的 Shared Runner 。特定的 Runner 只能供部分项目使用，而共享的 Runner 是所有 GitLab 中的项目都可以使用的。而这两种类型的 Runner 的注册方式都是一样。

从注册一个特定的 Runner 开始讲，首先安装一个 GitLab Mutli Runner，因为是 Go 语言实现的，所以安装起来会比较简单，直接采用二进制安装即可。第二步正式开始注册，输入 Gitlab 地址、token、描述、标签执行器等。输入上述数据之后 Runner 就注册好了，由于 Multi Runner 支持动态加载配置，所以 Runner 就立即生效了。可以在刚才的界面中看到新增了一个 Runner。有了 Runner，第二步就是如何在项目中增加 .gitlab-ci.yml 的 CI 配置文件。

在项目中增加 .gitlab-ci.yml 的 CI 配置文件

图 4

上文所示是一个非常简单的 CI 配置文件。定义了两个阶段，一个 test，一个 build，先执行 test 再执行 build，test 阶段有一个 job 叫做 test，执行的指令是 echo skip，但是这个 job 需要跑在带有 opentalk 的这个标签的 runner 上。build 阶段也有一个 job，叫做 build，它会执行 make docker，去构建 docker 镜像并且推送到私有仓库中，这个任务只有当分支中有 tag 提交才会触发，并且需要跑在带有 online docker builder 的 runner 上。写好这样一个 gitlab-ci.yml 后，commit 一下提交到 Gitlab，你就可以看到 CI/CD 页面（图4）中增加一条正在跑的任务。

图 5

接下来看看 GitLab Runner 的内部实现是怎样的？

GitLab Runner 的实现细节

本章主要分析了 GitLab CI 跟 Runner 信息交互的过程。

图 6

从图 6 可以看出 GitLab CI 是这样一个结构，最上面 GitLab 服务，负责托管代码，支配分解 Job。下面几个是 GitLabMultiRunner，由于支持多操作系统环境，所以图 6 中都加了标注，每一个 GitLabMultiRunner 可以配置多个 GitLab Runner，GitLab Runner 直接跟 GitLab 做交互，这一层通信是通过 HTTP 协议实现的，之后也会讲到。另外有些同学可能已经注意到了，图中 GitLab 是部署在公网上的，而 GitLab Runner 则是在 Nat 之下的，这个设计非常友好，不需要把 GitLab Runner 跟 GitLab 部署在一起，GitLab Runner 甚至可以在自己的笔记本上。

当我们看完了 GitLab CI 的整体结构后，再看看 Runner 跟 GitLab 之间的信息交互是怎样的？

Runner 跟 GitLab 之间的信息交互是怎样的？

信息交互分为几个部分，第一个部分是 Runner 注册。

图 7

Runner 会向 GitLab 发送一个注册请求，请求内容中包含 token、 tag 等重要信息，这些其实都是之前配置的时候需要填写的， GitLab 接收一个注册请求之后就会返回一个 token 给 Runner，Runner 之后的请求中都会带上这个 token。

图 8

在收到 GitLab 注册成功的消息之后，Runner 就会不停的向 GitLab 请求 Job，时间间隔是 3s。可以看到请求中的 token 已经改成注册时 GitLab 返回的 token 了。

这时会有两种情况：

第一种是没有任务，GitLab 返回 204 No Content；

图 9

第二种情况是有任务，GitLab 会把任务信息返回回来，包括任务的 token，job_info，git_info，runner_info 等等。Runner 在接收到 Job 之后，就会向 GitLab 发送一个确认请求，同时更新任务的状态。发送完这个请求，Runner 就开始正式跑任务了。Runner 会定时的发送输出的中间数据，通过向 GitLab 发 Patch 请求的方式。

图 10

等任务处理完后，Runner 会发送最终结果、状态、日志等。

图 11

最后总结下，第一个注册 Runner，注册成功后 3s 定时请求 Job，接收到 Job 之后发送确认请求，然后开始运行任务，定时把中间结果输出给 GitLab，等任务处理完了，把结果发送给 GitLab。上述内容就是 Runner 跟 GitLab 之间的信息交互流程。

现在 Runner 已经从 GitLab 获取到了任务，下一步 Runner 是怎么做的呢，Executor 又是怎么实现？下篇《当谈到 GitLab CI 的时候，我们都在聊些什么》将会重点为大家介绍 Docker Executor 的实现细节。

更多阅读：

当谈到 GitLab CI 的时候，我们都该聊些什么（下篇）