Hacker News new | ask | show | jobs
by bsenftner 1046 days ago
I started using docker a bit late, only about 3 years ago. My big question is if it is common knowledge that Docker Desktop creates a separate VM in which one's Docker Engine runs, not your host running Docker, but that VM inside your host. That separate VM indirection does not appear to be common knowledge, especially for 3rd party developers, because utilities that are supposed to work with Docker only work without Docker Desktop, or are unaware of Docker Desktop's VM and when installed claim there is no Docker on the host. It's really messed up, and as I tried to figure out what was going on I find nobody recognizes this gargantuan difference between these implementations with and without the "desktop" Docker is internally significantly different, requiring completely different runtime configurations for 3rd party integration.
1 comments

> common knowledge that Docker Desktop creates a separate VM

I mean, I know that linux containers only run on linux (please ignore docker for windows which briefly did not need a vm, that is thing of the past now). I don't know if other people know that linux containers only run on linux.

> utilities that are supposed to work with Docker only work without Docker Desktop, or are unaware of Docker Desktop's VM and when installed claim there is no Docker on the host

> gargantuan difference between these implementations with and without the "desktop" Docker is internally significantly different, requiring completely different runtime configurations for 3rd party integration

It's not really that different though. Because docker has a daemon and API, anything that integrates with docker is supposed to talk to the "$DOCKER_HOST" environment variable to run docker containers, see if docker is running and what version, etc etc.

That should be identical whether "$DOCKER_HOST" is pointed at a unix socket on your host, or at a linux vm, or so on.

The implementation of those APIs should be identical.

Do you have an example of a specific utility? Did you not set "$DOCKER_HOST"?

I spent months spinning my wheels trying to get the Tailscale VPN / Traefik / Let's Encrypt automatic SSL cert generation working. Each of the tech support teams at all three of these companies are unaware of that Docker Desktop separate VM. I spent months with support from Tailscale and Traefik, and after I realized the existence of that separate VM and discussed with their support - that VM news to them.

The transition to Docker development is very poorly documented. I've taken two formal classes in Docker, read a book, and have half a dozen Docker projects done and delivered and this is the first time I've even heard one needs to manually set "$DOCKER_HOST". This industry is just a bunch of overly paid amateurs, blindly groping in a dark cave, a cave carved out of money.

Long-time Docker user, am aware of the need for a VM on MacOS, Windows for Linux containers.

I think that one of the reasons many people might not be aware of the VM is because -- in my experience -- Docker Desktop works almost identically to Docker on a real Linux system. I feel like Docker has done a fantastic job at making you feel like it's running natively (i.e. despite running in a VM you can mount volumes close to the same way, you can use the docker CLI from the host, etc.). Additionally, I don't think people realize/care that Linux containers rely heavily on features the Linux kernel provides (interestingly, and less well-known, Microsoft has done a lot of work to provide Windows containers[0], too).

I am curious, though, why in your use-case of Tailscale and Traefik knowing that Docker Desktop runs in a VM would impact anything from a functional standpoint? I.E. why would the VM have even been an important factor to the support teams you reached out to?

> This industry is just a bunch of overly paid amateurs

I think, perhaps a more compassionate view is that everyone is learning and growing and it's difficult to be an expert at literally everything you use in your stack. :)

[0] https://learn.microsoft.com/en-us/virtualization/windowscont...

> I am curious, though, why in your use-case of Tailscale and Traefik knowing that Docker Desktop runs in a VM would impact anything from a functional standpoint?

When using Ubuntu/WSL2, there are not the same daemons running as on the same Ubuntu running on it's own. Tailscale expects one or two, I'd have to dig into my emails to find the specifics, something like no systemd under Ubuntu/WSL2 and Tailscale not checking, just failing. I seem to remember there was more than one daemon expected, which might be present on that other VM but either Tailscale or Traefik know to check or communicate with that other VM and their integration fails. Support's recommendation was to just use a no desktop gui server where everything just works.

Yeah, I get grumpy. I need to check myself better. I realize we're all trying our best.

> When using Ubuntu/WSL2, there are not the same daemons running as on the same Ubuntu running on it's own.

Ah, makes sense. I have encountered some funky stuff with Docker+WSL, especially because I often prefer to use distros other than Ubuntu. It feels extra fragile/added complexity how Docker Desktop on Windows relies on WSL for Linux containers.

Thanks for indulging my curiosity!