The world is multi-arch and you can easily leverage it! This can be beneficial in the current move-to-cloud approach where we have multiple cloud providers with different level of co$ts. Matching the right workload with the right platform can help saving some time and money.
In this post you will learn how you can easily leverage GitHub Actions to create multi-arch images. To learn more about multi-arch containers, take a look here.
Step 0: create accounts in the basic services required.
We are using GitHub to host the source code and the build process and Quay.io host our multi-arch image, so if you decide to follow the steps described here, you must have an account on each service.
Step 1: create a new project and a new robot.
Create a new GitHub project (no explanation required), create your Quay.io repository and create your Quay.io Robot which will be used to pull/push your multi-arch images from/to the container registry (ensure you set the write permission to your robot, like the picture below).
In you new GitHub project, create a new set of secrets to avoid exposing the username and token of your Quay.io robot. Go to Settings > Secrets > New repository secret and add a variable for the password and another for the user’s name, like seen below:
Once those aforementioned steps are done, we can proceed.
Step 3: create the Dockerfile of your application.
Push the Dockerfile of you application which will be used to create your multi-arch container.
IMPORTANT: to create multi-arch image, you must ensure that the base image you are using is available for your target architectures. In this example, we are building a multi-arch image to run on x86_64 and ppc64le and the base image we are using (Ubuntu), is available for each architecture.
The content of the Dockerfile is:
FROM ubuntu:20.04
CMD echo "Hello World from a container running on $(uname -m);"
Step 4: configure the GitHub Actions Workflow.
In your GH project, create a .github/workflow directory.
Inside the workflow directory, create a new file where we are going to add the build configuration:
The file describes what should happen. It uses some preexisting actions available in GH’s Marketplace, to ease the process:
- actions/checkout@v2: action for checking out a repo.
- docker/setup-qemu-action@master: action to configure Qemu static binaries.
- docker/setup-buildx-action@master: action to set up Docker Buildx.
- docker/login-action@v1: action to login against a Docker registry, Quay.io in our example.
- docker/build-push-action@v2: action to build and push Docker images with Buildx.
It start with the name of the job (multiarch-build) and configuring the machine on which the jobs will run (ubuntu-latest). Then, set the checkout action, configure QEMU static binaries, configure Docker Buildx, login in Quay.io and finally builds and pushes the multi-arch image.
---
name: 'multi-arch images build'
on: push
jobs:
multiarch-build:
runs-on: ubuntu-latest
steps:
- name: add checkout action...
uses: actions/checkout@v2
- name: configure QEMU action...
uses: docker/setup-qemu-action@master
with:
platforms: all
- name: configure Docker Buildx...
id: docker_buildx
uses: docker/setup-buildx-action@master
- name: login to Quay.io...
if: github.event_name != 'pull_request'
uses: docker/login-action@v1
with:
registry: quay.io
username: ${{ secrets.QUAY_USER }}
password: ${{ secrets.QUAY_PWD }}
- name: build Multi-arch images...
uses: docker/build-push-action@v2
with:
builder: ${{ steps.docker_buildx.outputs.name }}
context: .
file: ./Dockerfile
platforms: linux/amd64,linux/ppc64le
push: true
tags: quay.io/rpsene/techu-2021:latest
Once the job is configured, each new merge will trigger a new build (you can customize it according your needs).
And will push it to quay.io at the end of the process:
Finally, you can test your multi-arch image:
That’s it!
p.s: looks like there is a new bug that can require some retries during the build process.
nullpointerexception 