GitHub藏了半年的功能上线，CI构建终于不用每次都"重装系统

GitHub 刚刚宣布，其托管 Runner 现已支持自定义镜像。该功能终于结束了自去年 10 月开始的公开预览阶段。借助这一功能，团队可以使用经过 GitHub 批准的基础镜像，构建真正符合其工作流需求的虚拟机镜像。

其原理很简单，而它所解决的问题对任何管理过大规模持续集成（CI）的人来说都并不陌生。每当在 GitHub 托管的标准 Runner 上运行工作流时，它都会从头开始安装工具。Node、Python 运行时、特定语言的 SDK、内部证书、自定义二进制文件——所有这些在每次运行、每个任务中都会重新下载。自定义镜像则颠覆了这种模式：你只需一次性将所有内容打包好，后续任务便能完全跳过这些初始化步骤。

该流程包括三个步骤：设置一个镜像生成 Runner，运行包含 snapshot 关键字的工作流，然后创建一个使用该镜像的 Runner。关键字 snapshot 是核心机制。每个包含该关键字的任务都会生成一个独立的镜像。每次成功运行都会生成一个新的版本；GitHub 会自动递增次版本号。希望进行更精细控制的团队可以使用映射语法锁定到特定的主版本，并且可以配置 Runner 使用最新版本或锁定到特定版本。锁定到最新版本的 Runner 会在下次生成新版本时自动采用新镜像；锁定到特定版本的 Runner 则会保持不变，直到有人手动更新它。

GitHub 建议将镜像生成设置为周任务。这有助于保持依赖项的最新状态，并确保定期应用安全补丁。这是一个明智的建议，但这也意味着自定义镜像成了需要管理的又一项构建产物；它们需要生成，需要进行版本控制，并且可能需要接受审计。文档中还提到了治理方面的功能：企业所有者可以在 Actions 策略设置中管理自定义镜像的访问权限并设置保留策略。

该功能仅在比较大的 Runner 上提供，这意味着它是与 GitHub Team 或 GitHub Enterprise Cloud 套餐关联的。使用免费套餐的组织将无法使用该功能。镜像生成 Runner 的平台必须与正在构建的镜像的平台一致：Linux x64、Linux ARM64 或 Windows x64。

有必要明确下该功能不是什么。它并非一个通用的虚拟机镜像管道。你无法从外部导入任意 AMI 或 GCP 机器镜像。其基础必须是 GitHub 精选的基础镜像，或是 GitHub 提供的干净的操作系统镜像。该镜像始终处于 GitHub 生态系统内。你可以在组织 Actions 设置中的"自定义镜像"下查看它们，而非在你自己的容器注册表中。如果你希望在不同 CI 提供商之间复用镜像，或在 GitHub Actions 工作流之外构建镜像，则需要单独管理这些操作。

预先设置好且可定制的执行环境并不是什么新东西。不同的持续集成（CI）平台对此采取了各种不同的解决方式。

GitLab CI 允许团队在 .gitlab-ci.yml 中指定任何容器镜像。这意味着他们可以轻松地将任务指向注册表中的镜像，无论该注册表是 GitLab 的还是外部的，而且不需要额外的配置步骤。镜像会在任务启动时拉取。GitLab Runner 提供了多种在虚拟机级执行的执行器类型，如 Docker、Kubernetes 和 shell。这为团队提供了扩展计算资源的可选项。config.toml 中的 Runner 配置用于管理拉取策略、注册表凭据和缓存行为。GitLab 的模型对镜像来源的限制较少，将更多镜像生命周期管理的责任交给了团队。

CircleCI 采用了双轨策略。团队既可以在具有完整系统访问权限的机器执行器上运行任务，也可以使用自定义 Docker 镜像来满足特定需求。自定义 Docker 镜像与 CircleCI 的容器 Runner 天然兼容：你只需自行定义并发布镜像，然后在任务配置中引用它即可。容器 Runner 会接收容器化任务，将其调度到临时 Pod 中，并在容器环境中执行任务。它同时支持 CircleCI 便捷镜像和自定义 Docker 镜像。长期以来，用户一直呼吁在 CircleCI 云上为机器执行器提供自定义的 VM 级镜像，如预构建的 AMI。用户指出，GitLab 早已提供了类似的支持。对于需要完全操作系统级控制的团队，CircleCI 之前提供的解决方案主要是自托管 Runner。

GitHub 处理自定义镜像的方式，类似于在 AWS 上使用预配置 AMI 的自托管 Runner 池，或是使用 Packer 管理的镜像库。不过，该方案是完全托管的，并且已经集成到平台中。它所做的权衡取舍与其他任何托管解决方案都是一样的：以牺牲部分灵活性为代价，换取更低的运维开销。这种权衡的价值取决于构建环境的复杂程度，同时也取决于组织是否准备好将 Runner 镜像视为重要的构建产物。这些镜像需要独立的版本控制和更新计划。