I can keep multiple VMs running, run multiple Dockerized large web apps in various web frameworks, open 20+ tabs in a browser and a bunch of other stuff and it doesn't break a sweat. Working with Vim and 50+ plugins has no type delay. Opening Chrome from hotkey to being able to type takes a second.
DOCKER HYPERKIT MEMORY MAC FULL
I use this workstation for full time development / ops work on Windows with WSL 2 / Docker, etc.Įverything is still pretty damn fast and it feels no different than the day I put together the machine. I'm not here to start a mac vs windows war but I have a 6 year old i5 3.2ghz CPU (4 cores, no HT) with 16gb of memory and a first gen SSD. The interesting thing here is, is it really a game changer in practice for something like web development and every day computer usage? > I’ve been away from macs for couple of years, but these M1s are IMO a game changer. (Or you can do the same from the Docker on Mac tray menu.) Targeting my commands to my local Docker-on-Mac k8s cluster vs a remote one is just a `kubectl config set-context` away. I don't know about docker itself, but I'm using Docker on Mac for Kubernetes "application" development. 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.) It's already a special snowflake may as well treat it like one. (In the rare case that I do want a persistent database, I run it on the host. Why would any such data need to live longer than the containers producing+consuming it?
DOCKER HYPERKIT MEMORY MAC CODE
Any data is just there to verify that the code is doing the right thing. I don't want any persistent volumes, host mounts, any of that. Caches, databases, message queues? In development, they're ephemeral. In fact, best if it gets blown away on every restart.Īny 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. The less it can do other than that, the better. I want a dumb cattle VM running Container OS or an equivalent, whose only job is to run containers, ephemerally, connected to my host. I don't want to maintain my own special-snowflake VM just to run docker containers on it. 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? The common suggestion is to use NFS to get around those, which is just ridiculous when you think about it.
DOCKER HYPERKIT MEMORY MAC FOR MAC
The suggestion above is not bizzare, it's a normal use case: run Docker on Linux like it's meant to be run.ĭocker for Mac has had performance issues for years, especially related to file I/O. It shocks me that so many people want to run Docker on a platform it was never built for. It will eat RAM up to the amount you specify rather than dynamically allocating and deallocating as per the requirements of each running container like on Linux. It's also why you can limit how many CPU cores and RAM Docker can use, since you're just giving the underlying virtual machine those limits through the Docker settings app. The way it works on Intel-based Macs is through the xhyve/hyperkit hypervisor, i.e. Docker has never and will never run on a Mac natively. It's bizzare to want to run Docker on a Mac anyway.