Hacker News new | past | comments | ask | show | jobs | submit login

I've been using Minikube's docker-engine and haven't missed DockerForMac for some time now.

Minikube sets up a Linux VM using MacOS Hypervisor.

It even has a convenience command to configure docker-cli/docker-client.

  $ minikube docker-env
    export DOCKER_TLS_VERIFY="1"
    export DOCKER_HOST="tcp://"
    export DOCKER_CERT_PATH="/Users/wibble/.minikube/certs"
    export MINIKUBE_ACTIVE_DOCKERD="minikube"

For corporate situations where MITM proxies are used, you can inject/trust custom CAs using

  $ minikube start --embed-certs

Copy Paste install instructions for macOS: https://gist.github.com/rmetzger/e556bfda8082bceeae6a32e7e02...

Yeah, I used minikube for local dev on k8s services and ended up just using it for all Docker stuff after a while. It is slightly less ergonomic than Docker for Mac though especially with respect to DNS and network issues. For instance, the minikube VM and any containers running in it cannot by default use the host machines VPN, so if you have to connect to an external service over your corporate VPN then you need to do some extra config (which isn't very well documented) to make it work. And the setup I ended up using was to use the VPNKit socket that was part of Docker for Mac to make it work. Now VPNKit is also OSS so I'm sure you can get it to work without Docker for Mac at all but it's also not trivial.

Before Docker Desktop there existed a solution called docker toolkit that worked exactly like this. The only problem is that occasionally internal corporate networks will use the same ip address and you have to customize that by building your own docker engine.

But what minikube backend are you using for this? The preferred one is Docker and all the others are also paid on Mac.

> all the others are also paid on Mac

Hyperkit is open source software that works on macOS.


Virtualbox is also a free (as in beer, and mostly libre) driver that works on all of windows/linux/macOS

Beware of VirtualBox. While part of it is free, it's not very useful without the extension package. This package is easy to download on the same website as VirtualBox, but... it's not free.

Even better Oracle tracks the ips that download this extension and after a suitable amount of time they will come knocking on your company's door asking for an insulting amount of money (e.g. more expensive than VMware) or get sued. You need to read the fine print of the additional Eula printed in really small letters on the VirtualBox website to figure out the extension isn't free. It's almost a honeypot tactic. Scummy.

I don't know how Macs fare, but on Linux the extension package is not really a great feat, mostly adds RDP and some faster USB modes, but USB passthrough is marginal at most anyway.

Hyperkit is docker for mac's backend though, so... whatever bugs that upset people are probably still present.

Wait, so you're running your app on virtualized Linux inside Docker inside Linux inside Virtualbox inside native MacOS?

That's a reductive way to phrase it, but more or less yes.

It's arguable if the container is "virtualized linux" as they all share a single linux kernel. In reality there's one virtual machine, one linux kernel, and many linux userspaces (one per container), which is kinda the whole point of containers.

Over docker+linux, the virtual machine is the only additional layer.

fwiw, I personally don't use macOS, so I've only got virtualized linux (containers) run by docker running on linux running on my hardware.

Are you trying to make a point or something here? Like, yes, we've built layers of abstraction that include different types of virtualization (VMs and containers), and they compose. Is that all you're observing?

> Are you trying to make a point or something here?

Nah, just curious/intrigued by how these stack.

OS-level virtualization is very much a thing. I'd be interesting to compare this to the approach taken by Docker Dekstop for Mac. I bet they do something quite similar (hypervisor-based virtualization like Virtualbox) - nothing fancy like WSL1 that I believe runs a sort of "tortured" Linux kernel inside the NT kernel.

WSL1 didn't run a Linux kernel at all - it was implementing the Linux user-space API over the Windows NT kernel. Well, some of it - not enough to run Docker, for example.

Docker on Windows and Mac does the same as what is described above - it runs a Linux VM and runs the docker server inside that, and then does a little magic to expose native OS paths and so on to that VM. On Windows, it uses WSL2 by default now, but WSL2 is also a Hyper-V VM in the end, with some Windows magic to blend it more nicely in Windows workflows.

That’s how it has to work when there’s a kernel mismatch from host to guest. You’re implying more layers than there actually are.

- MacOS running a hypervisor

- A Linux VM with Docker installed.

- A Linux container running on that VMs kernel.

Containers on Linux aren’t virtualized (normally, you could use runV I suppose if you wanted). The only overhead is the extra disk space to extract the root fs of the container image and the namespacing.

You can run systemd in podman or LXD containers.

LXC was the first container implementation on Linux and uses full Linux systems similar to a VM.

It's spinning pinwheels all the way down

I use Linux and I have no idea what y'all are talking about.

I’m also using Hyperkit w/ minikube, and after some heavy setup automation it works pretty great. What I worry about, though, is what I’m going to do when I switch to a Mac w/ Apple Silicon. AFAICT Hyperkit is x64-only.

I am using "hyperkit"

Available options:

  --driver='': Driver is one of: virtualbox, parallels, vmwarefusion, hyperkit, vmware, docker, ssh (defaults to auto-detect)

Hyperkit, which is incidentally also what Docker for Mac uses.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact