计划和操作共享 Runner 队列

本文档介绍在共享服务模型中伸缩 Runner 队列的最佳实践。

当您托管共享 Runner 队列的时候，您需要一个计划完备的基础设施用以考虑：

  • 计算空间
  • 存储空间
  • 网络带宽和吞吐
  • 作业类型（包括编程语言、OS 平台和依赖库）

使用本指南根据您组织的要求，开发极狐GitLab Runner 部署策略。

本指南不会推荐您应该使用哪些基础设施类型。 然而，它会基于在 SaaS 版本上运行 Runner 队列的经验为用户提供相关内容，每个月它会处理几百万个 CI/CD 作业。

考虑您的工作负载和环境

在部署 Runner 之前，请考虑您的工作负载和环境要求。

  • 创建您计划在极狐GitLab 上使用的团队的列表。
  • 列出编程语言、网页框架和您组织所使用的库。 例如：GoLang、C++、PHP、Java、Python、JavaScript、React 或 Node.js。
  • 预估每个团队每小时/天可能处理的 CI/CD 作业的数量。
  • 验证是否有团队拥有使用容器无法满足的构建环境要求。
  • 验证是否有团队拥有最适合为团队设置专用 Runner 的构建环境要求。
  • 预估满足预期要求所需的计算量。

您可能会选择不同的基础设施栈托管不同的 Runner 队列。 例如，您或许需要在公共云或预配置环境上部署 Runner。

Runner 队列上的 CI/CD 作业的性能与队列的环境有直接的关系。 如果您正在执行很多需要大量资源的 CI/CD 作业，我们不推荐您在共享计算平台上托管队列。

Worker、执行器和弹性伸缩能力

gitlab-runner 可执行文件运行您的 CI/CD 作业。每个 Runner都是一个独立的进程。接收请求、执行作业并根据预定义的配置进行处理。 作为一个独立进程，每个 Runner 都能创建 “子进程”（也称为 Worker）以运行作业。

并发和限制

  • 并发： 设置您在主机系统上使用所有配置的 Runner 的时候，可以并发的作业的数量。
  • 限制： 设置 Runner 创建的可以同时执行作业的子进程的数量。

弹性伸缩（例如 Docker Machine 和 Kubernetes）与不弹性伸缩的 Runner 的限制不一样。

  • 在不弹性伸缩的 Runner 上，limit 定义主机系统上的 Runner 的容量。
  • 在弹性伸缩的 Runner 上，limit 是所有您想运行的 Runner 的数量。

基础配置：一个 Runner 和一个 Worker

对于最基础的配置来说，您可以在支持的计算基础设施和操作系统上安装极狐GitLab Runner 软件。 例如，您或许会在 Ubuntu Linux 上运行 x86-64 虚拟机。

安装完成后，您只执行一次 Runner 注册，并且选择 shell 执行器。 然后编辑 Runner config.toml 文件，将并发设置为 1。 

concurrent = 1

[[runners]]
  name = "instance-level-runner-001"
  url = ""
  token = ""
  executor = "shell"

本 Runner 可以处理的极狐GitLab CI/CD 作业在安装 Runner 的主机系统上直接执行。 就像您在终端直接运行 CI/CD 作业命令一样。这种情况下，因为您仅执行了一次注册命令， config.toml 文件仅包含一个 [[runners]] 部分。假设您将并发值设置为 1，在这个系统中只有一个 Runner Worker 可以为 Runner 进程执行 CI/CD 作业。

中级配置：一个 Runner 和多个 Worker

当您这样做时，Runner 的 config.toml 文件中有多个 [[runners]] 部分。 如果所有额外的 Runner Worker 都注册使用 Shell 执行器，并且您将全局配置选项 concurrent 的值更新为 3， 此主机上可以同时运行的作业的上限为 3。 

concurrent = 3

[[runners]]
  name = "instance_level_shell_001"
  url = ""
  token = ""
  executor = "shell"

[[runners]]
  name = "instance_level_shell_002"
  url = ""
  token = ""
  executor = "shell"

[[runners]]
  name = "instance_level_shell_003"
  url = ""
  token = ""
  executor = "shell"

您可以在同一台机器上注册多个 Runner Worker，每个 Runner Worker 都是一个独立的进程。 每个 Worker 的 CI/CD 作业的性能取决于主机系统的计算能力。

弹性伸缩配置：一个或多个 Runner Manager 和多个 Worker

当极狐GitLab Runner 设置为弹性伸缩时，您可以将一个 Runner 配置为其他 Runner 的 Manager。 您可以使用 docker-machine 或 kubernetes 执行器来执行此操作。在这种类型的配置中，Runner 代理本身不执行任何 CI/CD 作业。

Docker Machine 执行器

  • Runner Manager 使用 Docker 部署按需的虚拟机实例。
  • 在这些虚拟机上，极狐GitLab Runner 使用您在 .gitlab-ci.yml 文件中指定的容器镜像执行 CI/CD 作业。
  • 您应该在各种机器类型上测试 CI/CD 作业的性能。
  • 您应该根据速度或成本优化您的计算主机。

Kubernetes 执行器

  • Runner Manager 在目标 Kubernetes 集群上部署 Pod。
  • CI/CD 作业在每个 Pod 上执行，Pod 由多个容器组成。
  • 用于执行作业的 pod 通常比托管 Runner Manager 的 Pod 需要更多的计算和内存资源。

配置实例级别的共享 Runner

在弹性伸缩配置（Runner 作为 Runner Manager）中使用实例级共享 Runner 是一种高效且有效的启动方式。

托管虚拟机或 Pod 的基础架构栈的计算容量取决于：

  • 在考虑工作负载和环境时捕获的需求。
  • 您用来托管 Runner 队列的技术栈。

运行 CI/CD 工作负载并分析一段时间内的性能之后，您或许需要调整计算能力。

对于使用实例级共享 Runner 和弹性伸缩执行器的配置，我们建议您至少从两个 Runner Manager 开始。

随着时间的推移，您可能需要的 Runner Manager 的总数取决于：

  • 托管 Runner Manager 的栈的计算资源。
  • 您为每个 Runner Manager 配置的并发。

  • 每个 Runner Manager 每小时/天/月执行的 CI/CD 作业所产生的负载。

    例如，在 SaaS 版本上，我们目前使用 Docker Machine 执行器运行七个 Runner Manager。 每个 CI/CD 作业都在 Google Cloud Platform (GCP) n1-standard-1 虚拟机中执行。使用这个配置，我们每月处理数几百万个工作。

监控 Runner

大规模操作 Runner 队列的一个重要步骤是设置和使用极狐GitLab 附带的 Runner 监控功能。

下表包含极狐GitLab Runner 指标的摘要。该列表不包括 GoLang 特定的进程指标。 要在 Runner 上查看这些指标，请按照此处中的说明执行命令。

指标名称 描述
gitlab_runner_api_request_statuses_total API 请求的总数，由 Runner、端点和状态划分。
gitlab_runner_autoscaling_machine_creation_duration_seconds 机器创建时间的直方图。
gitlab_runner_autoscaling_machine_states 提供者中每个状态的机器的数量。
gitlab_runner_concurrent 并发设置的值。
gitlab_runner_errors_total 捕获的错误数。该指标是跟踪日志行的计数器。该指标包括标签 level。可能的值是 warning 和 error。如果您打算包含此指标，请在观察时使用 rate() 或 increase()。换句话说，如果您注意到警告或错误的频率在增加，那么这可能表明存在需要进一步调查的问题。
gitlab_runner_jobs 显示当前正在执行的作业数量（标记中范围不同）。
gitlab_runner_job_duration_seconds 作业持续时间的直方图。
gitlab_runner_jobs_total 显示所有执行的作业。
gitlab_runner_limit 限制设置的当前值。
gitlab_runner_request_concurrency 新作业的并发请求的当前数量。
gitlab_runner_request_concurrency_exceeded_total 超出配置的 request_concurrency 限制的超额请求数。
gitlab_runner_version_info 由不同的构建统计字段所标记的值为常数 1 的指标。
process_cpu_seconds_total 总的用户和系统 CPU 时间（单位：秒）。
process_max_fds 打开文件描述符的最大数量。
process_open_fds 打开文件描述符的数量。
process_resident_memory_bytes 常驻内存大小（单位：字节）。
process_start_time_seconds 自 Unix 纪元以来，进程的开始时间（单位：秒）。
process_virtual_memory_bytes 虚拟内存大小（单位：字节）。
process_virtual_memory_max_bytes 最大可用的虚拟内存量（单位：字节）。

Grafana 仪表板配置提示

我们跟踪了 SaaS 版本的许多指标。作为基于云的 CI/CD 的大型提供商，我们需要许多不同的观点解决问题。在大多数情况下，私有化部署的 Runner 队列不需要像跟踪 SaaS 版本那样跟踪指标的数量。

以下是我们建议您用于监控 Runner 队列的一些基本仪表板。

Runner 上启动的作业：

  • 查看所选时间间隔内您的 Runner 队列上执行的全部作业的概览。
  • 查看使用趋势。您应该至少每周分析此仪表板。

您可以将此数据与其他指标相关联，例如作业持续时间，以确定您是否需要更改配置或升级容量以继续为您的内部 SLO 提供 CI/CD 作业性能服务。

作业时间：

  • 分析您的 Runner 队列的性能和规模。

Runner 容量：

  • 查看正在执行的作业数除以限制或并发的值。
  • 确定是否仍有能力执行其他作业。

在 Kubernetes 上监控 Runner 的注意事项

当您使用 Kubernetes 平台托管您的 Runner 队列时，例如 OpenShift、EKS 或 GKE，您需要一种不同的方法设置 Grafana 仪表板。

在 Kubernetes 上，您可以频繁地创建和删除 Runner CI/CD 作业执行 Pod。 在这些情况下，您应该监控 Runner Manager Pod 并执行以下功能：

  • 仪表盘：显示不同来源的相同指标的聚合。
  • 计数器：在应用 rate 或 increase 函数时重置计数器。