31

I wonder why, apart from good old chroot, no implementation of operating system-level virtualization (or containers if you prefer) exists for Mac OS X.

Could it be due to kernel limitations or license restrictions? Or simply no one has yet launched a similar project?

14

A key element required for containerization is isolation of networking and other services, but not just isolation but also virtualization. FreeBSD Jails, Linux "containers" (or more correctly "namespaces"), and Solaris/illumos zones all offer some degree of "virtualization" of these operating system system services.

By virtualization, this means that these servers are available (or potentially available) to things inside the "container", but in a way that protects the other things on the same host outside the container. (For example, a container may have its own TCP/IP stack, with its own IP address, ARP cache, etc.)

OS (operating system) virtualization is how we generally refer to this type of "light-weight" virtualization, where processes think they see a virtual kernel, but are all sharing the same real kernel under the hood; that kernel acts as a sort of hypervisor in ensuring that container/virtualization boundaries are not crossed. (Put another way, the OS services are virtualized.) Compare this to hardware virtualization, where what is virtualized is the hardware -- e.g. devices are emulated in software and presented to an operating system running in the container. This is very powerful, but quite resource intensive -- each virtual machine must have its own copy of the operating system.

Recent macOS has native hypervisor support via Hypervisor.framework which allows software like "XHyve" [A port of FreeBSD’s BHyve] (docker on macOS uses this), but lacks the necessary services under the hood to fully virtualize operating system services.

In truth, a lot of what is needed is probably already present, since the work to provide sandboxes means that there are already logical points where system calls are intercepted and handled differently for different applications. However, that's far from the complete story -- implementing true separate network, IPC, and other namespaces is quite a lot of work.

The best reason for why Apple has not done this is likely the same reason that Apple has not released a platform suitable for running macOS in the data center for many years -- lack of market demand, or perceived lack of market demand by Apple leadership. The desktop and mobile focus where they have focused their attention simply don't need virtual macOS instances that much. (This is sad, because I would love to have virtual macOS support -- for example running macOS on VMs at Travis CI is really time consuming compared to Linux containers).

  • 1
    good answer ... my guess is Apple avoids supporting OSX on the server because it would collapse their MBP market if iOS developers could run a cheap powerful linux laptop and compile their apk on a VPS hosting provider – Scott Stensland Nov 11 '18 at 14:45
5

You'd be surprised - Containers actually are supported - the OS X (and iOS) Sandbox has evolved to use them. They have been introduced in 10.7, and are now de facto standard in 10.10 and iOS 8. In the latter they are more strictly enforced (primarily due to reason of application security), to the point where an app can only see itself , and previous methods of enumerating processes or resources now return container-based results - similar to Linux ipc namespace - but more powerful.

  • 2
    These are sandboxes though, not OS-virtualization (e.g. containers, zones, jails), right? – smdvlpr Feb 17 '15 at 17:54
  • 1
    Docker isn't virtualization either. Containers != VMs. Docker basically corals a bunch of different kernel features, cgroups, chroot, layered file systems, iptables routing and so on, to isolate a group of processes such that the app sees itself as having the system to itself, whilst isolating those environments to improve security and minimize the ability of containers to meddle with each other and the system. OSX containers achieve some of this functionality, but not all. Its probably something that could be implemented by a crafty enough coder however. – Shayne Apr 7 '16 at 5:45
  • 2
    @Technologeeks, can you point to any reference material on containers/sandboxes in OS X? – Ken Williams Oct 19 '16 at 15:56
3

I would imagine the answer to be that no one really wants it. It does seem to be doable. These things are done mainly for one purpose, conserving performance for VPS vendors. And really no one wants a VPS instance to be OS X-based.

  • 5
    Thanks for your point. IMHO there's at least another use case for containers, that is creating development environments. BTW, I've found also this old flame: groups.google.com/forum/#!topic/darwin-dev/6-FP9GCsBG4 – Emyl Jun 30 '14 at 10:57
  • Increased density is a nice side effect of isolating processes into their own namespaces. Containers let you run multiple apps more securely and have greater control over what they can do on the machine. These benefits are used by iOS to enhance security and keep apps from stepping on each other, for example, which has little to do with VPS density. Even single-service machines can benefit from security. There's no density improvement there but containers can still be useful. – GargantuChet Jul 25 '17 at 18:45
2

While it's using "good old chroot(8)", I started a project that tend to mimic docker's behavior on OS X and NetBSD. It's Free-as-in-speech and is available on GitHub. As the README says, this project is neither about security nor production, but will help testing full stacks natively on your workstation.

0

docker (as I understand it ) is only "virtualizing" (layering) the file system and network (cpu / mem are only limited) so all of the same feature should be there but just not marketed the same way.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .