从自行托管运行器迁移到 GitHub 托管的运行器

可以在 GitHub 托管或自托管的运行器上运行工作流，或混合使用不同类型的运行器。

本教程介绍如何评估当前对运行程序的使用情况，然后将工作流从自托管运行程序高效迁移到 GitHub 托管的运行程序。

1.评估当前的 CI 基础结构

从自托管运行程序迁移到 GitHub 托管的大型运行程序，首先要对当前的 CI 基础架构进行彻底评估。如果您花时间仔细匹配规格和环境，那么在开始在不同的运行器上执行工作流时，您将能够将修复问题所需的时间降到最低。

创建用于运行工作流的每个计算机规范的清单，包括 CPU 核心、RAM、存储、芯片体系结构和作系统。
请注意，是否有任何运行程序属于运行程序组或具有标签。可以使用此信息简化将工作流迁移到新执行器的过程。
记录工作流依赖的任何自定义映像和预安装的依赖项，因为这些映像会影响迁移策略。
确定哪些工作流当前是针对自托管运行器的，以及原因。例如，在 GitHub Actions 使用情况指标中，使用“作业”选项卡，并按运行程序标签（如 self-hosted 或自定义标签）进行筛选，以查看哪些存储库和作业正在使用该标签。**** 如果需要验证特定的工作流文件，还可以使用代码搜索查找引用 runs-on: self-hosted 或其他自承载标签的工作流文件。
确定访问专用网络资源的工作流（例如内部包注册表、专用 API、数据库或本地服务），因为这些工作流可能需要其他网络配置。

2. 将处理要求映射到 GitHub托管运行程序类型

GitHub 在多个操作系统（Linux、Windows 和 macOS）中提供托管的运行程序，并且提供启用 GPU 的计算机选项。请参阅“大型运行程序参考”。

将清单中的每个不同计算机规范映射到合适的 GitHub托管运行程序规范。
记下没有合适的 GitHub 托管的运行程序的任何自托管运行程序。
从迁移计划中排除任何必须继续在自托管运行器上运行的工作流。

3. 估计容量要求

在预配 GitHub托管的运行程序之前，请估算工作流所需的计算容量。查看当前的自承载运行程序使用情况有助于选择适当的运行程序大小、设置并发限制并预测潜在的成本更改。

在 GitHub 的右上角，单击个人资料图片，然后单击“ Your organizations”****。
单击您的组织名称。
在组织名称下，单击“ Insights”****。
在〈见解〉导航菜单中，单击操作使用情况指标。
单击包含要查看的指标的选项卡。请参阅“关于 GitHub Actions 指标”。

查看以下数据点以评估托管运行器容量。

     **消耗的总分钟数**：有助于估算基线计算需求。

     **工作流运行数**：标识可能需要更多并发的峰值活动时间。

     **跨 OS 类型的作业分发**：确保预配正确的 Linux、Windows 和 macOS 运行程序组合。

     **运行器标签（作业选项卡）**：按运行器标签进行筛选，以了解标签的使用位置。

将发现结果转换为容量计划：
- 在适当情况下，将高使用率的工作流与更大尺寸的运行器相匹配。
- 确定哪些工作流可能会受益于使用预构建或自定义镜像来降低运行时间。
- 通过估计通常同时运行的作业数量来确定并发性。
记下任何差距：
- 当前托管的运行程序映像不支持具有严格依赖项的工作流。
- 具有异常长运行时或定制环境需求的作业。（您可能需要定制这些图像。）

容量计划将指导如何配置多少运行器、要使用的计算机类型，以及如何在后续步骤中配置运行器组和策略。

4. 配置运行器组和策略

估算容量需求后，请配置运行程序组和访问策略，以便 GitHub托管的运行程序可供正确的组织和工作流使用。

在部署运行器之前配置运行器组有助于确保迁移时不会意外过于开放访问权限或产生意外的成本上升。

在企业级创建运行器组，以定义谁可以使用你的托管运行器。请参阅“控制对较大运行器的访问”。

使用运行程序组按组织、存储库或工作流确定访问权限。如果你是从自托管运行程序迁移，请考虑尽可能重用现有的运行程序组名称或标签。这使得在切换到 GitHub-hosted runners 时，工作流可以不作任何更改并继续顺利运行。
将新的 GitHub托管的运行程序添加到相应的组，并根据在步骤 3 中确定的使用模式设置并发限制。有关自动缩放的详细信息，请参阅管理较大的运行器。
查看策略设置，以确保运行器仅由预期工作流使用。例如，限制对特定存储库的使用或阻止不受信任的工作流访问更强大的计算机类型。

注意

macOS 大型运行程序不能添加到运行程序组，并且必须在工作流文件中直接引用。

5. 设置 GitHub 托管的运行器

接下来，根据前面识别的计算机类型和容量预配 GitHub托管的运行程序。

选择符合工作流要求的计算机大小和作系统。有关可用映像和规范，请参阅大型运行程序参考。
将每个运行程序分配到运行程序组并配置并发限制，以控制可以同时运行的作业数。
选择图像类型：
- 使用 GitHub 管理的镜像，以确保环境得到维护和频繁更新。
- 如果需要预安装的依赖项，请使用自定义映像来缩短安装时间。请参阅“使用自定义映像”。
应用任何必需的自定义，例如环境变量、软件安装或启动脚本。有关更多示例，请参阅自定义 GitHub 托管的运行器。
（可选）如果运行器需要访问内部资源，则配置专用网络。请参阅“使用 GitHub 托管的运行器的专用网络”。

配置专用连接选项

如果工作流需要访问专用资源（例如内部包注册表、专用 API、数据库或本地服务），请选择符合网络安全要求的方法。

配置 Azure 专用网络

运行托管的运行程序后，更新工作流程文件以定位它们。

如果将新的运行程序分配到与自托管运行程序所用相同的运行程序组名称，可以重用现有的标签。在这种情况下，工作流将自动使用新的运行程序，而无需更改。

如果创建了新的运行程序组或标签，请更新工作流 YAML 文件中的运行字段。例如：

jobs:
  build:
    runs-on: [github-larger-runner, linux-x64]
    steps:
      - name: Checkout code
        uses: actions/checkout@v5
      - name: Build project
        run: make build

检查对自托管标签（如 self-hosted、linux-x64 或自定义标签）的硬编码引用，并将其替换为相应的 GitHub 托管的运行程序标签。
测试每个更新的工作流，以确保它在新的执行环境中正确运行。监控与环境差异或缺少依赖项相关的任何问题。

7. 删除未使用的自托管运行程序

在 GitHub托管运行程序上更新和测试工作流后，删除不再需要的任何自承载运行程序。这可以防止作业意外地针对过时的基础结构。请参阅“删除自托管的运行器”。

在删除自托管运行程序之前，请验证是否已完全迁移：

在 GitHub Actions 使用情况指标中，使用“作业”选项卡并按运行程序标签（例如，self-hosted 或自定义标签）进行筛选，以确认没有存储库或作业仍在使用自托管运行程序。****

从自行托管运行器迁移到 GitHub 托管的运行器

本文内容