Hacker News Reader

Comment by new_realist | Hacker News Reader

Does OSX offer reasonable container technology? chroot?

macOS has a native hypervisor framework, Docker and xhyve uses it.

https://developer.apple.com/documentation/hypervisor https://github.com/moby/hyperkit

A hypervisor is not exactly a container. Definitely not in the Linux sense. It may be more secure, but it is also slower.

Further, there's no decent solution for shipping a macOS container image to run in a VM. Linux, yes, Mac, no.

Finally, good luck getting your virtualized macOS app to interact reasonably with your main OS (no drag and drop, no OpenGL, etc.).

I would rather chroot.

How much slower?

Not much slower than, say, Hyper-V or Virtualbox or other hypervisors that live alongside a general purpose desktop OS. Remember, they're using the same Intel chips and VT-d and such as anything else; as long as you have enough CPU power it's going to run fine.

IIRC the Docker implementation for OS X runs a tiny, carefully-configured Linux VM transparently in the background. This isn't that dissimilar from the Windows Subsystem for Linux from a user standpoint.

I've done plenty of Docker work on OS X; the only real weirdness is that you're running Linux in the containers and OS X outside. Eventually, though, before switching completely to a native Linux desktop, I moved deeper into the containers and would barely ever see the OS X command prompt any more.

Our build time on Linux container is 8 minutes, but it's a few hours on macOS using docker containers. I haven't dug into it but the hypervisor seems to be single threading the normally multicore compile.

Primarily disk access is a lot slower, even with Hyper-V. Eg. Compilation suffers from this. But tasks that don't use the disk too much shouldn't be that bad.

Measurably slower than a LXC container, but still much faster than a full VM.

Qemu has a backend too if I'm not mistaken?

In other words, nothing serious.

Does anyone actually use Docker on Mac?

Xhyve is more of a proof-of-concept than a production-ready tool.

> Does anyone actually use Docker on Mac?

What? We use it at work every day for local development, and my previous employer did as well. It has issues, definitely, but they have more to do with Docker than with xhyve.

But doesn’t Docker on Mac run a Linux VM? I don’t think it uses any of MacOS’s isolation features.

It uses Hyperkit: https://github.com/moby/hyperkit

> Does anyone actually use Docker on Mac?

I use it extensively. It is a desktop product however; it you aren't expected to put a swarm of MacBook pros into production.

Unless you want to run CD to the App Store? So fun....

Ah, but if the XServe had not died and datacenters had racks of these things, there'd no doubt be a production quality implementation by now. Shame.

Xhyve is but one of the options for fronting hypervisor.framework.

Calling it “not serious” is quite wrong.

I use Docker on Mac, and know many others who do as well.

I personally know of at least 3 or 4 engineering teams of 30+ developers who use it daily.

>Does anyone actually use Docker on Mac?

Sure, for development tasks.

I think apple fundamentally does not understand containers.

All the interesting container stuff is on other platforms.

It might be out of fear, maybe because apple doesn't want macos to be virtualized.

It would be really nice to have say the current xcode in one container and a dev xcode in another. It would be nice to farm work out to a lot of machines.

or a dockerfile like: FROM macos:10.14

RUN installer xcode... RUN xcode-build myproject

> I think apple fundamentally does not understand containers.

Given that Apple is (or at least was) one of the biggest users of Mesos in the world and have invited me to interview specifically on the back of the operationalization of containers, I'm guessing that the staggeringly bright programmers they've got probably understand containers.

Just a little hunch, you know?

The devops guys need to spread the love to the OS group and ship it with the OS.

Maybe it's another "you're not the target market" kind of thing.

The point I'm getting at is that folks on other platforms have lots and lots of options and apple doesn't provide any.

> apple doesn't want macos to be virtualized.

The macOS EULA explicitly allows macOS to be virtualized if you do it on a Mac running macOS.

> It would be really nice to have say the current xcode in one container and a dev xcode in another.

This is the entire point behind xcode-select. I currently have Xcode-beta and Xcode on side-by-side on my machine, and they pretty much coexist.

Can you run them simultaneously? I've never tried.

Yes, but there are some issues. For pure macOS development it's usually fine, but anything touching the simulator breaks if multiple versions of Xcode try to use it at the same time. I quickly got in the habit of always exiting Xcode before starting a different version.

- "allows" not the same as supports.

- I think xcode-select just modifies a .plist.

It changes a symlink at /var/db/xcode_select_link, and all of the development tool stubs that Apple has placed consult this to see which binary to run. This is pretty much the officially supported way to switch between multiple copies of Xcode.

Containers lose a lot of appeal once you leave the server, and Apple have explicitly abandoned the server market.

They do offer a set of "primitives" for virtualization, which can be hooked into by third-party solutions like Docker if they want to do so.

I imagine you could get pretty far with sandboxing+chroot, but it wouldn’t be docker. You’d definitely be able to prevent stuff in the container from getting out, but I’m not so sure you could reproduce docker’s “VM-like” (I.e. the inside of the container is ~identical to a normal Linux machine, with no need to make stuff compatible) quality.

Singularity recently released a (non-fully featured, but still useful) mac version.

Reply on news.ycombinator.com