Why would I want that control when Docker on Mac does everything exactly the way I would do it if I set it up myself?
I don't want to maintain my own special-snowflake VM just to run docker containers on it. I want a dumb cattle VM running Container OS or an equivalent, whose only job is to run containers, ephemerally, connected to my host. The less it can do other than that, the better. In fact, best if it gets blown away on every restart.
Any statefulness is to be avoided, because a stateful Docker host might mislead me that my images will work in prod, when they're really dependent on something in my dev VM. Caches, databases, message queues? In development, they're ephemeral. Blow those containers away, please. I don't want any persistent volumes, host mounts, any of that. This is development, not deployment. Any data is just there to verify that the code is doing the right thing. Why would any such data need to live longer than the containers producing+consuming it?
(In the rare case that I do want a persistent database, I run it on the host. It's already a special snowflake; may as well treat it like one. As a bonus, this forces me to ensure my applications can target external resources using connection-string env-vars — which is almost-always relevant in production, where the DBMS is going to be some cluster external to the compute environment.)
> VM could be somewhere else. Or it could be on the local machine. Doesn't matter.
I don't know about docker itself, but I'm using Docker on Mac for Kubernetes "application" development. Targeting my commands to my local Docker-on-Mac k8s cluster vs a remote one is just a `kubectl config set-context` away. (Or you can do the same from the Docker on Mac tray menu.)