CI/CD 系列 | 一文让你掌握 Gitlab Runner

3,815 阅读6分钟

本系列将会从宏观角度,讲述CI/CD相关知识。系列文章不求把每一项都讲仔细,而是让大家能对CI/CD整体流程有大致的概念。无论你是前端,后端,或是运维团队,只要是CI/CD链路上的一份子,相信这系列文章对你都会有帮助。 阅读更多专栏文章

前言

在详细讲述 Gitlab CI/CD 之前,我先让大家了解一下 Gitlab Runner。 由于它的内容不少,我决定先为它单独出一篇文章。

我们从官方文档的结构可以看出,Gitlab Runner 本身并不是 Gitlab CI/CD 的一部分,但它却独占着与CI/CD 同级别的一栏菜单。由此可见 Gitlab Runner 的重要性。

总体概念

要掌握 Gitlab Runner ,大家需要先了解它的设计理念。

在 Gitlab CI/CD 中,我们把任务流程叫作流水线(pipeline) ,而 Gitlab Runner 则是负责运行流水线任务的主体,可以参考下图:

本质上,Gitlab Runner 就是一个可以提供执行脚本环境的环境,它会根据你gitlab仓库中的配置文件,来执行一连串的任务。而 Gitlab Runner 可以被安装在服务器,虚拟机,甚至是Docker容器中。

Shared Runners

在某些企业中,运维团队会默认提供一些公用 Runners ,开发者可以直接使用它们。可以在项目仓库中点击 settings—— CI/CD 看到下图所示内容:

如果你跟上图右侧所示一样 Shared Runners 栏下,有显示可用的 Runners ,那么恭喜你,你可以直接使用它们,跳过下方安装说明。当然,如果你想了解更多,也可以跟我一起往下走。

安装

如果需要手动安装 Gitlab Runner 可以参考官方文档:docs.gitlab.com/runner/inst…

如上文所说,你可以在各种平台安装runner,但需要注意的是 Gitlab Runner 本质上是自动化脚本执行工具,流水线任务的执行效率与 runner 所在的环境中的硬件性能相关。因此为了避免硬件资源的抢夺,我们不建议把 Gitlab Runner 与生产环境或者开发环境放在一起。

Runner Executors

接下来我们遇到了第二个概念—— Runner Executors

Gitlab Runner 本身只提供与 Gitlab CI/CD 通信的能力,而真正执行流水线的是其实是 Executors 。因此我们可以把图例细化:

Executor类型

既然Executor是真正脚本执行的地方,为了应对不同场景,Gitlab为我们提供了多种Executor的类型:

  • SSH
  • Shell
  • Parallels
  • VirtualBox
  • Docker
  • Docker Machine (auto-scaling)
  • Kubernetes
  • Custom

为了更好的地对比,可以参考下方表格:

类型每次运行时创建一个新环境复用上次clone过的内容runner环境下的文件访问保护可以迁移runner机器零配置支持并发构建调试构建问题
SSH容易
Shell容易
VirtualBox部分可以困难
Parallels部分可以困难
Docker中等
Kubernetes中等

怎么选?

在这么多种类型中, shell 是最简单的一种类型,你可以完全把他当作是一个普通的linux系统,但这种方式会影响runner 本身环境。如果你正在学习尝试 Gitlab Runner ,你可以用一个虚拟机安装Gitalb Runner 并直接使用shell类型executor,这样效率是最高的。 但要注意,在生产环境中一般不会用这种方式

目前普通推荐使用的是 Docker 类型,这也是目前最普遍的选择,除了避免环境污染以外,我们还可以直接使用各种docker镜像来执行流水线任务。

注册

第一次安装完 Gitlab Runner 之后,并不会产生默认的executor。为了可以让代码仓库使用我们的runner,我们需要先进行注册

具体操作很简单,只要执行下列命令即可:

# 如果你是用Docker安装的Gitlab Runner
docker run --rm -it -v /srv/gitlab-runner/config:/etc/gitlab-runner gitlab/gitlab-runner register

# 如果你是用Unix/Linux安装的Gitlab Runner
gitlab-runner register

# 如果你是用Window安装的Gitlab Runner
.\gitlab-runner.exe register

执行命令之后,会进入一个交互阶段,用于配置:

1. Enter the GitLab instance URL (for example, gitlab.com/)

输入你的gitlab地址,可以在项目仓库的 settings—— CI/CD 的runner 模块中直接复制

2. Enter the registration token:

同上,输入项目仓库的registration token。

3. Enter a description for the runner:

输入对这个runner的文字描述

4. Enter tags for the runner (comma-separated):

输入runner的tag,会与流水线任务关联。

5. Enter optional maintenance note for the runner:

输入用于维护的说明

6. Enter an executor:

选择executor的类型

Enter the default Docker image (for example, ruby:2.7):

如果第六步选择了docker,会让你输入默认的docker 镜像。在流水线任务没有注明使用其他镜像时,会使用默认镜像。

注册成功之后,就可以在项目仓库 settings—— CI/CD 看到我们的runner了。

到这里我们的Gitlab Runner就可以正常使用了!

配置

当然,我们还可以随时修改Gitlab Runner的配置(包括在注册时输入的配置)。所有配置项都在 config.toml 文件里。

  • Unix/Linux系统可以在etc/gitlab-runner/ 或者 ~/.gitlab-runner 中找到。
  • 其他操作系统可以在 ./ 找到。

下方是一个简单的 config.toml 例子:

# 全局配置
# 可以并发运行的最大任务数量
concurrent = 1
# 任务直接的间隔时间(单位:秒)
check_interval = 0

# session_server配置
[session_server]
	# 任务结束之后runner处于活跃状态的时间(单位:秒)
  session_timeout = 1800

# 我们runner的配置,大部分是注册时输入的
[[runners]]
  name = "local test"
  url = "https://xxxxxxxxx"
  token = "xxxxxxxxxxxxxxxxx"
  executor = "docker"
  [runners.custom_build_dir]
  [runners.cache]
    [runners.cache.s3]
    [runners.cache.gcs]
    [runners.cache.azure]
  [runners.docker]
    tls_verify = false
    image = "ruby:2.7"
    privileged = false
    disable_entrypoint_overwrite = false
    oom_kill_disable = false
    disable_cache = false
    volumes = ["/cache"]
    shm_size = 0

想要了解更多的配置,可以参考:docs.gitlab.com/runner/conf…

总结

今天我们了解的 Gitlab CI/CD 中负责执行脚本的 Gitlab Runner 的设计结构,描述了Executor 的类型与选择方案,并掌握了它的安装,注册流程。最好我们还提到了进一步配置 runner 的方法。

本文的重点在于对Gitlab Runner 的展开描述,让大家对此有一个具体的概念。而它具体是如何与 Gitlab CI/CD 结合,实现自动化流水线的说明,我会在下一篇文章《CI/CD系列 | 一步上手Gitlab CI/CD》中详细讲述。

进一步阅读

Gitlab Runner 官方文档:docs.gitlab.com/runner/

如果你觉得本文对你有一点帮助,麻烦给我点个赞吧~~ 谢谢