自托管运行器的管理与监控
立即解锁
发布时间: 2025-08-25 00:32:20 阅读量: 1 订阅数: 4 


GitHub Actions实战指南:CI/CD自动化全解
# 自托管运行器的管理与监控
## 1. 自托管运行器概述
自托管运行器可在支持.NET Core、Git 和 Node 的任何环境中进行配置,安装 Docker 是可选的,但如果要运行基于 Docker 镜像的操作,则必须安装。自托管运行器通过出站 HTTPS 连接进行通信,这使得在网络中安装更加容易和安全。
自托管运行器有许多配置选项,允许用户自定义作业前后的操作。最佳的设置方式是将运行器配置为临时运行器,它将只运行一个作业,然后注销自己,不再接受任何更多的作业,这样可以清理环境并防止重大安全风险。
### 1.1 自动缩放选项
有几种自动缩放选项,其中由 GitHub 管理和支持的是 Actions Runner Controller(ARC)。ARC 可以基于时间、运行器利用率进行缩放,还可以通过配置 GitHub 中的 Webhook,在工作流作业排队时即时触发缩放。
#### 1.1.1 ARC 缩放方式
- **基于运行器忙碌百分比缩放**:根据正在执行作业的运行器百分比进行缩放,可以按可配置的运行器数量进行上下缩放。
- **按需启动新运行器**:通过监听 GitHub 在创建新拉取请求时触发的 API Webhook,按需启动新的运行器。
#### 1.1.2 ARC 支持的创建级别
ARC 解决方案支持在企业、组织和存储库级别创建运行器,提供了创建共享运行器的最大灵活性。还可以为不同的团队配置不同的扩展集,例如为团队 A 和团队 B 分别配置不同的扩展规则和容器镜像。通过 Helm 图表配置扩展集,可以将配置部署到不同的 Kubernetes 命名空间,实现更好的隔离以及网络和跨命名空间访问限制。
### 1.2 ARC 通信配置
ARC 允许使用个人访问令牌(PAT)或 GitHub 应用进行通信。由于在企业级别配置运行器时不支持 GitHub 应用,因此在该级别需要使用 PAT。对于其他级别(组织或存储库),建议使用 GitHub 应用,这样不会绑定到单个用户账户,并且可以设置一个细粒度的应用,仅用于注册运行器。使用 PAT 不被推荐,因为 PAT 可以模拟用户的所有操作,而不是对令牌的可用范围进行细粒度控制。此外,如果使用其令牌的工程师离开公司,PAT 将失效,这可能会导致配置出现问题。GitHub 应用也不会占用许可证席位,从而节省成本。
使用 GitHub 应用时,会获得一个安装 ID 和一个私钥文件(PEM 文件),可以将其作为 Kubernetes 机密提供给 ARC 控制器,用于注册和注销运行器。还可以将 GitHub 应用用作 GitHub 中可用 Webhook 的接收端,每当作业排队时触发创建运行器。每次请求新运行器时,将使用 GitHub 应用信息从 GitHub API 获取新的安装令牌,然后使用该令牌注册运行器。
### 1.3 ARC 监控
目前对操作运行器的监控非常有限,唯一可用的用户界面仅显示每个级别可用的运行器以及它们是否忙碌。可用的 API 也仅显示这些信息:哪些运行器可用、是否忙碌以及分配了哪些标签。没有方法从 ARC 中获取特定标签的可用运行器数量或当前忙碌运行器的百分比等信息。
为了进行监控,需要自行设置。可以使用 Kubernetes 监控来检查有多少 Pod 正在运行,并将其与动态缩放设置关联起来,以了解运行情况。还可以配置警报,以便在快速上下缩放时得到通知。或者,可以创建一个工作流,并使用市场上的操作(例如 https://github.com/devops-actions/load-runner-info)来获取所有可用运行器的信息,确定特定标签的可用运行器数量(如果数量低于预期则发出警报)或检查有多少运行器正在执行作业。
## 2. 管理运行器组
### 2.1 运行器组的作用
运行器组可以将运行器分割成不同的集群,并使用特定选项管理对组中运行器的访问。例如,可以为特定团队的存储库分割运行器,确保他们始终有特定数量的运行器可用;也可以确保具有特定功能(如支持 GPU 的运行器)的一组运行器仅可供某些存储库和用户使用,避免在昂贵的运行器上运行简单的代码检查作业。
### 2.2 运行器组的创建
运行器组只能在企业或组织级别创建,不能在存储库级别创建。在组织中,导航到“Settings > Actions > Runner Groups”可以找到所有运行器组的概述;在企业级别,可以在“Settings > Policies > Actions”中点击“Runner Groups”选项卡找到。默认情况下,总是有一个名为“default”的组,除非在配置过程中另有指定,否则新运行器将注册到该组。新组只能使用用户界面或 REST API 创建,示例代码如下:
```bash
curl -L \
-X POST \
-H "Accept: application/vnd.github+json" \
-H "Authorization: Bearer <YOUR-TOKEN>" \
-H "X-GitHub-Api-Version: 2022-11-28" \
https://api.github.com/orgs/ORG/actions/runner-groups \
-d '{"name":"gpu-group",
"visibility":"selected",
"selected_repository_ids":[123,456],
"restricted_to_workflows": true,
"selected_workflows":
["<ORG-NAME>/<REPONAME>/.github/workflows/<WORKFLOW>.yml@main"]
}'
```
### 2.3 运行器组的配置
在运行器组的概述中,可以看到每个组中的运行器数量以及每个组的整体设置。创建或编辑特定组时,可以配置组中的运行器是否可供所有存储库(或
0
0
复制全文
相关推荐










