Deeply Understanding the Different Between Portability, Compatibility, and Supportability

Let’s dig into these three concepts a bit deeper:

Portability

Since the OCI standard governs the images specification, a container image can be created with Podman, pushed to almost any container registry, shared with the world, and consumed by almost any container engine including Docker, RKT, CRI-O, containerd and, of course, other Podman instances. Standardizing on this image format lets us build infrastructure like registry servers which can be used to store any container image, be it RHEL 6, RHEL 7, RHEL8, Fedora, or even Windows container images. The image format is the same no matter which operating system or binaries are in the container image. Notice that Skopeo can download a Windows Nano Container Image, uncompress it, and store it in .local/share/containers/storage/ (rooteless in this case) even though this is on a Fedora Container Host:

skopeo --override-os windows copy docker://mcr.microsoft.com/windows/nanoserver:1903 containers-storage:mcr.microsoft.com/windows/nanoserver:1903

The image is now available in the local storage:

skopeo inspect containers-storage:mcr.microsoft.com/windows/nanoserver:1903

Output:

{
"Name": "mcr.microsoft.com/windows/nanoserver",
"Digest": "sha256:14b9bc111f8cd94dc0c807d4c4735d973d4d0c2138c61ae416c8f032c07dee89",
"RepoTags": [],
"Created": "2019-11-02T08:26:36.163Z",
"DockerVersion": "",
"Labels": null,
"Architecture": "amd64",
"Os": "windows",
"Layers": [
"sha256:e145b606dfc22d200d5cb05f3ac1d69fdd0dd13b1e2d906c7ebaf154e6a694ed"
]
}

The image is cached locally, but you won’t be able to run it on Linux.

Compatibility

This addresses the content inside the container image. No matter how hard you try, ARM binaries in a container image will not run on POWER container hosts. Containers do not offer compatibility guarantees; only virtualization can do that. This compatibility problem extends to processor architecture, and also versions of the operating system. Try running a RHEL 8 container image on a RHEL 4 container host — that isn’t going to work. However, as long as the operating systems are reasonably similar, the binaries in the container image will usually run. Now, let’s try and execute that Windows Nano image on Fedora:

podman run -it containers-storage:mcr.microsoft.com/windows/nanoserver:1903

Output:

Error: unable to find user ContainerUser: no matching entries in passwd file

Notice that this image won’t run because the image config is not compatible, even though the image layers are portable and cached locally. The ContainerUser is a Windows user which Podman doesn’t find in a passwd file in the image. Even if we added an /etc/passwd file, the binaries would fail to run because they are Windows binaries, not Linux ELF binaries. This is a compatibility problem, even though the image is portable.

Supportability

This is what vendors can support. This is about investing in testing, security, performance, and architecture as well as ensuring that images and binaries are built in a way that they run correctly on a given set of Container Hosts. For example, Red Hat supports RHEL 6, UBI 7, and UBI 8 container images on both RHEL 7 and RHEL 8 Container Hosts (note that RHEL CoreOS is built from RHEL 8 bits). Red Hat cannot guarantee that every permutation of Linux Container Image and host combination on the planet will work. It would expand the testing and analysis matrix at a non-linear growth rate. To demonstrate, run a Red Hat Universal Base Image 8 (UBI) Container Image on a RHEL 8 Container Host:

cat /etc/os-release | head -n 4

Output:

NAME="Red Hat Enterprise Linux"
VERSION="8.0 (Ootpa)"
ID="rhel"
ID_LIKE="fedora"

Now, run it in a container:

podman run -it --rm ubi8 cat /etc/os-release | head -n 4

Output:

NAME="Red Hat Enterprise Linux"
VERSION="8.1 (Ootpa)"
ID="rhel"
ID_LIKE="fedora"

This demonstrates a completely supportable image and host combination, which is also compatible, and portable.

Conclusion

With Podman running a UBI 8 Container Image on a RHEL 8 Container Host, we have:

1. Portability – we can move the image anywhere we want. This also allows you to share infrastructure like Registry Servers.
2. Compatibility – they are designed and engineered to work together (See: Engineering compatibility with the Red Hat Universal Base Image). Compatibility is based on hardware architecture, operating system (Linux versus Windows), distribution of Linux (Ubuntu versus RHEL), and even age of the Linux distro in the container image (very old images may not work on newer hosts, while very new images may not work on older hosts).
3. Supportability – Red Hat can fix problems in the Container Image, Container Host, Container Engine, and the Linux kernel to make sure that all of these components work together over a defined life cycle. Supportability is based on a vendor’s ability to release, patch, version, and test a set of components together. Also, high quality support is based on a set of components that are designed and engineered to work together.

If you would like to understand Portability, Compatibility, and Supportability, check out this lab: https://learn.openshift.com/subsystems/container-internals-lab-2-0-part-1. Originally posted at: https://crunchtools.com/deeply-understanding-the-different-between-portability-compatibility-and-supportability/