Hacker News Reader

Comment by gigatexal | Hacker News Reader

On Linux how is this done? Raw no virtio or anything?

On Linux you don't need Docker Desktop and and run docker natively without any VMs. FS is managed via overlayfs which provides near native performance.

"Docker for Mac" is actually a full Linux virtual machine. The Docker commands you run on your host mac are sent into the Linux VM, to run the technologies Docker uses ("control groups" and "namespaces" mainly). The Linux VM is hidden as an implementation detail of Docker for Mac, meaning you can't ssh into the VM, you can only interact with it through Docker commands.

On Linux itself, Docker simply uses the same core Linux technologies to create the isolated runtime "containers" using "control groups" and "namespaces." Docker on Linux is basically native speed because it doesn't have to jump through hoops like syncing the VM filesystem with the host Mac's filesystem, which is a major point of slowness and a long standing pain point with Docker for Mac.

You seem to have a good understanding of these containers.

Do you know in simple terms why macOS doesn't have such "native containers"? After all isn't it more linux-like than Windows?

I saw this website that suggests Apple themselves are not providing such a feature... do they see it as a security issue?

https://macoscontainers.org/

It really hinges on these things called "control groups" and "namespaces," which are features of the Linux kernel. The "kernel" is the core computer program that interfaces with the hardware. MacOS has its own kernel. (If you install htop for mac, run htop at a terminal, press "t" to go into tree view, and scroll to the top, you'll see kernel_task, the representation of the kernel).

A "control group" (or "cgroup") is a feature of the Linux kernel that lets you create an environment with a fixed allocation of memory, CPU, and other resources. Aka a controlled group of resources. Whatever runs in here only gets the resources defined by whoever created the cgroup.

The other feature is "namespaces", aka a "process namespace." It's another feature of the Linux kernel that lets you create an isolated namespace for processes to run in. If you're a process running inside this namespace, to you, it looks like you're the only process on the system. You can run multiple processes in a namespace (Docker containers can run more than one process!)

So on Linux, to create a container, you basically use native Linux features to build this isolated environment, and run some process(es) in it. This is also why there are different ways to run containers (BSD jails), really what we're talking about is building an isolated environment.

As far as I know, the Mac kernel doesn't have these same features to create isolated environments, which is likely why Docker for Mac went with a full Linux VM, which includes the kernel. This is approaching the limit of my knowledge. I don't know what the Mac kernel is missing or what gaps or proposals there are to create a container-like environment. I also haven't worked with BSD jails or other technologies so I don't know how portable containers are between systems, if at all.

Thanks for the excellent explanation!

MacOS is based on a Mach kernel with a BSD userland. It’s unixy but containers are a Linux thing based on namespaces and cgroups among other things all of which are Linux kernel primitives.

BSD has jails which are similar but different.

So the answer is MacOS doesn’t offer containers like you know them because it’s not linux hence Docker for Mac spins up a VM.

Ok so you mean it's something that's lacking at a much more lower level of the OS?

Yes. Windows offers Linux containers, via thin Hyper-V layer and Windows containers can be hosted in 2 min different ways.

This is about making the same files accessible inside and outside a container. Docker does that by bind mounting files from outside of the container's file tree into it. Bind mounts are just a way to provide a different file path to access an existing directory. It has zero performance cost.

The reason Docker Desktop and similar solutions need to come up with these different complicated solutions is that they want to share files between containers running inside a Linux VM and the host system. So they need some kind of way of syncing the files.

Ahh thanks for clarifying everyone. Makes sense. I didn't know overlayfs is near native, cool! I guess I wasn't doing too much file io to notice the containers being slow or perhaps I just got used to things being slow. Either way, glad to see this improved for folks not using Docker on linux distros.

Reply on news.ycombinator.com