The background,

In the industry’s current cloud native practices, the “build once, deploy anywhere” mechanism is already prevalent. With containerization and Docker, we can build applications and services for any environment and configure them at run time.

There are some limits to this adaptation, however. Operating systems and applications still need to be compiled to execute on specific architectural types. For example, software compiled for the AMD64 processor won’t run on ARM-based machines, and software built for Linux won’t run on Windows.

Docker meets the requirements of multi-CPU architecture for container applications by supporting multi-arch images. You can build separate images for each schema that you want to support, and then bind all images as a collection in a list of Docker listings. You can then deploy the generated multi-schema image by its name and label — the Docker client will automatically select the image that matches the target schema.

Artifactory-based Docker repositories make it easy to build multi-schema images and manage them just like any other Docker image. In this article we will show you how to create and manage multi-architecture Docker images within the development/delivery process flow.

Second, build multiple architecture mirrors

  • Multi-architecture Mirroring

In our example, we need to create an application that can run on either of the following two processor architectures under Linux:

  1. X86-64 environments, such as Linux desktops;
  2. Arm-based A1 instance on AWS EC2.

To be able to run on either, we need a multi-architecture image that supports both the AMD64 and ARM64 architectures.

  • Create multiple schema images based on Buildx

First, our DockerFile must be configured to create sample images based on the desired schema, as follows:

ARG ARCH=

FROM ${ARCH}debian:buster-slim

RUN apt-get update

&& apt-get install – y curl

&& rm -rf /var/lib/apt/lists/*

“Curl” ENTRYPOINT []

If we run the Docker build command with this DockerFile and set the ARCH parameter with the –build-arg option, we can build a separate image for each required architecture. We then need to build a separate list of listings (using the Docker manifest command) to bind them to a multi-schema image.

There is a simpler, more recommended approach. Use the Docker CLI Buildx plug-in (see docs.docker.com/buildx/work…). , you can directly create a multi-architecture image, and push the constructed multi-architecture image to the Docker warehouse in Artifactory by using the same Docker CLI command line. As follows:

$ docker buildx build

–push

–platform linux/amd64,linux/arm64

–output=type=image,push=true,registry.insecure=true

–tag myartifactory/docker-local /multiarch-image:tag .

If you’re using Docker Desktop on Mac or Windows, Buildx is already installed. If you use Linux, you can install Buildx from GitHub.

(See github.com/docker/buil…)

  • Multi-schema images in Artifactory

Here is how the multiarch-Image multischema image created in the previous section is stored in Artifactory in a Docker repository called Docker-local.

► Docker checklist list

The docker-generated manifest list (list.manifest.json) is a multi-schema image “manifest list”, also known as a “rich list”, which identifies the Docker image in the collection and the architecture (operating system and processor combination) that each image runs on.

When the Multiarch-Image application runs, the Docker CLI will first pull the manifest list and then use it to select which image to pull and deploy to match the operating system and architecture of the destination.

► Architecture mirroring

Each image of the supported schema has its own label that can be addressed, which is created by Artifactory by combining the publication label with the schema name. Since our example uses the publication tag “tag”, the labels for schema images are tag-Linux-AMd64 and tag-linux-arm64.

Each image also has its own manifest that identifies the layers that comprise it.

Three, upgrade multi architecture mirror

Once your multi-schema image is located in Artifactory’s Docker repository and has passed testing, you can advance the image to the next maturity Docker repository, just like any other artifact repository.

The following JFrog CLI command promotes the multi-architecture image we created in the Docker-local repository to the Docker-target repository:

$ jfrog rt docker-promote –copy

multiarch-image docker-local docker-target

As with any normal Docker image, you can limit promotions to a tag in the image. If you choose to rename the label in the promotion, it will rename every schema in the multi-schema image. The command is as follows:

$ jfrog rt docker-promote –copy

– source – the tag “latest” – target – the tag “latest – new”

multiarch-image docker-local docker-target

Four,

Delivering multiple architecture images throughout the software development life cycle (SDLC) can mean more complex testing and validation, as each supported architecture may need to be validated individually on its target platform.

But with Artifactory’s support for multi-schema mirroring, the best practices of your workflow will be preserved. You can still build once and then advance your immutable, multi-architectural images during development, test, and production.