当谈到 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 的时候，咱们都该聊些什么（下篇）