Is not this the main way to speed up Docker on Mac: use a beefed up Linux Virtual Machine (VirtualBox, UTM, tart) and run Docker inside this Virtual Machine?
the 'DOCKER_HOST' variable (and the fact that all SDK's seem to support it) is honestly the greatest bloody thing in the entire ecosystem.
My workflow for the past 3 years with Docker has been: set up some desktop machine somewhere, configure docker, configure ssh like normal: set DOCKER_HOST=ssh://<tailscale_ip> on my laptop.
Docker responds as if it's local, but I get absurd build/fetch speedup (since the wired connection is faster than Wifi) and it's not running inside a slow VM.
Recently I've been using colima on my Mac natively, but I keep reaching for the DOCKER_HOST option.
You just access everything on the docker machines IP instead of localhost. Dev servers may need an additional parameter for that, it i don’t see any big problems.
This assumes you want a distinct storage drive within your VM.
Many developers prefer to code in their host OS but run the image via Docker for Mac. They also want instant real-time code changes to appear inside the running Docker image. I suppose you could have some of the disk live within the VM and the code portions be memory mapped or Rsynced. I haven’t thought through the downsides.
There was a project for that called docker sync (it could use of 3 mechanisms (one being rsync) to continually keep the files up to date in the container. The problem I found was it would just randomly stop syncing with no warnings or errors of any kind. It was very flaky.
Nowadays make sure you use their new virtual machine thing in docker for Mac and add :cached in your compose file of any mounted volumes and I found that alleviated my issues. It used to be really bad though.
This doesn’t address the root problem. If you want the FS features that the “””native””” Docker Desktop provides, you end up with the same drawbacks re performance.
