Overview
Building on our exploration of multi-arch pipelines for IBM Power in the previous blog, we now delve into the next frontier: Automation. Automating multi-arch image builds using Continuous Integration (CI) tools has become essential in modern software development. This process allows developers to efficiently create and maintain container images that can run on various CPU architectures, such as IBM Power (ppc64le), x86 (amd64), or ARM ensuring compatibility across diverse hardware environments.
As discussed in our previous blog, multi-arch build pipelines can greatly reduce the complexity of supporting multiple operating systems and architectures. Notably, images built on the Power architecture can seamlessly be supported by other architectures, and vice versa, amplifying the versatility and impact of your applications. Furthermore, automating the processes using various CI tools, not only accelerates the creation of multi-arch images but also ensures consistency, reliability, and ease of integration into diverse software environments.
Methods for automating multi-arch image builds
There are multiple methods for automating multi-arch image builds, but for the purpose of this blog, I’ll cover some of the most popular: Using GitHub Actions, Using GitLab and Using Travis CI.
Automate multi-arch image builds using GitHub Actions
GitHub Actions is a continuous integration and continuous development (CI/CD) tool on GitHub that allows users to automate the build, test, and deployment of code. It officially supports building on x86 and ARM CPU architectures via self-hosted runners.
For detailed information on this topic, refer to the following blogs on IBM Power Developer eXchange:
Automate multi-arch image builds using GitLab
GitLab is a complete DevOps platform that enables developers to perform all the tasks in a project—from project planning and source code management to monitoring and security. It allows teams to collaborate and build better software. One of the most important features GitLab provides is continuous integration/continuous deployment (CI/CD), which developers can use to build, test & deploy their software whenever they push any code changes to their application.
For detailed information on this topic, refer to the following tutorial on IBM Developer:
Automate multi-arch image builds using Travis CI
Travis CI is a cloud-based service that automates the process of testing and building software projects hosted on GitHub repositories.
This section covers all the steps required to automate the multi-arch image builds with Travis CI in both Cross-compilation and native approach.
Step 1: Enable Travis CI
- Login to Travis CI.
- Integrate Travis CI with your repository by navigating to Profile à Settings and click Sync account. Ensure that your repository is now listed under Repositories tab to confirm the integration.
Step 2: Configure Travis CI repository environment variables
- Configure container image registry secrets.
To add environment variables, go to GitHub repository in Travis CI and navigate to More options à Settings à Environment Variables à Add.
REGISTRY_USERNAME and REGISTRY_TOKEN secrets contain credentials to access container image registry from the Travis CI workflow.
- Define container image registry variables.
To add repository variables, go to GitHub repository in Travis CI and navigate to More options à Settings à Environment Variables. Toggle the Display value in build log to ON and click ADD.
Create REGISTRY, REPO_NAME, and IMAGE_NAME variables. These variables, when combined, will form the path for the image being built, for example: `quay.io/pparab/multiarch`.
Step 3: Set Travis CI workflow
- Cross-compilation approach
To begin with, download all the required resources from GitHub.
To automate multi-architecture image builds via cross-compilation, create a Travis CI workflow by adding a file named `travis.yaml` to your GitHub repository.
os: linux
dist: focal
language: shell
branches:
only:
- main
jobs:
include:
- name: Build Multi-Arch Image
arch: amd64
services:
- docker
before_install:
- mkdir -vp ~/.docker/cli-plugins/
- curl -sSL "https://github.com/docker/buildx/releases/download/v0.10.4/buildx-v0.10.4.linux-amd64" > ~/.docker/cli-plugins/docker-buildx
- chmod a+x ~/.docker/cli-plugins/docker-buildx
- docker run --rm --privileged multiarch/qemu-user-static --reset -p yes
install:
- docker buildx create --use --name=multiarch
script:
- docker login -u "$REGISTRY_USERNAME" --password "$REGISTRY_PASSWORD" $REGISTRY
- docker buildx build --platform linux/amd64,linux/arm64,linux/ppc64le --push --tag $REGISTRY/$REPO_NAME/$IMAGE_NAME:latest
- Native approach
To begin with, download all the required resources from GitHub.
To automate multi-arch image builds via the native approach, create a Travis CI workflow by adding a file named `travis.yaml` to your GitHub repository. I’ve shown the commands for doing this on ppc64le below however, the commands are the same for each architecture; simply replace the ppc64le tag with the appropriate architecture tag (i.e., amd64, arm64, etc.).
os: linux
dist: focal
language: shell
branches:
only:
- main
jobs:
include:
- stage: Build specific target architecture images
- name: Build Multi-Arch Image on ppc64le
arch: ppc64le
services:
- docker
script:
- docker login -u "$REGISTRY_USERNAME" --password "$REGISTRY_PASSWORD" $REGISTRY
- docker build -t $REGISTRY/$REPO_NAME/$IMAGE_NAME:latest-ppc64le .
- docker push $REGISTRY/$REPO_NAME/$IMAGE_NAME:latest-ppc64le
- stage: Create and Push Image Manifest
services:
- docker
script:
- docker login -u "$REGISTRY_USERNAME" --password "$REGISTRY_PASSWORD" $REGISTRY
- docker manifest create --amend $REGISTRY/$REPO_NAME/$IMAGE_NAME:latest $REGISTRY/$REPO_NAME/$IMAGE_NAME:latest-ppc64le
- docker manifest push $REGISTRY/$REPO_NAME/$IMAGE_NAME:latest
For more details on this process, refer to customizing the build.
Step 4: Run the Travis CI workflow
The Travis CI workflow is configured to trigger a run on each push commit in the repository. Alternatively, you can manually trigger it by navigating to More options à Trigger build à Trigger custom build.
Step 5: Verify workflow logs
Validate the workflow logs to ensure that they are dependable and accurate. Navigate to Job à Current à Job log to verify that your logs provide a trustworthy record of your workflow executions.
Step 6: Verify image manifest in container image registry
Navigate to your registry and click on Tags à Manifest(latest tag) to validate the container image manifest in a registry, specifically focusing on multi-arch support for ensuring image integrity and security across various architectures.
Step 7: Verify multi-arch container image
Verify the multi-arch container image generated for its compatibility on various platforms.
I’ve shown the process to verify this on ppc64le below however, perform the same for each architecture.
# docker pull quay.io/pparab/multiarch
Using default tag: latest
latest: Pulling from pparab/multiarch
bf8a04663b01: Pull complete
fe5ca62666f0: Pull complete
b02a7525f878: Pull complete
fcb6f6d2c998: Pull complete
e8c73c638ae9: Pull complete
1e3d9b7d1452: Pull complete
4aa0ea1413d3: Pull complete
7c881f9ab25e: Pull complete
5627a970d25e: Pull complete
c5f9bfc1f3ba: Pull complete
Digest: sha256:b7b477815dd7219aa216ed30595471029f06f82e98d59e87e5bcef89b3eb50d1
Status: Downloaded newer image for quay.io/pparab/multiarch:latest
# docker inspect quay.io/pparab/multiarch | grep Arch
"Architecture": "ppc64le",
# docker run -t quay.io/pparab/multiarch
Process started.
Running on linux/ppc64le
Process completed.
Welcome to the Multi-Arch World
This approach ensures that the container image is compatible with multiple architectures, enhancing the flexibility and portability of the software.
Summary
This blog guides you through the process of automating multi-architecture image builds with GitHub Actions, GitLab and Travis CI, offering valuable insights into both cross-compilation and native build techniques. You should now have the expertise and tools needed to craft adaptable container images, guaranteeing the smooth operation of your applications on diverse CPU architectures.