On Mac there is simply the additional step of Docker Desktop running a Linux VM for you, so that it has something to run the containers in.

(EDIT: On Windows that's also an option, or you set it to run against Windows' native container support - which then can only run windows-based images. But really, usually people mean "on Linux" when they discuss how Docker works)

Hmm, what kind of VM? By default, my M1 Mac will only run arm64 software under Docker. If an arm64 build is not available for something (ie x64 only), I can change the architecture setting, and only then will Docker attempt to run the process using Qemo. If Docker on Mac is already a VM, why does it need Qemo? Why does the Docker VM not emulate across architectures?

> Why does the Docker VM not emulate across architectures?

Because it's easier to use a CPU emulator on just one kernel a single VM than manage multiple VMs. So you can use QEMU just like Macs already use Rosetta for x86_64 macOS binaries on aarch64 macOS.

Linux further has a built-in feature for running 'foreign' (different CPU architecture, but still Linux) binaries (and more!) in a transparent way, so if you set this up in the VM you can invoke those x86_64 binaries as if they were native, without really thinking about it: https://www.kernel.org/doc/html/latest/admin-guide/binfmt-mi...

You can also use it with DOS and Windows binaries, or via Apple's Rosetta for Linux instead of QEMU for CPU emulation (and there are some other open-source competitors in that space as well). Pretty neat!

VM != cpu emulation, but fwiw I hear the opposite: M1 mac runs aarch64 containers natively, and emulates x64 containers. Mostly this works until it becomes confused and tries to run an x64 container without emulation.

> M1 mac runs aarch64 containers natively, and emulates x64 containers

Macs don't run any containers natively, because macOS doesn't support containers and doesn't have a Linux ABI translation layer (some operating systems, like Illumos and NetBSD, do, and you can run Linux binaries on them almost like you can run Windows binaries on Linux via WINE). On M1, when you run aarch64 containers under Docker, you are 'merely' emulating an environment for a Linux kernel to run in and you can pass certain aspects of your CPU through. But when you do the same with x86_64 containers, you are additionally 'emulating' (via a translation layer) x86_64.

Hopefully some day macOS will have its own truly native containers, like Linux and Windows do. That could be a serious savings for containerized macOS development environments, because they will be way more efficient than Docker Desktop on Mac currently can be. For now, the only way to get that kind of efficiency is Nix— which is great and better suited to that use case than Docker, but underutilized at many organizations.

Probably even then people will still use virtualized Linux, since that's a closer environment to where apps will usually run in prod. But at such an org I'd argue for using macOS containers for local development, should they ever come to be available. The efficiency gains are well worth it IME.

Yes I got the architectures messed up, meant what you said.

I'd guess so they get away with one VM (and have all the containers in one VM and thus under one kernel, for networking them etc?)? One arm64 VM, using qemu to run x86 when needed, achieves that.

Let's say you run: docker run -it ubuntu:22.04 bash , then roughly this happens:

There's a Linux VM hosted on your mac. There's a docker daemon running on your mac. The docker command process above communicates with said daemon which has the ability to exec processes inside the Linux VM. It uses that capability to exec runc (or something similar) which in turn starts a bash process inside a namespace inside the VM.

If you run some other container the same thing happens, using the same VM.

So the secret is : docker isn't running anything on your mac, it's running stuff on a Linux VM hosted on your mac.

Docker in Mac runs via a VM, so you wouldn't be running it a process under your Mac, necessarily.

Adding to what the others are saying about Docker running inside a VM on Mac:

When it comes to running for example an Ubuntu docker container, it would share the Linux kernel running in the VM with other containers on the same host. The "Ubuntu" is the distribution packaged specifically for containers, meaning that the regular Ubuntu packaged kernel is not used and neither is the init system because the Linux distribution container images are meant to containerize single applications and traditionally do not need the concept of "services".

I'm sure it's possible to run systemd inside a container, just as some people run Cron and even X11 inside containers.

When people talk about containers they almost always mean Linux containers, i.e. a collection of features in the Linux kernel that allow creating the illusion of containers.

Needless to say, this doesn't make any sense on macOS because there's no Linux kernel. Therefore you need a Linux VM to run Linux containers on macOS.