关于自托管运行程序

你可以托管自己的运行器，并自定义用于在 GitHub Actions 工作流程中运行作业的环境。

本文内容

关于自托管运行程序

自托管运行器是你为了在 GitHub Enterprise Cloud 上执行来自 GitHub Actions 的作业而部署和管理的系统。 有关 GitHub Actions 的详细信息，请参阅“了解 GitHub Actions”和“About GitHub Actions for enterprises”。

自托管运行器比 GitHub 托管的运行器提供更多的硬件、操作系统和软件工具控制。 使用自托管运行器，可以创建自定义硬件配置，以满足处理能力或内存需求，以运行更大的作业，在本地网络上安装可用的软件，并选择 GitHub 托管的运行器未提供的操作系统。 自承载运行器可以是物理设备、虚拟设备、在容器中、在本地或在云中。

你可以在管理层次结构的各个层级添加自托管运行器：

  • 仓库级运行器专用于单个仓库。
  • 组织级运行器可以处理组织中多个仓库的作业。
  • 企业级运行器可以分配到企业帐户中的多个组织。

运行器机器使用 GitHub Actions 自托管运行器应用程序连接到 GitHub Enterprise Cloud。GitHub Actions 运行器应用程序是开源的。 可以参与 runner 存储库并在其中提交问题。 当发布新版本时，运行器应用程序在作业分配到运行器时或发布后一周内（如果运行器没有被分配任何作业）会自动更新。

自托管运行器与 GitHub Actions 未连接超过 14 天，将被自动从 GitHub Enterprise Cloud 中移除。 临时自托管运行器与 GitHub Actions 未连接超过 1 天，将被自动从 GitHub Enterprise Cloud 中删除。

有关安装和使用自托管运行器的详细信息，请参阅“添加自托管的运行器”和“在工作流中使用自托管运行程序”。

GitHub 托管运行器与自托管运行器的区别

GitHub 托管运行器使你可以更快、更简单地运行工作流，而自托管运行器具有高度可配置的特点，让你可以在自己的自定义环境中运行工作流。

GitHub 托管的运行器：

  • 接收操作系统、预安装包和工具以及自托管运行程序应用程序的自动更新。
  • 被 GitHub 管理和维护。
  • 每次执行作业时提供一个干净的实例。
  • 使用 GitHub 计划设定的免费分钟数，超过免费分钟数后按分钟收费。

自托管运行器

  • 仅接收自托管运行器应用程序的自动更新，但你可以禁用运行器的自动更新。 有关控制自托管运行器上的运行器软件更新的详细信息，请参阅“使用自托管运行器自动缩放”。 你负责更新操作系统和所有其他软件。
  • 可以使用已付费的云服务或本地计算机。
  • 可以根据硬件、操作系统、软件和安全要求进行自定义。
  • 无需在每次执行作业时提供一个干净的实例。
  • 可免费使用 GitHub Actions，但是你对运行器维护费用负责。
  • 可以组织成组以限制对特定工作流、组织和存储库的访问。 有关详细信息，请参阅“使用组管理对自托管运行程序的访问”。

自托管运行器机器的要求

只要符合以下要求，便可将任何计算机用作自托管运行器：

  • 你可以在机器上安装和运行自托管运行器应用程序。 有关详细信息，请参阅自托管运行器支持的架构和操作系统。
  • 计算机可与 GitHub Actions 通信。 有关详细信息，请参阅自托管运行器与 GitHub Enterprise Cloud 之间的通信。
  • 机器有足够的硬件资源来执行你计划运行的工作流程类型。 自托管运行器应用程序本身只需要很少的资源。
  • 如果你想运行使用 Docker 容器操作或服务容器的工作流程，你必须使用 Linux 机器并安装 Docker。

自动缩放自托管运行器

你可以自动增加或减少环境中自托管运行器的数量，以响应你收到的 web 挂钩事件。 有关详细信息，请参阅“使用自托管运行器自动缩放”。

使用限制

在使用自托管的运行器时，对 GitHub Actions 的使用有一些限制。 这些限制可能会有变动。

  • 作业执行时间 - 工作流中的每个作业最多可以运行 5 天的执行时间。 如果作业达到此限制，作业将终止且无法完成。 * 工作流运行时间 - 每次工作流运行时间限制为 35 天。 如果工作流程运行时间达到此限制，其运行将被取消。 此时间段包括执行持续时间以及等待和审批所用的时间。
  • 作业排队时间 - 已排队至少 24 小时的自托管运行器的每个作业都将取消。 队列中的实际时间在取消前最多可以达到 48 小时。 如果自托管运行器在此限制内没有开始执行作业，则作业将被终止，并且无法完成。
  • API 请求：一个存储库中所有操作在一小时内最多可以执行 15,000 条对 GitHub API 的请求。**** 如果超出请求数，其他 API 调用将失败，这可能导致作业失败。
  • 作业矩阵 - 作业矩阵在每次工作流程运行时最多可生成 256 个作业。 此限制适用于 GitHub Enterprise Cloud 托管和自托管运行器。
  • 工作流运行队列 - 每个存储库在 10 秒的间隔内可排队的工作流运行不超过 500 个。 如果工作流程运行达到此限制，该工作流程运行将会终止而无法完成。
  • 注册自托管运行器 - 一个运行器组中最多可以有 10,000 个自托管运行器。 如果达到此限制，将无法添加新运行器。

自托管运行器的工作流连续性

如果 GitHub Actions 服务暂时不可用，则在触发后 30 分钟内没有排队时，运行的工作流程运行将被丢弃。 例如，如果触发了一个工作流程，而 GitHub Actions 服务在 31 分钟或更长时间内不可用，则该工作流程将不会被处理。

自托管运行器支持的架构和操作系统

自托管运行器应用程序支持以下操作系统。

Linux

  • Red Hat Enterprise Linux 8 或更高版本
  • CentOS 8 或更高版本
  • Oracle Linux 8 或更高版本
  • Fedora 29 或更高版本
  • Debian 10 或更高版本
  • Ubuntu 20.04 或更高版本
  • Linux Mint 20 或更高版本
  • openSUSE 15.2 或更高版本
  • SUSE Enterprise Linux (SLES) 15 SP2 或更高版本

Windows

  • Windows 10 64 位
  • Windows 11 64 位
  • Windows Server 2016 64 位
  • Windows Server 2019 64 位
  • Windows Server 2022 64 位

macOS

  • macOS 11.0 (Big Sur) 或更高版本

体系结构

自托管运行器应用程序支持以下处理器架构。

  • x64 - Linux、macOS、Windows。
  • ARM64 - Linux、macOS、Windows（当前为 公共预览版）。
  • ARM32 - Linux。

自托管运行器与 GitHub Enterprise Cloud 之间的通信

自托管运行器连接到 GitHub Enterprise Cloud 以接收作业分配并下载新版本的运行器应用程序。 自托管运行器使用 HTTPS long poll 打开 GitHub Enterprise Cloud 连接 50 秒，如果没有收到任何响应，就会暂停并创建新的长轮询。 应用程序必须在机器上运行才能接受和运行 GitHub Actions 作业。

自托管运行器和 GitHub Enterprise Cloud 通过 HTTPS（端口 443）建立连接。

由于自托管运行器会打开与 GitHub 的连接，因此无需允许 GitHub 与自托管运行器建立入站连接。

必须确保机器具有适当的网络访问权限，且上传和下载速度至少达到 70 千位每秒，才可与以下列出的 GitHub 主机通信。 某些主机是基本运行器操作所必需的，而其他主机仅针对某些功能是必需的。

可以使用 REST API 返回关于 GitHub 的元信息，包括 GitHub 服务的 IP 地址。 有关所使用域和 IP 地址的详细信息，请参阅“元数据的 REST API 终结点”。

Note

列出的一些域名使用 CNAME 记录配置。 一些防火墙可能要求你为所有 CNAME 记录递归添加规则。 请注意，CNAME 记录将来可能会改变，只有列出的域名将保持不变。

基本操作所需：

Shell
github.com
api.github.com
*.actions.githubusercontent.com

下载操作时需要：

Shell
codeload.github.com
ghcr.io
*.actions.githubusercontent.com

上传/下载作业摘要、工作流项目和缓存时需要：

Shell
results-receiver.actions.githubusercontent.com
*.blob.core.windows.net

运行器版本更新需要：

Shell
objects.githubusercontent.com
objects-origin.githubusercontent.com
github-releases.githubusercontent.com
github-registry-files.githubusercontent.com

检索 OIDC 令牌时需要：

Shell
*.actions.githubusercontent.com

需要将包或容器下载或发布到 GitHub 包：

Shell
*.pkg.github.com
ghcr.io

Needed for Git Large File Storage 需要

Shell
github-cloud.githubusercontent.com
github-cloud.s3.amazonaws.com

此外，你的工作流程可能需要访问其他网络资源。

如果你对 GitHub 组织或企业帐户使用 IP 地址允许列表，必须将自托管运行器的 IP 地址添加到允许列表。 有关详细信息，请参阅 GitHub Enterprise Cloud 文档中的管理组织允许的 IP 地址或为企业中的安全设置实施策略."

你也可以通过代理服务器使用自托管的运行器。 有关详细信息，请参阅“将代理服务器与自托管运行程序结合使用”。

有关排查常见网络连接问题的详细信息，请参阅“对自托管运行程序进行监视和故障排除”。

自托管运行器安全性

建议仅将自托管运行器用于私有仓库。 这是因为，通过创建在工作流中执行代码的拉取请求，公共存储库的分支可能会在自托管运行器计算机上运行危险代码。

这对 GitHub 托管的运行器不是问题，因为每个 GitHub 托管的运行器始终是一个干净的独立虚拟机， 在作业执行结束时被销毁。

在自托管运行器上运行不受信任的工作流程会给你的机器和网络环境带来严重的安全风险，特别是机器在同一环境下执行不同的作业时。 其中一些风险包括：

  • 机器上运行的恶意程序。
  • 逃避机器的运行器沙盒。
  • 显示对机器网络环境的访问权限。
  • 在机器上保持不需要或危险的数据。

有关自托管运行器安全强化的详细信息，请参阅“GitHub Actions 的安全强化”。

限制自托管运行器的使用

企业所有者和组织所有者可以选择允许哪些存储库创建存储库级别的自托管运行器。 拥有“管理组织运行器和运行器组”权限的用户只能选择允许哪些存储库为组织中的存储库创建存储库级自托管运行器。

有关自定义组织角色的详细信息，请参阅“关于自定义组织角色”。

有关详细信息，请参阅“在企业中为 GitHub Actions 实施策略”和 “禁用或限制组织的 GitHub Actions”。

延伸阅读