{"meta":{"title":"从自行托管运行器迁移到 GitHub 托管的运行器","intro":"了解如何评估当前的 CI 基础设施，并将工作流从自托管运行器迁移到 GitHub 托管运行器。","product":"GitHub Actions","breadcrumbs":[{"href":"/zh/enterprise-cloud@latest/actions","title":"GitHub Actions"},{"href":"/zh/enterprise-cloud@latest/actions/tutorials","title":"教程"},{"href":"/zh/enterprise-cloud@latest/actions/tutorials/migrate-to-github-runners","title":"迁移到 GitHub 运行程序"}],"documentType":"article"},"body":"# 从自行托管运行器迁移到 GitHub 托管的运行器\n\n了解如何评估当前的 CI 基础设施，并将工作流从自托管运行器迁移到 GitHub 托管运行器。\n\n您可以在由 GitHub 托管的运行器或自托管运行器上运行工作流，也可以混合使用这两种类型的运行器。\n\n本教程介绍如何评估当前运行程序的使用情况，然后将工作流从自承载运行程序有效地迁移到 GitHub托管运行程序。\n\n## 1.评估当前的 CI 基础结构\n\n从自托管运行器迁移到 GitHub 托管的大型运行器，首先要对当前的 CI 基础设施进行全面评估。 如果您花时间仔细匹配规格和环境，那么在开始在不同的运行器上执行工作流时，您将能够将修复问题所需的时间降到最低。\n\n1. 创建用于运行工作流的每个计算机规范的清单，包括 CPU 核心、RAM、存储、芯片体系结构和作系统。\n2. 请注意，是否有任何运行程序属于运行程序组或具有标签。 可以使用此信息简化将工作流迁移到新执行器的过程。\n3. 记录工作流依赖的任何自定义映像和预安装的依赖项，因为这些映像会影响迁移策略。\n4. 确定哪些工作流当前是针对自托管运行器的，以及原因。 例如，在使用情况指标中 GitHub Actions ，使用 **“作业** ”选项卡并按运行程序标签（例如 `self-hosted` 或自定义标签）进行筛选，以查看哪些存储库和作业正在使用该标签。 如果需要验证特定的工作流文件，还可以使用代码搜索查找引用 `runs-on: self-hosted` 或其他自承载标签的工作流文件。\n5. 确定访问专用网络资源的工作流（例如内部包注册表、专用 API、数据库或本地服务），因为这些工作流可能需要其他网络配置。\n\n## 2.将处理要求映射到 GitHub托管运行程序类型\n\nGitHub提供适用于多种操作系统（Linux、Windows 和 macOS）的托管运行器，并可选择配备 GPU 的机器。 请参阅“[大型运行程序参考](/zh/enterprise-cloud@latest/actions/reference/runners/larger-runners)”。\n\n1. 将清单中的每种不同机器规格对应到合适的 GitHub 托管运行器规格。\n2. 记下没有合适的 GitHub托管运行程序的任何自承载运行程序。\n3. 从迁移计划中排除任何必须继续在自托管运行器上运行的工作流。\n\n## 3. 估计容量要求\n\n在配置 GitHub 托管运行程序之前，请先估算您的工作流所需的计算资源容量。 查看当前的自承载运行程序使用情况有助于选择适当的运行程序大小、设置并发限制并预测潜在的成本更改。\n\n1. 在 GitHub 的右上角，单击个人资料图片，然后单击“<svg version=\"1.1\" width=\"16\" height=\"16\" viewBox=\"0 0 16 16\" class=\"octicon octicon-organization\" aria-label=\"organization\" role=\"img\"><path d=\"M1.75 16A1.75 1.75 0 0 1 0 14.25V1.75C0 .784.784 0 1.75 0h8.5C11.216 0 12 .784 12 1.75v12.5c0 .085-.006.168-.018.25h2.268a.25.25 0 0 0 .25-.25V8.285a.25.25 0 0 0-.111-.208l-1.055-.703a.749.749 0 1 1 .832-1.248l1.055.703c.487.325.779.871.779 1.456v5.965A1.75 1.75 0 0 1 14.25 16h-3.5a.766.766 0 0 1-.197-.026c-.099.017-.2.026-.303.026h-3a.75.75 0 0 1-.75-.75V14h-1v1.25a.75.75 0 0 1-.75.75Zm-.25-1.75c0 .138.112.25.25.25H4v-1.25a.75.75 0 0 1 .75-.75h2.5a.75.75 0 0 1 .75.75v1.25h2.25a.25.25 0 0 0 .25-.25V1.75a.25.25 0 0 0-.25-.25h-8.5a.25.25 0 0 0-.25.25ZM3.75 6h.5a.75.75 0 0 1 0 1.5h-.5a.75.75 0 0 1 0-1.5ZM3 3.75A.75.75 0 0 1 3.75 3h.5a.75.75 0 0 1 0 1.5h-.5A.75.75 0 0 1 3 3.75Zm4 3A.75.75 0 0 1 7.75 6h.5a.75.75 0 0 1 0 1.5h-.5A.75.75 0 0 1 7 6.75ZM7.75 3h.5a.75.75 0 0 1 0 1.5h-.5a.75.75 0 0 1 0-1.5ZM3 9.75A.75.75 0 0 1 3.75 9h.5a.75.75 0 0 1 0 1.5h-.5A.75.75 0 0 1 3 9.75ZM7.75 9h.5a.75.75 0 0 1 0 1.5h-.5a.75.75 0 0 1 0-1.5Z\"></path></svg> Your organizations”\\*\\*\\*\\*。\n\n2. 单击您的组织名称。\n\n3. 在组织名称下，单击“<svg version=\"1.1\" width=\"16\" height=\"16\" viewBox=\"0 0 16 16\" class=\"octicon octicon-graph\" aria-label=\"graph\" role=\"img\"><path d=\"M1.5 1.75V13.5h13.75a.75.75 0 0 1 0 1.5H.75a.75.75 0 0 1-.75-.75V1.75a.75.75 0 0 1 1.5 0Zm14.28 2.53-5.25 5.25a.75.75 0 0 1-1.06 0L7 7.06 4.28 9.78a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042l3.25-3.25a.75.75 0 0 1 1.06 0L10 7.94l4.72-4.72a.751.751 0 0 1 1.042.018.751.751 0 0 1 .018 1.042Z\"></path></svg> Insights”\\*\\*\\*\\*。\n\n   ![组织的水平导航栏的屏幕截图。 标有图标和“见解”的选项卡以深橙色标出。](/assets/images/help/organizations/org-nav-insights-tab.png)\n\n4. 在〈见解〉导航菜单中，单击 <c0>操作使用情况指标<c0>。\n\n5. 单击包含要查看的指标的选项卡。 请参阅“[关于 GitHub Actions 指标](/zh/enterprise-cloud@latest/actions/concepts/metrics)”。\n\n6. 查看以下数据点以评估托管运行器容量。\n\n   * **消耗的总分钟数**：有助于估算基线计算需求。\n   * **工作流运行数**：标识可能需要更多并发的峰值活动时间。\n   * **跨 OS 类型的作业分发**：确保预配正确的 Linux、Windows 和 macOS 运行程序组合。\n   * **运行器标签（作业选项卡）**：按运行器标签进行筛选，以了解标签的使用位置。\n\n7. 将发现结果转换为容量计划：\n\n   * 在适当情况下，将高使用率的工作流与更大尺寸的运行器相匹配。\n   * 确定哪些工作流可能会受益于使用预构建或自定义镜像来降低运行时间。\n   * 通过估计通常同时运行的作业数量来确定并发性。\n\n8. 记下任何差距：\n\n   * 当前托管的运行程序映像不支持具有严格依赖项的工作流。\n   * 具有异常长运行时或定制环境需求的作业。 （您可能需要定制这些图像。）\n\n容量计划将指导如何配置多少运行器、要使用的计算机类型，以及如何在后续步骤中配置运行器组和策略。\n\n## 4. 配置运行器组和策略\n\n估算容量需求后，配置运行程序组和访问策略，以便 GitHub托管的运行程序可供正确的组织和工作流使用。\n\n在部署运行器之前配置运行器组有助于确保迁移时不会意外过于开放访问权限或产生意外的成本上升。\n\n1. 在企业级创建运行器组，以定义谁可以使用你的托管运行器。 请参阅“[控制对较大运行器的访问](/zh/enterprise-cloud@latest/actions/how-tos/manage-runners/larger-runners/control-access#creating-a-runner-group-for-an-enterprise)”。\n\n   使用运行程序组按组织、存储库或工作流确定访问权限。 如果你是从自托管运行程序迁移，请考虑尽可能重用现有的运行程序组名称或标签。 这允许工作流在切换到 GitHub托管运行程序时继续工作，而无需更改。\n\n2. 将新的 GitHub托管运行程序添加到相应的组，并根据步骤 3 中确定的使用模式设置并发限制。 有关自动缩放的详细信息，请参阅 [管理较大的运行器](/zh/enterprise-cloud@latest/actions/how-tos/manage-runners/larger-runners/manage-larger-runners#configuring-autoscaling-for-larger-runners)。\n\n3. 查看策略设置，以确保运行器仅由预期工作流使用。 例如，限制对特定存储库的使用或阻止不受信任的工作流访问更强大的计算机类型。\n\n## 5. 配置由 GitHub 托管的运行器\n\n接下来，根据你之前确定的机器类型和容量，为由 GitHub 托管的运行器进行预配。\n\n1. 选择符合工作流要求的计算机大小和作系统。 有关可用映像和规范，请参阅 [大型运行程序参考](/zh/enterprise-cloud@latest/actions/reference/runners/larger-runners#runner-images)。\n\n2. 将每个运行程序分配到运行程序组并配置并发限制，以控制可以同时运行的作业数。\n\n3. 选择图像类型：\n\n   * 使用由 GitHub 管理的映像，以获得持续维护且频繁更新的环境。\n   * 如果需要预安装的依赖项，请使用自定义映像来缩短安装时间。 请参阅“[使用自定义映像](/zh/enterprise-cloud@latest/actions/how-tos/manage-runners/larger-runners/use-custom-images)”。\n\n4. 应用任何必需的自定义，例如环境变量、软件安装或启动脚本。 有关更多示例，请参阅 [自定义 GitHub 托管的运行器](/zh/enterprise-cloud@latest/actions/how-tos/manage-runners/github-hosted-runners/customize-runners)。\n\n5. （可选）如果运行器需要访问内部资源，则配置专用网络。 请参阅“[使用GitHub托管的运行程序建立专用网络](/zh/enterprise-cloud@latest/actions/concepts/runners/private-networking)”。\n\n### 配置专用连接选项\n\n如果工作流需要访问专用资源（例如内部包注册表、专用 API、数据库或本地服务），请选择符合网络安全要求的方法。\n\n#### 配置 Azure 专用网络\n\n在 Azure 虚拟网络 （VNET） 内运行GitHub托管运行程序，以便安全访问内部资源。\n\n1. 创建一个 Azure 虚拟网络 (VNET)，为执行程序配置子网和网络安全组。\n2. 为运行程序组启用 Azure 专用网络。 请参阅“[为企业中的GitHub托管运行器配置私有网络](/zh/enterprise-cloud@latest/admin/configuring-settings/configuring-private-networking-for-hosted-compute-products/configuring-private-networking-for-github-hosted-runners-in-your-enterprise#1-add-a-new-network-configuration-for-your-enterprise)”\n3. 应用网络配置（如 NSG 和防火墙规则）来控制入口和出口流量。\n4. 更新工作流目标，以使用为专用网络配置的运行程序组。\n\n有关详细说明，请参阅：\n\n* [为组织中的 GitHub 托管的运行器配置专用网络](/zh/enterprise-cloud@latest/organizations/managing-organization-settings/configuring-private-networking-for-github-hosted-runners-in-your-organization)\n* [为企业中的GitHub托管运行器配置私有网络](/zh/enterprise-cloud@latest/admin/configuring-settings/configuring-private-networking-for-hosted-compute-products/configuring-private-networking-for-github-hosted-runners-in-your-enterprise)\n\n#### 使用 WireGuard 覆盖网络进行连接\n\n如果 Azure 专用网络不适用（例如，由于目标网络位于本地或其他云中），则可以使用 VPN 覆盖（例如 WireGuard）提供对专用资源的网络级访问。\n\n有关详细说明和示例，请参阅 [使用 WireGuard 创建网络覆盖层](/zh/enterprise-cloud@latest/actions/how-tos/manage-runners/github-hosted-runners/connect-to-a-private-network/connect-with-wireguard)。\n\n#### 将 OIDC 与 API 网关配合使用，以便对专用资源进行受信任的访问\n\n如果不需要运行程序加入专用网络，可以使用 OIDC 建立对通过 API 网关公开的服务的受信任短期访问。 此方法可以减少对长期机密的需求，并限制对工作流所需的特定终结点的网络访问。\n\n有关详细说明和示例，请参阅 [将 API 网关与 OIDC 配合使用](/zh/enterprise-cloud@latest/actions/how-tos/manage-runners/github-hosted-runners/connect-to-a-private-network/connect-with-oidc)。\n\n## 6. 更新工作流以使用新的运行程序\n\n在您配置好 GitHub 托管的运行器后，请更新工作流文件以将其设为目标。\n\n1. 如果将新的运行程序分配到与自托管运行程序所用相同的运行程序组名称，可以重用现有的标签。 在这种情况下，工作流将自动使用新的运行程序，而无需更改。\n\n2. 如果创建了新的运行程序组或标签，请更新工作流 YAML 文件中的运行字段。 例如：\n\n   ```yaml\n   jobs:\n     build:\n       runs-on: [github-larger-runner, linux-x64]\n       steps:\n         - name: Checkout code\n           uses: actions/checkout@v6\n         - name: Build project\n           run: make build\n   ```\n\n3. 检查是否存在对自托管标签（例如 `self-hosted`、`linux-x64` 或自定义标签）的硬编码引用，并将其替换为相应的由 GitHub 托管的运行器标签。\n\n4. 测试每个更新的工作流，以确保它在新的执行环境中正确运行。 监控与环境差异或缺少依赖项相关的任何问题。\n\n## 7. 删除未使用的自托管运行程序\n\n在 GitHub 托管的运行器上更新并测试工作流后，删除不再需要的任何自托管运行器。 这可以防止作业意外地针对过时的基础结构。 请参阅“[删除自托管的运行器](/zh/enterprise-cloud@latest/actions/how-tos/manage-runners/self-hosted-runners/remove-runners)”。\n\n在删除自托管运行程序之前，请验证是否已完全迁移：\n\n* 在 GitHub Actions 使用情况指标中，使用 **“作业** ”选项卡并按运行程序标签（例如 `self-hosted` ，自定义标签）进行筛选，以确认没有存储库或作业仍在使用自承载运行程序。"}