计划和操作共享 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)以运行作业。
并发和限制
弹性伸缩(例如 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
函数时重置计数器。