Docker portability: 6 important caveats and pitfalls

In this article I present 6 kinds of real-world Docker portability issues, where Docker-based software does not run or build the same way on two different machines. ## Introduction to Docker portability ... **Unfortunately, it’s pipe dream!** Things do *not* always work out of the box. **Let’s take a look at 6 real-life portability issues you may run into, when working with Docker.** ## Docker Desktop vs. Docker Linux engine In production, **Docker engine** (or other container engines) typically only **runs on Linux**. **Developers**, however, **are much more likely to work on Windows or macOS hosts, and use Docker**. Docker Desktop jumps through many hoops (hidden from your eyes) to make this work, running some kind of Linux VM under the hood. *Desktop* **A few features, most prominently**(=making folders on the host accessible in the container) *bind mounting* **are implemented very differently on Docker Desktop (macOS/Windows), compared to Docker engine (Linux).** Let’s take a look at a few caveats related to bind mounting: **The performance of bind mounts on Docker Desktop is much worse than on Linux**. I’ve talked about a few solutions in this article. **There are issues with file system permission issues, exemplary, the** *ownership*of the files. - With Docker engine on Linux, the ownership of files are retained “as is” between host and container. There is no user-ID-remapping, unless you configure it explicitly (see docs). If a folder that you bind-mount contains files owned by the Linux host user with UID=1000, they are also owned by UID=1000 inside the container. And files you create inside the container with the (often default) … ## Incompatible Linux kernels On Linux, processes running in a Docker container make use of the host’s Linux kernel. This kernel basically offers a syscall-interface. Consequently, the binaries packaged into the container make syscalls against the host’s kernel. As this blog post elaborates (in particular: section “The Bugzilla Breakdown”), **in rare cases it can happen that the syscall-interface that the containerized binaries expect does not match the one offered by the host kernel, resulting in crashes (or other weird behavior) that are very difficult to diagnose.** … ## Different container tools or versions **There are many different tools for running and building containers, and their behavior may be different**. Examples where things can go wrong: - One team member uses Docker Desktop version X, the other one uses an older version Y of Docker Desktop. The behavior of the two versions differ (e.g. `not supporting build-secrets yet, in the older version Y)` **docker compose** - One team member uses Docker Desktop on macOS, the other one uses colima on macOS - One team member uses Docker Desktop on Windows, the other one uses Rancher Desktop ## Build problems due to platform or tooling differences **Sometimes building a Docker image only works on specific platforms and tools.** Two examples: - If your `Dockerfile`contains BuildKit-specific syntax, e.g. `(see here for details), then you will run into problems with build tools that do not support such features, e.g. kaniko`