关于自托管运行程序

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

本文内容

注意：GitHub Enterprise Server 目前不支持 GitHub 托管的运行器。 可以在 GitHub public roadmap 上查看有关未来支持计划的更多信息。

关于自托管运行程序

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

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

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

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

运行器机器使用 GitHub Actions 自托管运行器应用程序连接到 GitHub Enterprise Server。GitHub Actions 运行器应用程序是开源的。 可以参与 runner 存储库并在其中提交问题。 发布新版本后，运行器应用程序将在 24 小时内自动更新。

Note

如果使用临时运行器并禁用了自动更新，则在升级 GitHub Enterprise Server 之前，应首先将自托管运行器升级到升级后的实例将运行的运行器应用程序版本。 在升级临时运行器之前升级 GitHub Enterprise Server 可能会导致运行器脱机。 有关详细信息，请参阅“升级过程概述”。

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

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

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

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

GitHub 托管的运行器：

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

自托管运行器

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

自托管运行器机器的要求

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

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

自动缩放自托管运行器

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

使用限制

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

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

对自承载运行程序的支持操作

可能需要进行额外的配置才可结合使用来自 GitHub with GitHub Enterprise Server 的操作与 GitHub Enterprise Server，或者结合使用 actions/setup-LANGUAGE 操作与没有互联网连接的自托管运行器。 有关详细信息，请参阅“管理对 GitHub.com 上操作的访问”并联系 GitHub Enterprise 站点管理员。

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

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

自托管运行器和 GitHub Enterprise Server 通过 HTTP（端口 80）或 HTTPS（端口 443）建立连接。 若要确保通过 HTTPS 进行连接，请为 你的 GitHub Enterprise Server 实例 配置 TLS。 有关详细信息，请参阅“配置 TLS”。

只有从运行器到 GitHub Enterprise Server 的出站连接是必需的。 不需要从 GitHub Enterprise Server 到运行器的入站连接。 若要使缓存正常工作，运行器必须能够与 Blob 存储通信，并直接从其中下载内容。

GitHub Enterprise Server 必须通过 HTTP(S) 在 你的 GitHub Enterprise Server 实例 的主机名和 API 子域接受来自运行器的入站连接，并且运行器必须允许通过 HTTP(S) 与 你的 GitHub Enterprise Server 实例 的主机名和 API 子域建立出站连接。

自托管运行器不需要接入任何外部互联网即可运行。 因此，可以使用网络路由在自托管运行器与 GitHub Enterprise Server 之间直接通信。 例如，可以将私有 IP 地址分配给自托管运行器，并配置路由以将流量发送到 GitHub Enterprise Server，无需流量便可浏览公用网络。

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

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

自托管运行器与 GitHub.com 之间的通信

自托管运行器不需要连接到 GitHub.com，除非您已启用自动访问 GitHub Enterprise Server 的 GitHub.com 操作。 有关详细信息，请参阅“关于在企业中使用操作”。

如果已启用自动访问 GitHub.com 操作，则自托管运行器将直接连接到 GitHub.com 以下载操作。 你必须确保机器具有适当的网络访问权限才可与以下列出的 GitHub URL 通信。

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

Note

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

自托管运行器安全性

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

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

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

限制自托管运行器的使用

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

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

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

延伸阅读