Main

Simple to set up. Easy to use. Powerful integrations.


Ready to build better conversations?

Aircall runs on the device you're using right now.


Blog

How to Support Multi-Architecture Container Images

In the last years, containers have successfully become one of the most essential tools used to develop and run applications and Aircall is no exception. In fact, containers are involved in all the aspects of our work.

Aircall, the cloud-based phone system of choice for modern businesses, has always kept growing exponentially. Therefore, we need to implement more and more architectures to develop our product. Which means that it’s a real challenge to manage all the different containers during the development process.

Furthermore, this challenge became a real concern for our SRE team as we started migrating our AWS Lambda functions to Arm64 runtime because we needed to migrate most of the containers involved in Lambdas CI/CD to Arm64.

After looking for ways to make this transition easier, we decided to start using multi-architecture container images. In fact, they provide an easy way to manage containers with different architectures and don’t require making big changes to our existing process.

What are multi-architecture container images

Multi-architecture container images are container images that are compatible with different architectures at the same time. These images bring more simplicity when :

First, let’s dig deeper into the container images in general and get a better view of what they are. 

. Each container image has one or more layers of file system content. The manifest specifies the layers that make up the image as well as its runtime characteristics and configuration.

When you first pull a container image for use in Docker or another container runtime, two things happen:

1. the manifest is pulled locally based on the specified image repository and tag.

2. the manifest is used to assemble the container file system from the layers specified.

 command to see the manifest of any local image in your Docker development environment. As you can see, platform characteristics such as architecture and operating system are clearly specified by the image manifest.

With multi-architecture image support in our container repository, it becomes easier for us to build docker images supporting multiple architectures and operating systems and refer to them by the same abstract manifest name. This is achieved through the support of an image specification component known as a 

) allows for the nested inclusion of other image manifests, where each included image is specified by architecture, operating system, and other platform attributes

The container engine responsible for creating the container pulls from the registry the correct layers for the compute environment where it’s running based on the values in the manifest list.

 command to see the manifest list of your docker image. As you can see, the manifest list contains the different manifests available for your image.

In Aircall, we are using Amazon ECR to store our container images. Amazon ECR, as most of the repository services of major cloud providers, is compatible with multi-architecture images.

 to build our container images. Kaniko is a tool that allows us to build our images from a Dockerfile, inside a container or Kubernetes cluster.

Despite being a great tool to build container images, Kaniko doesn’t support the creation of manifest lists (issue link : 

https://github.com/GoogleContainerTools/kaniko/issues/786

 ). As a consequence, we had to use another tool for that purpose.

 is the tool that we decided to use. It’s a command line utility used to view or push multi-platform container image references.

Manifest-tool is pretty straightforward to use, having 2 basic commands :

Multi-architecture container images were easy to support and we only needed to add a step in our Gitlab CI pipeline, which is used to create docker images.

The new step added is used to create a manifest list using the manifests of each architecture that are already built and pushed. This step has been added without breaking our existing process.

This is our process with the new step added to support multi-architectures:

Build docker images for each architecture

 using Dockerfile and Kaniko. We also have a fleet of Gitlab Runners with different OS and architectures.

 of each architecture using different tags (eg: latest-amd64)

 assembling the different images already pushed into one common tag (eg: latest)

Now, as the multi-architecture container image is used, we can use it inside our code and our gitlab-ci pipelines using that common tag “

This is our Gitlab CI job that we added to create multi-architecture container images.

As you can see, this step has been added without breaking the existing workflow.

As an example, we will look at one of our CI/CD jobs created using Gitlab CI in order to deploy lambda functions to the different runtimes (x86 and arm64) using AWS SAM CLI.

Before implementing multi-architecture images, we had to create a new environment variable in each of our Gitlab runners to define a tag suffix that will be used to select docker images from our ECR repository.

Then, when we needed to spin a new container to run our CI/CD jobs, we had to pull the correct docker image using a tag defined by that environment variable. For example, this is an extract from a gitlab-ci file used to run AWS SAM deployment jobs:

Now, using the multi-architecture images, we no longer need to create that environment variable in our Gitlab runners nor to add a suffix in the image tag. The pipeline is becoming easier to maintain as it is common for all the different architectures.

To summarize, supporting multi-architecture container images was both a simple and a rewarding task, as it simplifies the use and the management of multiple architectures for your container images. The transition was also very smooth as we didn’t break the tag convention already existing in our teams, but we enriched it.

https://github.com/opencontainers/image-spec/blob/main/image-index.md

2. Introducing multi-architecture container images for Amazon ECR : 

https://aws.amazon.com/blogs/containers/introducing-multi-architecture-container-images-for-amazon-ecr/

Application error: a client-side exception has occurred while loading aircall.io (see the browser console for more information).