Hacker News new | ask | show | jobs
by mshekow 1054 days ago
I also looked at this topic, see [1]. Some points are similar to the article posted by OP. My findings were:

- Docker Desktop and Docker engine (CE) behave differently, e.g. bind mounts, or file system ownerships.

- CPU/Platform differences (ARM vs. AMD64): many devs don't realize they use ARM on their mac, thus ARM images are used by default, and tools you run in it (or want to install) may be have differently, or may be missing entirely

- Incompatible Linux kernel APIs (when containerized binaries make syscalls not supported by the the host's kernel, for whatever reason)

- Using the same version tags, expecting the same result (--> insanity, as you know it :D)

- Different engines (e.g. Docker Desktop vs. colima) change the execution behavior (RUNNING containers)

- Different build engines (e.g. kaniko vs. BuildKit vs. buildah) change the BUILD behavior

For anyone who is interested: more details in [1].

[1] https://www.augmentedmind.de/2023/04/02/docker-portability-i...
1 comments
nerdponx 1054 days ago
I think a lot of this comes down to a broader difference between Mac/Windows Docker Desktop and "plain" Docker on Linux. The former is actually backed by a VM, so a lot of the painless simplicity comes from having a true virtual machine involved, rather than just a layer of namespacing.

A lot of people are in here complaining about how Docker is not reproducible enough. But reproducibility of image builds is a matter of diminishing returns, and there are other problems to worry about, like the ones you are pointing out.

Speaking of which, it's probably good to get in the habit of installing some Linux OS in a VM and trying to run your container images inside that (with "plain" Docker, no inner VM), before pushing it to your cloud host and waiting for it to fail there.

link