Some people here actually want and need Docker features. For me it's the ability to run from a given image and know that I've got _exactly_ the same image that other developers have. Reproducibility.
I might be wrong, but I think his point is that by the time you're running a linux VM for docker, why not go ahead and get the rest of the tooling for free?
Docker can still be run in the VM just fine, for cases where you want a reproducible build environment.
I do this at any company that lets me (and by lets, I mean doesn't explicitly forbid) - They all give me a Mac, and the first (and sometimes only) thing I install is usually vmware fusion, followed by the linux distro of my choice (Arch).
>for cases where you want a reproducible build environment.
Or just create your reproducible build environment as a QEMU VM image instead of a docker file. That way you only have to install a VM image, instead of install VM image/OS + install Docker + install your Docker file.
Containers solve a different problem than vms. The biggest issues (at least for me) are
1. The second a dev starts using that VM, it's no longer reproducible. The goal of docker is that a developer can create reproducible images as a part of normal development.
2. I won't be running that QEMU vm in production, but I might very well be running the exact same container image in both development and production.
Digests cryptographically guarantee that you get the correct content, which prevents both malicious tampering (mitm, stolen credentials, etc) or accidental mutations. This is why "immutable tags" are a bad substitute and an oxymoron.
There are also better caching properties when using content addressable identifiers. For example with kubernetes pull policies, using IfNotPresent and deploying by digest means you don't even have to check with the registry to initialize a pod if the image is already cached, which can improve startup latency.
> There are also better caching properties when using content addressable identifiers. For example with kubernetes pull policies, using IfNotPresent and deploying by digest means you don't even have to check with the registry to initialize a pod if the image is already cached, which can improve startup latency.
While agree on the unquoted part, this is true also for human-readable (aka mutable-that-should-be-immutable) tags, when that pull policy is set (which is by default for everything that is not `latest`)
