计划和操作共享 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-machinekubernetes 执行器来执行此操作。在这种类型的配置中,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。可能的值是 warningerror。如果您打算包含此指标,请在观察时使用 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 请求并发的计数器跟踪超过数量。
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 并执行以下功能:

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