第三章小试牛刀：开始使用GitLab CI/CD

本章节就正式开始配置 Gitlab CI/CD，完成一个简单示CI/CD例流程，本节目标：

了解 CI/CD 流程；
介绍并安装、注册 Runner 服务；
编写（ yml ）文件，跑完一个 Pipelines 流程；
查看 Pipeline 和 Jobs 作业状态以及运行日志详情；

3.1 CI/CD流程概述

Gitlab CI/CD 是跟项目走的，配置前需要明确知悉是哪个项目仓库需要进行 CI/CD 作业，然后在此项目的根目录 .gitlab-ci.yml 文件中编写作业流程，并且需要拥有项目的所有权限或者在项目中是 Maintainer 角色。

拥有了以上的权限后，在正式开始前，我们还需安装和注册 Runner，Runner 是具体执行作业流程的服务，等同于 Jenkis 的 Agent，不建议将 Runner 安装在同 Gitlab 服务所在同一台机子上，因为 Runner 进行 CI/CD 作业时会消耗服务器大量性能，避免拖垮 Gitlab 服务，以下是我司的 gitlab 仓库与 Runner 服务架构图：

images

解释一哈😄：

Gitlab 单独部署在一台 2vCPU 8GB 的服务器（内网IP：10.0.0.29）；
Runner 分两个组，前端组 Front、和后端组 Backend，每组内有一个或多个 Runner ，这样做有一个好处就是并行执行 CI/CD jobs 时，不会因只有一个 Runner 而阻塞；

下面以注册单个 Runner，说一下如何安装与注册的步骤。

3.2 安装 Runner

在 Gitlab 服务中创建空仓库，我这里项目名以 vue-project 为例，如下图所示：

images

通过菜单 Settings > CI/CD 查看 Runner 状态，目前看到还没有可用的 Runner，如下图所示:

images

通过①、②、③ ，找到第④步，可以看到安装 Runner 所需的链接（URL）和 Token，桥黑板，这俩值在下面注册 Runner 时会使用到请知晓，我们先安装 Runner，官方提供三种安装方式，有容器安装方式、手动下载二进制文件安装、和通过 rmp/dep 包的方式安装，这里我们使用 Docker 快速安装一个 Runner，其他安装方式请参考文档，安装命令如下：

1
2
3
4
5
# 通过 docker 快速启动一个 runner 服务：
docker run -d --name gitlab-runner --restart always \
     -v /srv/gitlab-runner/config:/etc/gitlab-runner \
     -v /var/run/docker.sock:/var/run/docker.sock \
     gitlab/gitlab-runner:latest

✋🏻 命令注解：

docker run ：没什么好说的
-d ：守护进程方式启动
–name ：为启动后的容器命名为 gitlab-runner
–restart ：启动方式 always
-v /srv/gitlab-runner/config:/etc/gitlab-runner：挂载本地目录 /srv/gitlab-runner/config 到容器 /etc/gitlab-runner 目录下；
-v /var/run/docker.sock:/var/run/docker.sock：同上意思（挂载是的文件）
gitlab/gitlab-runner:latest：容器镜像名称

重提一点是，runner 服务的配置文件被挂载到本机 /srv/gitlab-runner/config 目录下，可以通过命令：cat /srv/gitlab-runner/config/config.toml 查看，下一步注册 Runner 步骤走完，你就会明白，实际上是将配置参数写到此配置文件config.toml （提前泄露了机密）

3.3 注册 Runner

Q：在注册 Runner 服务前，我们思考一下注册 Runner 是为了什么，以及 Runner 在 CI/CD 中起着什么作用呢？

用一张图解释一下：

images

注解：

① Push，将本地代码 Push 远端 Gitlab 仓库；
② Connect，Gitlab 与 Runner 建立连接，安装与注册 Runner 即是完成这个过程；
③ Jobs，是描述 Runner 作业任务的最小单元，一个流水线（Pipelines）可包含多个 Jobs；

A：现在回答第一个问题，注册 Runner 是为了让 Gitlab 发现 Runner，让 Runner 执行CI/CD任务（干活的），目的是要打通 Gitlab 服务和 Runner 服务之间的联系。那扮演者什么作用呢？承上启下的至关重要的作用（一句废话）。

好了，接下来快速进入注册的步骤，其实就两个步两行命令 1、进入已安装的 gitlab-runner 容器；2、执行注册命令；为了假装严肃正经，所以我们还是正八经的演示一遍，

因为我们的 Runner 是跑在 Docker 容器上的，所以再执行注册命令： gitlab-runner register 前，需要先进入到容器内，否则此命令无法找到。进入到 gitlab-runner 容器，命令：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
# 通过容器名称进入 gitlab-runner 容器：
docker exec -it gitlab-runner bash

# 查看容器内 gitlab-runner 服务版本：
gitlab-runner --version
Version:      13.12.0
Git revision: 7a6612da
Git branch:   13-12-stable
GO version:   go1.13.8
Built:        2021-05-20T15:16:05+0000
OS/Arch:      linux/amd64

🌰 以下是我执行命令示意图：

接下来就可以通过 gitlab-runner register 命令进行注册了，命令gitlab-runner register，执行后有六步需要配置，结果如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
root@48dd29e1a0a0:/# gitlab-runner register
Runtime platform                                    arch=amd64 os=linux pid=29 revision=7a6612da version=13.12.0
Running in system-mode.                            
                                                   
Enter the GitLab instance URL (for example, https://gitlab.com/):
https://gitlab.xxxxxxxxxxx.com/
Enter the registration token:
MsVBXXXXXXXXXXXXEXon
Enter a description for the runner:
[48dd29e1a0a0]: ZL-Runner        
Enter tags for the runner (comma-separated):
dev
Registering runner... succeeded                     runner=MsVBENXx
Enter an executor: ssh, virtualbox, docker-ssh+machine, parallels, docker, docker-ssh, shell, docker+machine, kubernetes, custom:
docker
Enter the default Docker image (for example, ruby:2.6):
alpine:latest
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!

关键信息 URL 和 Token 我使用 xxxx 做了替换，别傻乎乎的全复制过去。

✋🏻步骤注解：

Enter the GitLab instance URL (for example, https://gitlab.com/): 输入你的Gitlab地址；
Enter the registration token: 输入你的 Token；
Enter a description for the runner: 填写描述, 无关紧要；
Enter tags for the runner (comma-separated): 填写标签, 没有标签谁都可以用, 是shared-runner（共享使用）, 有标签需要声明才可用, 一般通过 tags 将 runner 分为前端和后端，这样就不会因共享一个runner 而阻塞执行；
Enter an executor: ssh, virtualbox, docker-ssh+machine, parallels, docker, docker-ssh, shell, docker+machine, kubernetes, custom: 选择你的 executor: Docker应该是我观察到最常用；
Enter the default Docker image (for example, ruby:2.6): 选择一个默认镜像: 例如 alpine:latest 🌰 以下是我的命令示意图：
执行完成后，我们再回到查看 Runner 状态页，此时可以看到有一个名为 ZL-Runner、Tag 为 dev 且可供使用的 Runner，效果图如下：

images

截止到此，我们已经完成了 Runner 的安装与注册，

3.3 小试牛刀

在项目的根目录下创建 .gitlab-ci.yml 文件，创建完成后，点击保存提交到仓库的 master，内容如下：

 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
# 阶段
stages:
  - build
  - test
  - deploy
  
# 定义 Job
build-job:
  # 指定阶段
  stage: build
  # 指定哪个 Runner 运行当前 Job
  tags:
    - dev
  # 任务要执行的 shell 脚本，内容会被 runner 执行  
  script:
    - echo "Hello, $GITLAB_USER_LOGIN!"

test-job1:
  stage: test
  tags:
    - dev  
  script:
    - echo "This job tests something"

test-job2:
  stage: test
  tags:
    - dev
  script:
    - echo "This job tests something, but takes more time than test-job1."
    - echo "After the echo commands complete, it runs the sleep command for 20 seconds"
    - echo "which simulates a test that runs 20 seconds longer than test-job1"
    - sleep 20

deploy-prod:
  stage: deploy
  tags:
    - dev  
  script:
    - echo "This job deploys something from the $CI_COMMIT_BRANCH branch."

提交后如下图所示，可以看到如 ① 位置可看到流水线正在作业中，点击即可查看详情。

images

关键词解释： YAML 文件定义了一系列带有约束说明的 job，job 至少要包含 script。 stages 阶段，定义了 job 支持的执行阶段和顺序，其中的元素 build、test、deploy 顺序决定了对应 job 的执行顺序，下一个阶段的 Job 只会再前一个阶段的 Job 结束后执行。 stages 执行顺序：

运行所有的 build ；
如果所有作业都 build 运行成功，那么开始运行所有的 test；
如果所有作业都 test 运行成功，那么开始运行所有的 deploy；
如果所有作业都 deploy 成功，则标记 job 为 passed ；
如果在之前动作中有任何失败，则标记 job 为 failed 并终止 job 执行；

这里分别定义了四个job为：build-job、test-job1、test-job2、deploy-prod，每个 job 中又包含了 stage、tags、script，分别再解释一下这三个关键词。

stage 表示：定义当前 job 运行在那个阶段 (默认: test)；
tags 表示：指定哪个 Runner 运行此 Job，📢 注意不指定该 Job 可能不会执行；
script 表示：任务要执行的 shell 脚本，内容会被 Runner 执行；

$GITLAB_USER_LOGIN 、$CI_COMMIT_BRANCH 是 Gitlab 预定义变量，除此此外还可以自定义变量。

3.4 查看作业状态

通过点击左侧菜单栏 Pipelines，也可查看流水线（Pipeline）作业列表，如下图所示：

images

从列表可以看出，有三种不同的颜色标识，分别为 passed 成功状态，failed 失败，canceled 已取消执行，我们点击上图 ② 查看此 Pipeline 详情，如下所示：

images

可以看到此流水作业分为三个阶段（Build/Test/Deploy），共执行 4个 Jobs，我们以 ③号 Deploy 为例，查看一下此 Job 执行的详情，如下图：

images

如红色框内可详细的看到 Runner 的执行详情，相信智商180的你肯定可以看明白。

运行的 Runner，可以看到当前的 Runner 版本与名称（ZL-Runner）；
准备 Docker 镜像，yml 中没有指定，使用默认的 alpine:latest；
拉取仓库中 master 分支代码；
执行 yml 中的 script；

3.5 本章小结

本章节介绍了 CI/CD 的作业流程，以及 Gitlab 与 Runner 的关系，从安装 Runner、注册 Runner、配置 yml 文件（.gitlab-ci.yml），认识了 CI/CD 的流水线 Pipelines，每个流水线是由最小单元 Job 组成，通过编辑 YML 快速跑通了简单 Pipelines 流程，解下来，我们会先以前端为例讲解一下，我们企业前端项目中是如何使用 CI/CD 的，本章节中你有任何疑问或问题请留言。

文章目录

3.1 CI/CD流程概述

3.2 安装 Runner

3.3 注册 Runner

3.3 小试牛刀

3.4 查看作业状态

3.5 本章小结