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

bluesGavin
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/

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

avatar
文章
阅读
粉丝