Hacker News Reader

Comment by ogre_codes | Hacker News Reader

If you have multiple developers working on the same product, you want each developer to have their own environment. In my experience, for cost, convenience, and productivity its made most sense to do this with local Docker. It also eliminates a lot of connectivity issues with running on a remote machine.

> In my experience Docker Desktop has been such a resource hog

Not sure if this is related to the specific project or what, but I haven't had tons of trouble with docker being a big hog.

That said, they are significantly changing the way Docker on M-Series CPUs works, working directly with Apple's Virtualization Framework which I believe improves performance.

View on HN

Here is an example thread of many users experiencing resource utilization issues with various root causes:

https://github.com/docker/for-mac/issues/3499

Some root causes have been addressed. If they are significantly changing the architecture with the Apple Silicon rollout, I'm very much looking forward to see if that improves things!

I wasn't trying to argue the point about Docker being a resource hog! I've always run Docker on computers with lots of RAM or with fairly simple images (or both sometimes) so it's likely I've just dodged that bullet.

Docker for Mac is a really bad resource hog for devs at my company. It's a common refrain that comes up again and again.

We build a SaaS web app with a MERN stack deployed to AWS. Local development usually involves running about 12 containers.

Personally, I got fed up and installed Ubuntu 20.04 in Parallels and have been running the Docker containers there for several months. What a night and day difference... the entire VM sits at about 13% CPU when idling, whereas Docker for Mac would whine my fans at around 150% CPU continuously when idling, and spike up to 300+% when clicking around the app.

Back in the old days, each of those developers would just use telnet and X Window sessions on the same UNIX box, which the cloud is nothing else than the same stack in new clothing.

The main resource issue is because Docker runs in a VM, it can't share memory with the OS. So it's using the configured amount of memory (2GB by default) whether you're running busybox or an entire Kubernetes cluster.

I think the Virtualization Framework mitigates that to some extent. The way Docker was required to run on x86 it needed a Linux VM which I believe the Docker images ran atop. Under the new model, I think they run on bare metal and share memory.

Regardless, for me the cost of adding enough RAM to support Docker is less than the headache and expense of spinning up Docker images in the cloud.

M1 Docker still needs a Linux VM, Virtualization Framework is just a different way of doing that. I'm not aware of any VM that can share memory with the host, but maybe Apple has some black magic up their sleeve.

Yeah, fundamentally Docker is Linux on Linux. If you are running Linux on MacOS, it's not Docker, it's a VM. So Docker installs are Linux Docker Image -> Linux VM -> MacOS Virtualization Framework.

For that reason alone, I suspect Linux will always be the best host system for Docker images.

> I suspect Linux will always be the best host system for Docker images.

It seems that for more than 1-2 containers, running Docker inside a Linux VM on macOS is better resource-wise.

On Windows Docker uses Windows containers for Windows images and WSL for Linux images, so whatever is the best host depends on the images.

WSL is a Linux VM, though.

Seems like Apple's Virtualization Framework supports some sort of memory ballooning mechanism (https://developer.apple.com/documentation/virtualization/mem...), which could hopefully enables in the near future dynamic memory support like Docker Desktop on WSL 2 is able to do (if it's not already the case, I haven't tried the M1 preview).

Reply on news.ycombinator.com