> xhyve, Hypervisor.framework, and kvm are all frameworks for creating and running virtual machines
> In contrast, Docker for linux runs using a native container mechanism without using a VM at all
Thanks for pointing this out. As I'm slowly getting familiar with container-based workflows and underlying technology, your statement helped clear up my confusion about the essential differences between containers and VMs.
I found an informative table in Microsoft's documentation for "Containers on Windows", that compares and contrasts the two approaches:
This helped me understand how Docker for Mac using xHyve is different from Docker on Linux with native containers as a much thinner layer with a shared kernel.
Aside from the container/VM architecture, a performance bottleneck of Docker for Mac is (apparently) how mounted volumes work, on the file system level.
---
> macOS doesn't support containers, but it could
According to a random Reddit thread (so, with a grain of salt) I found on this topic:
> Using a shared kernel container (via cgroups, for example) isn't feasible with macOS because of licensing restrictions and because the Linux syscall interface isn't compatible with macOS.
Which seems to imply that there's some fundamental reason why Docker for Mac must rely on VMs, that macOS is not (yet?) capable of providing containers that are as native as on Linux.
They also mention how the file system on macOS has design limitations that make containers more difficult.
> The net result is that performance is probably going to be near-native for light workloads, but macOS depends on other fundamental technologies like APFS which aren't designed for datacenter type workloads.
---
EDIT: Aah, right, this is why a comment higher up mentioned:
> Apple said they were working with Docker to make sure MacOS on ARM is a first class host for Linux Docker containers.
> In contrast, Docker for linux runs using a native container mechanism without using a VM at all
Thanks for pointing this out. As I'm slowly getting familiar with container-based workflows and underlying technology, your statement helped clear up my confusion about the essential differences between containers and VMs.
I found an informative table in Microsoft's documentation for "Containers on Windows", that compares and contrasts the two approaches:
Containers vs. virtual machines - https://docs.microsoft.com/en-us/virtualization/windowsconta...
This helped me understand how Docker for Mac using xHyve is different from Docker on Linux with native containers as a much thinner layer with a shared kernel.
---
According to this article:
Beating some performance into Docker for Mac - https://medium.com/homullus/beating-some-performance-into-do... (July 2020)
Aside from the container/VM architecture, a performance bottleneck of Docker for Mac is (apparently) how mounted volumes work, on the file system level.
---
> macOS doesn't support containers, but it could
According to a random Reddit thread (so, with a grain of salt) I found on this topic:
Docker on the new Mac Big Sur - https://www.reddit.com/r/docker/comments/he0v5c/docker_on_th...
> Using a shared kernel container (via cgroups, for example) isn't feasible with macOS because of licensing restrictions and because the Linux syscall interface isn't compatible with macOS.
Which seems to imply that there's some fundamental reason why Docker for Mac must rely on VMs, that macOS is not (yet?) capable of providing containers that are as native as on Linux.
They also mention how the file system on macOS has design limitations that make containers more difficult.
> The net result is that performance is probably going to be near-native for light workloads, but macOS depends on other fundamental technologies like APFS which aren't designed for datacenter type workloads.
---
EDIT: Aah, right, this is why a comment higher up mentioned:
> Apple said they were working with Docker to make sure MacOS on ARM is a first class host for Linux Docker containers.