One of the past maintainers of minikube here. Minikube, while targeted towards Kubernetes developers, also provides all the features you'd want here. It also takes away most of the pain from virtual machine management w/ native hypervisors.<p>If you're looking for customizability (boot image, docker version, container runtime), minikube is probably your best bet. It even comes with some rudimentary file-sharing and port-forwarding primitives, but it isn't as batteries-included as Docker desktop. On the other hand, you have full ssh access to the VM to do whatever you want (+startup scripts, etc.)<p>Awhile back, I wrote up a comparison of all the Docker Desktop Alternatives. [1]<p>[1] <a href="https://matt-rickard.com/docker-desktop-alternatives/" rel="nofollow">https://matt-rickard.com/docker-desktop-alternatives/</a>
I know people doing docker dev are generally targeting a Linux of some sort, but why the heck doesn't the macOS kernel support native containerization?<p>Come on Apple. Microsoft can do it.<p>edit: this seems like a new development since my last whine/complaint on this topic:<p><a href="https://macoscontainers.org/" rel="nofollow">https://macoscontainers.org/</a>
I've been exploring 2 alternatives (podman and colima) to replace my normal docker workflow, which is just building and running containers locally, sometimes with docker-compose. I started with podman but had issues with 2 main pieces of my workflow: docker-compose (or podman-compose) and shared volumes (with `run -v`). Switched over to colima and those worked out of the box for me ("brew install docker; brew install docker-compose; brew install colima; colima start; docker run ...")
The favorite replacement that I have found for docker desktop is to run docker-ce in lima vm [1]. It’s only a couple of commands to get up and running with their docker example [2]. Basically:<p>brew install lima<p>limactl start docker.yaml<p>lima is built on qemu, which is always a solid choice for virtualization. It also supports M1 Macs, and even Intel on Arm emulation (at a pretty hefty performance cost).<p>One of nice features of lima is that it automatically forwards ports from the host vm to guest, so when you start up a container listening on port 5432, for example, you can access it at localhost:5432. This works nicely in particular for local development while using a VPN client, which I have found has a tendency to interfere with local network traffic (if split tunneling is disabled).<p>lima is used under the hood in rancher desktop, which is another great option if you would prefer to have a gui. But I have settled on lima as I prefer the CLI for scripted installations, and also find it to be more customizable.<p>I have also seen colima mentioned in the comments, which appears to wrap lima with some prebuilt configurations. I don’t really think this is necessary, and seems like something that could just as easily be done with a gist, but if you are looking for the absolute quickest way to get up and running with docker (and optionally kubernetes) on lima, then this could be it.<p>[1] <a href="https://github.com/lima-vm/lima" rel="nofollow">https://github.com/lima-vm/lima</a><p>[2] <a href="https://github.com/lima-vm/lima/blob/master/examples/docker.yaml" rel="nofollow">https://github.com/lima-vm/lima/blob/master/examples/docker....</a>
As an alternative one can also consider Rancher Desktop (<a href="https://www.suse.com/c/rancher_blog/rancher-desktop-1-0-0-has-arrived/" rel="nofollow">https://www.suse.com/c/rancher_blog/rancher-desktop-1-0-0-ha...</a>) mentioned here few days ago.
Unfortunately this like other alternatives still misses some key features of Docker Desktop for Mac like utilizing VPNKit (<a href="https://github.com/moby/vpnkit" rel="nofollow">https://github.com/moby/vpnkit</a>) to make networking not constantly break when on a VPN without split tunneling, etc.<p>I've started using minikube myself as I stopped constantly needing to use Cisco AnyConnect for work as we switched to using a Zscaler product instead - but this is a huge bugbear for many users I'd like to see <i>somebody</i> address.
I’ve been trying something new for the last few months. I brought a min-spec M1 Air and I’ve been using a hetzner dedicated server as my development machine.<p>I run all user-interfaces locally, and use unison to keep files in sync. VSCode remote dev works well, but I’m more of a PyCharm person myself and their remove dev is just picking up. Docker just runs natively on the server.<p>But it has been working very well with unison. I run eternal terminal with tmux, so my terminal is always available. Local bandwidth requirements are low and I get a 6-core 64GB dev machine.<p>It’s actually been very pleasant. I have barely any dev tools locally (not even home brew, which I do not miss at all).
> Motivation: Docker for Mac was proving to be a workflow pain rather than a workflow gain. It was slowing down my 16" Macbook Pro (32GB RAM, 6 CPUs), draining the battery, and causing the fans to constantly spin at full speed.<p>A performance comparison between this solution and Docker for Mac would have been great.
"Motivation: Docker for Mac was proving to be a workflow pain rather than a workflow gain."<p>I feel that pain. I switched from a Linux box to a Mac Mini for ALMOST all the work I do. I just couldn't take the pain, now when I need to do my Docker work, I just flip back to my Linux box. I have a Logi keyboard and Mouse with that 3 device button option, and a monitor with a few inputs, so I just turn on the ol' Linux box, press a few buttons, and I'm there. I do the same thing for Windows, for the rare occasion I need Windows (mostly for testing stuff).<p>I could probably find ways around the pain points, but I just can't be bothered when it's so easy to just use the other machine sitting right here. No point in wasting any more time on it.
The Docker/virtualisation stuff on macOS really needs fixing up. The x86 to ARM transition has made things worse but it was pitiful even before. Virtualization.framework doesn't seem to live up to the hype. Docker has an experimental mode for it - if you try enabling it you'll quickly realise why it's experimental. Your computer will go into meltdown and performance will feel a hundred times slower. M1 MacBooks are no good for Docker/VMs unless you have a Parallels license.<p>Apple needs to do what Microsoft did surrounding Linux on Windows. Allocate some engineers for a few years to make life easier for developers on their platform.
As others have pointed out, Virtualbox doesn't work on ARM (M1).<p>A few months ago I switched to a new setup on my M1 Max: running a Ubuntu VM in UTM (<a href="https://mac.getutm.app/" rel="nofollow">https://mac.getutm.app/</a>), and installing Docker there.<p>I use Mutagen (<a href="https://mutagen.io/" rel="nofollow">https://mutagen.io/</a>) for syncing files between macOS and the VM, which works really well.<p>There is a 10x-20x speed improvement running a large PHP (Drupal) project through the VM than Docker for Mac.
I'm using Multipass [<a href="https://multipass.run" rel="nofollow">https://multipass.run</a>], docker cli, configured with a docker context.
In my experience, Docker for Mac has always had significant performance problems primarily because of its built in host <-> volume sync strategy. The problem has persisted for many years. Different 3rd party (open source) solutions can relieve this performance bottleneck like docker-sync and mutagen. It just blows my mind that after all these years, the docker for mac team hasn't found a decent file sync strategy to include by default. If you're working on a project with a lot of files, docker for mac's built-in sync strategy is likely crushing your CPU.
Admittedly I haven't tried Windows and MacOS a lot, but I still don't understand why people insist on using MacOS for doing Linux development. I think it must be pretty rare to have devs doing MacOS development not using MacOS or devs doing Windows development not using Windows, but for Linux backend there seem to be a consensus that running VMs is a good idea.<p>Why is that? Are people doing stuff on their computers I'm not even aware we can do because I use Linux? Or am I working slower because Linux is not the right tool for development? At work I have a feeling that a lot of time is lost to have the Linux devs tools (docker in particular) working properly on other OSes (MacOS and WSL), and docker especially (and those new Mac M1 which suddenly are even slower with all the existing docker images because of course our CI is not building ARM images...).
It’s not local docker, but<p><pre><code> export DOCKER_HOST=ssh://user@some.nix.box
</code></pre>
does the trick for like 90 percent of my local docker workflows. Big gaps are local volumes, remembering to look for ports exposed on the remote box instead of localhost, and VPN access (if the remote box box isn’t on the right network)<p>Otherwise its a treat. No local storage eaten up, no cores pinned to 100%, no reserved memory, no (additional) VM layer, …
I wrote a dumb shell script that wraps Canonical's multipass to do what Docker Desktop used to. Its limited but reliable on my M1 mac.<p><a href="https://github.com/jedahan/podman-desktop" rel="nofollow">https://github.com/jedahan/podman-desktop</a>
I suppose peeps are starting to notice this because they're no longer able to use Docker Desktop on their corporate machines and are scrambling for alternatives?<p>We got lucky where I work, and already had a RHEL license which gives us Docker Desktop Enterprise too, I think.
We do two strange things (right now) that only seem to work with Docker Desktop for Mac <=4.3.2:<p>We use registry mirrors to access a registry over an SSH tunnel. Doesn't seem to work with Docker via Colima, etc. as it's initiating connections from inside the VM, which doesn't see the SSH tunnel. Broke with Docker Desktop for Mac 4.4.2 as well, and tbh I can't explain why it ever worked, but it did. Nerdctl just learned about registry mirrors like 3 weeks ago[0], but it looks like it's having containerd do the pull so it would be in the same boat.<p>We set up IP aliases on lo0, and bind containers to individual addresses. This lets multiple containers and their services be directly accessible from the host - and e.g. applications running in Windows on VirtualBox - without having to remap ports. I don't think any of the alternatives support this. I know Colima does not. I don't think anything including Docker Desktop have a way to expose the docker bridge adapter directly to the host.<p>[0] <a href="https://github.com/containerd/nerdctl/pull/642" rel="nofollow">https://github.com/containerd/nerdctl/pull/642</a>
what about lima? it seems more easier to get.<p><a href="https://github.com/lima-vm/lima" rel="nofollow">https://github.com/lima-vm/lima</a>
I use only arm images with Docker but I get 100% CPU on my m1 ; on top it says Docker - 100%. Usually it takes a while (few hours) to go from 5% to 100% but it always gets there and the only way to stop it is shutdown Docker desktop and starting it again. It also crashes quite a lot (docker ps will then say Docker is not running and I have to restart Docker desktop to get it back as well). I really like the hardware on this machine but I'm contemplating selling it and getting a Frame.work with Linux just to get rid of this pain. It is a far faster & smoother experience on my 11 year old X220 with Linux than on this m1. I am not sure why this happens; I see many more people have it but there seems to be no clear reason?<p>Does this help or is the issue lower level?
I find it hilarious that their solution to Docker (which is supposed to be virtualization-light: containers) bloatedness is to use a full-fledged virtual machine.<p>Something's gone deeply wrong somewhere.
No company is going to touch Virtualbox without a 10ft barge pole. The licensing is so easy to get wrong and before you know it you’re writing a cheque to Oracle’s legal department
I'd rather (my company) pay than having to deal with all this myself. My Docker workflow works. Spending time on everyone moving away is actually a negative ROI.
<p><pre><code> 5. Install Docker Machine docker-machine
</code></pre>
The last time one of these discussions came up and a similar solution was provided, someone pointed out that 'docker-machine' is not a dependable solution. I can't remember the exact reason, nor can I find the link, but it was something along the lines of Docker making it proprietary or abandoning the project.<p>Can anyone provide any more detail about the state of 'docker-machine' or help clarify any issues with hitching your wagon to these 'docker-machine' solutions?
Uhm I’m not a sys-admin nor an extreme senior engineer, but you have to admit. The current setup for running docker on macOS, with the current virtualization, is completely broken.
Has anyone done any filesystem speed comparisons on any of these? Mounting volumes on Mac in Docker Desktop is... not great. Anyone found any good comparisons?
I've done most of my dev work on my physical Windows box using Docker Desktop, but have access to a robust cloud VM network where all my Unix work is done. The end result of a dev process is an image regardless of what tool you used, right? So how does Docker know if you've used Windows or Unix to write and test a given image? Is there metadata written into the image?
This is a very heavy alternative. It is also not viable for those with ARM machines, as Virtualbox is x86 only.<p>Minikube is a popular alternative. Colima is an up-and-coming one that's can run both raw containerd and Docker engine on top of containerd. I prefer Colima since I'd rather not have Kubernetes running full-time (consumes resources).
So, what exactly are the restrictions going to be? I don’t really use the UI all that much beyond seeing that the engine is running, I don’t have any images on docker hub. I pretty much just run it locally and push images to AWS ECR.
When I work on Linux as my OS, I just install CTOP, and it's all I need to work with Docker.<p><a href="https://github.com/bcicen/ctop" rel="nofollow">https://github.com/bcicen/ctop</a>
Multipass has been my docker desktop replacement of choice, I really like it (even in the non-M1 days I never liked docker desktop and used dinghy which was a wrapper around docker-machine)
When they changed the docker desktop terms, I switched to Podman. Now with Rancher Desktop and kubernetes swallowing the world...what really is the point of docker at all?
Is there anything complex about setting this up that you'd want to use this, or is this more of a time saver?<p>I was thinking about doing this, and still might on my own, unless there's some hard problem solved here. Nothing wrong at all with using this, though, very cool!