CI/CD problems and solutions for open source software in Arm64 architecture

Deploying open source software on Arm64 architecture requires a powerful CI/CD environment. However, there is a difference between the support levels of Arm64 and traditional x86 processor architectures, which are often at a disadvantage. Infrastructure components developers for multiple architectures have certain expectations for their work environment:

• Consistency: The tools and methods used across platforms are consistent, avoiding the need to change the development process due to the adoption of less popular platforms.
• Performance: The platform and support mechanism have good performance to ensure that deployment scenarios are not affected by insufficient speed when supporting multiple platforms.
• Test coverage: All platforms are tested simultaneously with efficiency, compliance and security without significant distinction.
• Maintainability: Enables developers to automate the integration and redevelopment process to make it suitable for all platforms without modification.

Product managers of these components also need to meet these requirements, and there are at least two points:

• Platform Coverage: Technical Account Manager (TAM) has the skills and preparation required to respond to customer needs.
• Support hierarchical capabilities: Enables TAMs and other IT personnel to classify software support levels based on their ability to respond to emergencies or emergencies.

The Aid of Actuated Platform

Open source developer Alex Ellis, partnering with Ampere and infrastructure provider Equinix, provides an Actuated CI/CD platform for some of the most critical open source projects in the cloud-native software ecosystem.

Actuated runs GitHub self-hosted automation processes (which security engineers prove vulnerable to malicious attacks) in micro virtual machines isolated from the public Internet.

Implementation and Results

Several critical CNCF open source projects use Actuated environments to run all of their Arm64 GitHub Actions. The environment is based on Ampere? Altra? processors and is provided with the help of infrastructure provider Equinix.

The success of this initiative has led GitHub to provide full Arm64 architecture support for GitHub Actions. Developers who used to run the Arm64 build process in a QEMU simulation environment with x86 architecture can now migrate it to Arm64 on bare metal.

Arm64 self-hosted runner for GitHub Actions

GitHub dominates software project hosting. The most popular way to generate continuous integration builds and releases of GitHub hosted projects is to use GitHub Actions, a CI tool set built in, the platform. The most important role of the GitHub Actions CI/CD platform is to automate the software development process.

The runner is responsible for triggering any GitHub Action. It is a proxy running on the server, waiting for the task and ready to execute once the task is received. It takes the task from the workflow and is responsible for completing it.

GitHub is a complete software deployment platform. Therefore, it hosts its own runners, each adapting to its specified target environment and architecture. Until recently, GitHub has not provided a managed runner environment for Arm64. There is indeed an option for projects that want to generate Arm64 native builds - a self-hosted runner.

GitHub users can install agents on physical or virtual machines hosted elsewhere and have GitHub Actions dispatch jobs to the host, managed by project users. This requires the project administrator not only to manage the project itself, but also to maintain and ensure the security of the build environment the project will use.

In the CNCF case, developers leveraged Equinix Metal points, allowing them to configure bare metal instances and use them as self-hosted runners for projects. But for code lab projects that must serve other developers around the world 24/7, the security of a self-hosted runner poses a challenge: According to the GitHub documentation, anyone can clone the project repository, modify the Actions job, and access the runner node to run any job.

Another problem is ensuring consistency between CI operations. For self-hosted runners, if there are side effects on CI jobs, such as configuration changes or files left afterwards, they will still exist in subsequent jobs.

This brings up a problem – when running CI jobs that build or test software, you should have a controlled environment so that the only change between each run is the software. For self-hosted runners, the environment drifts over time. Without a cleanup process, the running of the same build job on the same host may produce different results over time.

One way developers bypass the need for Arm64 native runners is to run a virtual Arm64 environment on an x86 server, using QEMU open source simulation. The simulated environment adds huge performance overhead to software compilation, and its speed is only a small part of the speed of compilation on native, non-analog hardware.

Simulation is easy to use for small and medium-sized projects. However, if developers have to build large and important projects for ARM64, the pressure on the virtual environment becomes so great that the build will fail completely.

Gap phenomenon

Unlike typical enterprises, CNCF is obliged to build its cloud-native components for all the major processor architectures in the world.

Projects such as containerd portable container runtime, etcd key-value data store, fluentd log data collector, Falco real-time threat detection tool, and OpenTelemetry observability and detection toolkit are key dependencies in the cloud native ecosystem and must therefore be built for x86 and Arm64.

To build low-level infrastructure components that support Arm64, CNCF developers need access to native Arm64 infrastructure. Ironically, this means they need the category of tools they are trying to create.

Initially, Ampere and Equinix worked with CNCF to overcome these gaps by donating Ampere Altra-based servers or setting up Altra-based bare metal nodes in Equinix facilities. The granularity of the Arm64-based server resources that Equinix can share is the bare metal node-160-core dual-slot Ampere Altra system.

Ideally, such servers would be shared among multiple projects, but this was beyond the capabilities of the CNCF at the time. This is the problem Ampere and Actuated addressed for CNCF by allowing multiple projects to run on a smaller number of hosts, providing more projects with easy access to build services while consuming less hardware.

Breakthrough: Modification of Actuated and one-line code

To move toward the first step towards platform consistency between x86 and Arm64, Ampere sought help from Alex Ellis, the creator of a service called Actuated. This is a product that runs GitHub Actions jobs in a secure, isolated micro virtual machine that is detected to receive build jobs from GitHub Actions and provides developers with visibility into their build job performance and shared build system load.

After changing a line of code for its configuration file, Actuated can run all CNCF's existing GitHub Actions runners, and in some cases it also requires pasting some code snippets—the changes were implemented in less than five minutes. These changes enable GitHub hosted projects to point to Actuated's micro-VM-driven environment on Ampere Altra processors for their build jobs.

A level playing field

By early 2023, there are few options for GitHub hosting projects that want to fully integrate Arm64 into its continuous integration process. Through this initiative, leveraging Actuated innovative software solutions and Equinix-managed Ampere CPUs, lowering the barriers for CNCF projects to begin achieving consistency in ARM64 and x86 support.

Key cloud-native projects including etcd, containerd, Open Telemetry, Falco, etc. can promote their support for ARM64, speed up its CI operation on native Arm64 infrastructure, and support more and more users to take advantage of Arm64 computing in the cloud.

At the end of this pilot project, the number of developers' choices increased significantly. CNCF now provides its projects with the ability to run GitHub Actions jobs on a managed Kubernetes cluster on OCI, using Ampere-driven instances and GitHub project Actions Runner Controller, and with GitHub adding a managed Arm64 runner, the project is easier to support this rapidly growing and exciting cloud-native application architecture.

The above is the detailed content of CNCF Triggers a Platform Parity Breakthrough for Arm64 and x86. For more information, please follow other related articles on the PHP Chinese website!