CNCF触发了ARM64和X86的平台平等突破

Arm64 架构开源软件的 CI/CD 难题与解决方案

在 Arm64 架构上部署开源软件需要一个强大的 CI/CD 环境。然而，Arm64 和传统 x86 处理器架构的支持水平之间存在差异，Arm64 通常处于劣势。面向多种架构的基础设施组件开发人员对工作环境有一定的期望：

• 一致性：跨平台使用的工具和方法保持一致，避免因采用不太流行的平台而需要改变开发流程。
• 性能：平台和支持机制具有良好的性能，确保在支持多个平台时部署方案不会因速度不足而受影响。
• 测试覆盖率：对所有平台同时进行效率、合规性和安全性测试，且无需进行重大区分。
• 可维护性：使开发人员能够自动化集成和重新开发流程，使其适用于所有平台而无需修改。

这些组件的产品经理也需要满足这些要求，此外还有至少两点：

• 平台覆盖能力：技术客户经理 (TAM) 具备响应客户需求所需的技能和准备。
• 支持分级能力：使 TAM 和其他 IT 人员能够根据响应紧急或突发客户问题的能力对软件支持级别进行分类。

Actuated 平台的助力

开源开发者 Alex Ellis 与 Ampere 和基础设施提供商 Equinix 合作，为云原生软件生态系统中一些最关键的开源项目提供了 Actuated CI/CD 平台。

Actuated 将 GitHub 自托管自动化流程（安全工程师证明其容易受到恶意攻击）在与公共互联网隔离的微虚拟机中运行。

实施与成果

几个关键的 CNCF 开源项目利用 Actuated 环境运行其所有 Arm64 的 GitHub Actions。该环境基于 Ampere® Altra® 处理器，并在基础设施提供商 Equinix 的帮助下提供。

这项举措的成功促使 GitHub 为 GitHub Actions 提供了完整的 Arm64 架构支持。现在，以前在 x86 架构的 QEMU 模拟环境中运行 Arm64 构建流程的开发人员可以将其迁移到裸机上的 Arm64。

GitHub Actions 的 Arm64 自托管运行器

GitHub 占据了软件项目托管的主导地位。GitHub 托管项目生成持续集成构建和发布最流行的方式是使用平台内置的 CI 工具集 GitHub Actions。GitHub Actions CI/CD 平台最重要的作用是自动化软件开发流程。

触发任何 GitHub Action 的责任方是运行器。它是在服务器上运行的代理，等待任务并准备好一旦收到任务就执行。它从工作流程中获得任务，并负责完成它。

GitHub 是一个完整的软件部署平台。因此，它托管自己的运行器，每个运行器都适应其指定的目标环境和架构。直到最近，GitHub 还没有为 Arm64 提供托管运行器环境。想要生成 Arm64 原生构建的项目确实有一个选择——自托管运行器。

GitHub 用户可以在其他地方托管的物理机或虚拟机上安装代理，并让 GitHub Actions 将作业分派到该主机，由项目用户管理。这要求项目管理员不仅要管理项目本身，还要负责维护和保障项目将使用的构建环境的安全。

在 CNCF 的案例中，开发人员利用了 Equinix Metal 的积分，使他们能够配置裸机实例并将其用作项目的自托管运行器。但是对于必须全天候向全球其他开发人员提供服务的代码实验室项目而言，自托管运行器的安全性构成挑战：根据 GitHub 文档，任何人都可以克隆项目存储库，修改 Actions 作业，并访问运行器节点以运行任意作业。

另一个问题是确保 CI 运行之间的一致性。对于自托管运行器，如果 CI 作业存在副作用，例如配置更改或之后留下的文件，它们仍将存在于后续作业中。

这带来了一个问题——在运行构建或测试软件的 CI 作业时，应该拥有一个受控的环境，以便每次运行之间唯一变化的是软件。对于自托管运行器，环境会随着时间的推移而发生漂移。如果没有清理过程，同一个主机上相同构建作业的运行可能会随着时间的推移而产生不同的结果。

开发人员绕过对 Arm64 原生运行器需求的一种方法是在 x86 服务器上运行虚拟 Arm64 环境，使用 QEMU 开源模拟。模拟环境为软件编译增加了巨大的性能开销，其速度只是在原生、非模拟硬件上编译速度的一小部分。

模拟对于开发中小型项目足够好用。但是，如果开发人员必须为 ARM64 构建大型且重要的项目，那么对虚拟环境的压力就会变得非常大，以至于构建会完全失败。

差距现象

与典型的企业不同，CNCF 有义务为世界上所有主要的处理器架构构建其云原生组件。

containerd 可移植容器运行时、etcd 键值数据存储、fluentd 日志数据收集器、Falco 实时威胁检测工具和 OpenTelemetry 可观测性和检测工具包等项目是云原生生态系统的关键依赖项，因此必须为 x86 和 Arm64 构建。

为了构建支持 Arm64 的低级基础设施组件，CNCF 开发人员需要访问原生的 Arm64 基础设施。具有讽刺意味的是，这意味着他们需要他们正在尝试创建的工具类别。

最初，Ampere 和 Equinix 与 CNCF 合作克服这些差距，通过捐赠基于 Ampere Altra 的服务器或在 Equinix 设施中设置基于 Altra 的裸机节点。Equinix 可以共享的基于 Arm64 的服务器资源的粒度是裸机节点——160 核双插槽 Ampere Altra 系统。

理想情况下，这样的服务器将在多个项目之间共享，但这在当时超出了 CNCF 的能力范围。这就是 Ampere 和 Actuated 提出为 CNCF 解决的问题，通过允许多个项目在较少的数量的主机上运行，从而为更多项目提供对构建服务的轻松访问，同时消耗更少的硬件。

突破：Actuated 和一行代码的修改

为了迈向 x86 和 Arm64 之间平台一致性的第一步，Ampere 寻求了 Alex Ellis 的帮助，他是名为 Actuated 的服务的创建者。这是一个在安全的、隔离的微虚拟机中运行 GitHub Actions 作业的产品，该产品经过检测以接收来自 GitHub Actions 的构建作业，并为开发人员提供对其构建作业性能和共享构建系统负载的可视性。

在更改其配置文件的一行代码后，Actuated 就可以运行所有 CNCF 现有的 GitHub Actions 运行器，在某些情况下还需要粘贴一些代码片段——这些更改的实施时间不到五分钟。这些更改使 GitHub 托管项目能够指向 Actuated 在 Ampere Altra 处理器上的微虚拟机驱动环境以进行其构建作业。

公平的竞争环境

到 2023 年初，对于想要将 Arm64 完全集成到其持续集成流程中的 GitHub 托管项目，几乎没有选择。通过这项倡议，利用 Actuated 的创新软件解决方案和 Equinix 托管的 Ampere CPU，降低了 CNCF 项目开始实现 ARM64 和 x86 支持一致性的门槛。

包括 etcd、containerd、Open Telemetry、Falco 等在内的关键云原生项目能够推进其对 ARM64 的支持，加快其在原生 Arm64 基础设施上的 CI 运行速度，并支持越来越多的用户利用云中的 Arm64 计算。

在这个试点项目结束时，开发人员的选择数量大大增加。CNCF 现在为其项目提供了在 OCI 上的托管 Kubernetes 集群上运行 GitHub Actions 作业的能力，使用 Ampere 驱动的实例和 GitHub 项目 Actions Runner Controller，并且随着 GitHub 添加了托管的 Arm64 运行器，项目更容易支持这种快速增长且令人兴奋的云原生应用程序架构。

以上是CNCF触发了ARM64和X86的平台平等突破的详细内容。更多信息请关注PHP中文网其他相关文章！