Handling multi platform deployment using Manifest file in Docker

Docker runs on different operating systems (Linux and Windows) and hardware architectures (Intel, Arm, IBM PowerPC and mainframes).

A drawback with this multi-platform support is that one Docker image has to be built for each specific target platform, i.e. a specific operating system and hardware architecture. So, if you want to be able to run your Docker container on both Linux and Windows using Intel 64-bit hardware you must create two Docker images, one for Linux and one for Windows. You also have to create each Docker image using a Docker engine running on the specific target platform.

When using the Docker images, you also have to specify what version you want to use, e.g. the Linux or Windows version. This makes it inconvenient to use together with tools like Docker Compose or a container orchestrator, e.g. Kubernetes or Docker in Swarm mode, since the configuration files (Kubernetes yml files or docker-compose.yml) becomes platform specific.

Projects that do support multiple platforms have resorted to using image names to indicate which platform an image was built for. For example, my-cool-app-ppc64le:latest; or creating a Docker Hub namespace for each architecture, like ppc64le/my-cool-app.

Manifest file

To alleviate these issues, the docker community has come up with what is currently called a manifest list, also nicknamed a multi-arch image, or fat manifest.An individual manifest describes the contents of one image, and a manifest list lets you group multiple images together. After the creation of a manifest list, anyone (from the project owners to their user-base) can use the manifest list name where they once used an individual image name. When a user does a docker pull or docker run, the docker engine does the work of selecting which image to pull based on the operating system and architecture on which it is running. As a result, a project’s users no longer have to worry about finding the name of the image that will work for their platform. The project can have a single name “my-cool-app:latest” to put in blog posts, documentation, and so on. This makes the user experience much more pleasant and intuitive.