[nucleardog]

The reason Docker Desktop for Mac looks like you're running Docker on Linux is because... you are. It's running docker in a linux VM for you.

Similar issues in our environment, and I managed to swap everything over to Rancher Desktop fairly seamlessly as it does the exact same thing. It runs a Linux VM and if you select the "dockerd (moby)" container engine it runs a copy of docker inside of it. So you get a socket with the same docker API implemented... because it's running actual docker. docker compose and everything else work as expected.

The reason we switched is that Rancher Desktop, along with providing a convenient way to run docker, also includes a full k3s install in that same VM. So we can work on unifying some of our stack/configs on kubernetes rather than docker for local and kubernetes for everywhere else. It also opens up using upstream helm charts and things when a developer wants to deploy and try something locally.

It's also free. Open source and backed by SUSE, who also develops and maintains the k3s distribution among other stuff in this space.

[skissane]

> The reason Docker Desktop for Mac looks like you're running Docker on Linux is because... you are. It's running docker in a linux VM for you.

Yes, but that wasn't what I was talking about. Docker Desktop for Mac goes to a lot of trouble to hide the fact that there are two different virtual filesystems involved (Linux vs macOS) and two different networking stacks too. That means scripts which run on Docker for Linux and do stuff involving filesystem/network integration between the host and the container will often work without change on Docker Desktop for Mac. In my past experience, open source alternatives don't offer as seamless integration, they don't do as good a job of hiding the fact that there are two different virtual filesystems and networking stacks, so those kinds of scripts are less likely to work.

[nucleardog]

Don't know your use case that precisely so can't say if it does a "good job" versus just "a job", and it's been a while since I've used Docker Desktop or macos (though about half of our dev team is using Rancher Desktop on macos right now), but as far as I'm aware it's essentially identical.

FS: Rancher mounts your `/Users/$USER` folder in the VM that Docker is running in. It supports virtiofs on macos (not sure if it's used by default though). As far as I can tell, this replicates the default Docker Desktop setup.

Networking Container -> Host: Connecting to `host.docker.internal` works as expected. On the host I can listen on a port on my host (`nc -l -p 1234`) and connect from a container (`docker run -it --rm alpine nc host.docker.internal 1234`).

Networking Host -> Container: Exposed ports work as I would expect. I can run a container with an exposed port (`docker run -it --rm -p 1234:1234 alpine nc -l -p 1234`) and connect from my host (`telnet localhost 1234`). I can't connect directly onto the docker network bridge (though I'm not sure if that was ever supported on OSX?).

No skin in the game either way here, just with a bunch of people suggesting buying OrbStack (which is OSX only), figured I'd throw Rancher Desktop out as a potentially viable cross-platform alternative that's also free and OSS.