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.
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.)
Awhile back, I wrote up a comparison of all the Docker Desktop Alternatives. [1]
I use kubernetes for pushing stuff to AWS EKS, and it is great. The problem I found with minikube and other Kubernetes based "alternatives" to Docker Desktop (including podman) is that they are not compatible with Docker Compose. There are a * a lot * of "solved problems" via docker-compose.yml files, and all of my past companies have used it. I've tried some docker-compose to k8s migration tools, but the amount of crap files they generate was not feasible for me.
Nerdctl[1] (for containerd) works fine with docker-compose.yml for my purposes (which are not much). The only issue I encountered was with environment variable substitution not working the same as docker-compose, but I didn't look hard for a solution and edited my compose file
Helm charts are roughly the k8s equivalent of docker compose. Might be a few years before they’re as widespread but a lot of common things you’d want to host are largely “solved” already.
There's one big difference between Docker Desktop and minikube and the ones referenced in the docker desktop alternatives link. Docker Desktop is a desktop app (GUI and all) while all the listed alternatives are terminal apps.
For some this might not matter but for others it does.
Rancher Desktop[1] has the desktop app install experience, the GUI, and the the tools (Docker CLI/nerdctl, Kubernetes (k3s), etc), and more.
I agree, I think the GUI is important for the kinds of users who feel lost without Docker Desktop. There have been plenty of other ways for technical users to run their containers all along (really, you could just run your own VM with vagrant if nothing else) but the people who want a "point and click" turnkey experience will appreciate the GUI.
Another kind of nice thing about Rancher Desktop is it's cross platform, so even Linux users can use it. That could be nice if you have a mix of Linux and Mac devs and want to use the same tooling here. It also makes sure you don't "mess up" your real Linux system or run into any distro-specific version incompatibilities (since it's all in a disposable VM controlled by Rancher Desktop).
I've tinkered with Rancher Desktop periodically and I think it's a promising tool. For now I keep going back to running Docker directly, only because it's my existing workflow (I'm a Linux user so the Docker Desktop changes don't apply to me).
It should be noted that minikube does not work on the M1. Sadly we started switching devs over to M1 at the same time we finished up switching our local environment over to minikube.
The issue that I had with Minikube is that I couldn’t get it to work with my employer’s VPN enabled. I realize that this is more the fault of my employer’s strict no-split-tunneling configuration than Minikube’s, but sadly that is the reality I live in.
I ended up using lima vm, which has an elegant port forwarding solution to make everything running on the VM appear as if it is running on localhost.
Having made the switch, I also prefer the simplicity and transparency of know exactly how the VM is configured, and being able to make tweaks to the provisioning script if necessary. Minikube on the other hand felt a bit automagical at times.
kind (Kubernetes-in-Docker) still requires Docker, so its not a replacement for Docker Desktop (Windows/macOS). You'll need to run kind in minikube or kind in Docker Desktop.
> kind was primarily designed for testing Kubernetes itself, but may be used for local development or CI.
minikube was designed for those who want a local kubernetes environment for development. It didn't work well for testing Kubernetes itself which led to kind. They had two different, though slightly overlapping, goals.
minikube is good where you have to have a VM, which is development on Windows and OS X. Linux containers need Linux, much to the dismay of laptop buyers I guess.
I personally don't bother. I use Windows but just have a pet Linux VM where I actually do work, and then use kind (with podman; Docker seems to be turning the screws and I'm getting out ahead of that).
I prefer Minikube over Kind, because Minikube supports a lot more options and features, and has integrated the same features as Kind. Kind has not had a new release for almost a year.
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?
Come on Apple. Microsoft can do it.
edit: this seems like a new development since my last whine/complaint on this topic:
Although just today I was having some Windows containers hiccups, I am looking forward to the day that Microsoft doesn't require installing a third party solution (Docker) to use them.
Install a WSL machine. Install docker (or containerd, or whatever) in it. Install docker-cli on your host, then use `docker context` to use the server in WSL. 20min of effort if your Google fu is good.
If you need something like the docker desktop UI, check out portainer.
Indeed, with windows' linux subsystem I have to say working from M$ sounds reasonable, maybe even better than dealing with Mac OS X half-baked package managers and subpar docker experience.
It used to be that Windows had a better UX than OS X (imho at least), but nowadays they're equally crap and they can't compare with what's available on linux.
With two machines, I'd still pick Windows for gaming dev and linux for everything else.
With three machines, I'd add a screen-less mac mini to do iOS related builds.
No, but basically this would apply to like little services that might run on docker locally on my mac. Say you have a Dockerfile that uses pip to install some stuff and run a python script. There are a few tools on github I use that are configured like this. To run it without docker, I would write up a simple launch agent plist file that calls up another script that just initializes a conda environment with the dependencies and runs the python. this might not be applicable to all docker use cases, though, but it works well enough for me.
> macOS is mainly targeted at secretaries, managers and artists.
Counterpoint: I've never seen someone in the Bay Area developing on a Windows machine, in any company I've worked at. In my experience, locally, it's more like 95% Mac, 5% Linux, and 0% Windows.
Now, I know that neither of our anecdotes represent the state of the world in general, but the notion that "Macs are for non-techies" is laughable on the face of it.
I had a windows laptop a few times while working. I much prefer it to Mac laptops (which is what I've been made to use most of the time), or even linux laptops. Most of my dev work targets linux but with visual studio code remote, or a shell, or a remote desktop, what I run on the local machine is less important.
What is important is having a set of keystrokes that make sense to me (the mac command button does not work well on my PC laptops, and remapping just makes stuff worse) and don't change over decades.
I’m fine with that. Develop on a C64 if you’re efficient with it for all I care. I don’t like using Windows because it feels strange and all the keyboard shortcuts are wrong to me. What’s uncool is making fun of it, and by extension people who use and like it, as a toy for people who aren’t technically sophisticated.
That’s right up there with “iPhones are for sheep LOL” as far as things that make the speaker sound a lot worse than the people they’re talking about.
> macOS is mainly targeted at secretaries, managers and artists. Tech work isn't designed to be compatible with a mac.
I don't think this is true at all. Despite not developing Mac applications, we've (Twilio) been a Mac shop since day one, 14 years ago. This was driven by our three founders, who, at the time, were all engineers. These days our IT department offers Windows machines for employees who need it for some reason, but uptake is likely in the single-digit percentages.
And I know a lot of people who do technical work at various companies whose primary work machine is a MacBook Pro.
This might be a Silicon Valley startup thing. I would expect the Stack Overflow survey is skewed pretty hard toward Windows due to big corporate enterprises that aren't tech companies. It seems to me that most "tech companies" prefer Macs.
> Take for example using netcat. The version available to Mac is 17 years old and lacking some useful flags
I run Linux, so I don't have firsthand experience with much of this, but everyone I know who uses macOS for development has something like Homebrew installed, so they can get up-to-date versions of the various tools that are outdated in the default macOS install.
I have worked at 4 small-to-mid-sized tech companies now and only one didn't have every software engineer on Macs with Docker.
I don't disagree that the built-in tools on Mac leave a lot to be desired, but you can also just brew install things and clearly Docker has gone to a lot of effort to make this all work on Mac, so the demand is there.
I switched to Linux for the current company, and was expecting fewer Docker oddities and better battery life, but I seem to actually have way more issues now, which - without sinking a week or more into investigating transient issues - I attribute to it not being isolated in a VM.
I often have to reboot my machine just to get basic DNS resolution working from inside a container
> Iirc, a 2018 stackoverflow survey of what devs use had 50% on windows, 40% on Linux and 10% on mac.
You needn't rely on your memory, the survey is still available [0]. FWIW, it doesn't seem to contain a question about the OS where development takes place, only about the targets[1]. The top answers were:
[1] "Linux and Windows Desktop or Server are the most common choices that our respondents say they have done development work for this year." (emphasis mine)
Are you talking about the old problem of VMware and Hyper-V not playing well together, or suggesting that using both together solves Windows development woes?
> why the heck doesn't the macOS kernel support native containerization?
Because Apple has no plans of growing their server OS marketshare. I know there are benefits of using namespaces (containers) in the desktop market, but they don't sell iMacs/MBPs. Exterior design and heavy marketing is their sales strategy.
I never understood this, because surely some huge percentage of developers use Macs. Enterprises buy stacks of them nonstop. Just making that group happy would get you the reputation of being a developers machine, for serious computer people, which could translate into laymen purchases too.
Would developers really be happy with containers running macOS inside? Production is running Linux, so they need two sets of images and their local image will be different from the one running in production.
I'm really not sure what comment you're replying to but Mac developers write code that runs on linux primarily using Docker and "VMs" that run linux on docker. Like; probably 75% of the devs on the west coast do this.
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 ...")
I really wanted to use it badly, but lacking an alternative to Docker Compose or compatibility with it in 2022 is unacceptable. Yes, there is technically a way you can orchestrate containers through configuration, and I don't remember what it was called, but I found it both difficult to use and learn. It's crazy to me that people wanted to develop an alternative to Docker... without a way to just configure and network containers with YAML or JSON.
There are use-cases that Podman can be used for that don’t involve Compose (yes, even with orchestration). Likewise there are a lot of features Podman and family have that Docker does not. Historically rootless is the big one; Docker sort of has that now but it’s still not daemon-less.
What problems did you have running Docker-compose with podman? I am running both on a server without any problem. Fedora-like distros have a package podman-docker that make docker-compose work without workarounds.
To be clear: this isn’t the actual podman-compose project, just a wrapper to make docker-compose work with podman-machine. That said, I just tried to do a run and it didn’t work. It’s not part of my workflow though so I haven’t encountered it before and thus haven’t really looked into it.
I assume you meant 2.x; Compose 2.x is only ~4 months old. I believe the intention of the Podman team is to abandon their podman-compose and work on compatibility with docker-compose 2.x going forward.
The version of the file format is different to the version of the CLI tool. Compose (the file format) 3.x was introduced with Compose (the tool) version 1.10 in 2017: https://github.com/docker/compose/releases/tag/1.10.0
Oh. I was only talking about the program and the interface it uses with the underlying runtime. Compose 2.x expects the underlying tool to have a different API.
I just switched to Colima and found it worked perfectly out of the box, according to the documentation. Once I had brought up a new machine with `colima start --cpu 2 --memory 8 --disk 10 --with-kubernetes`, `docker compose` worked perfectly and I could see the colima-backed kubernetes cluster available to control via `kubectl config get-contexts`.
I am on a m1 macbook air and I've been using Docker + Docker Desktop without much issue, and my use-case is a little simpler than yours (only running single containers at a time).
I'm genuinely curious to learn more about what these tools (Colima, podman) help enable. If I'm missing out on a performance boost, I'd definitely check them out.
And in those larger companies, just paying for the "coffee a month" may not be an option, since they insist all licenses are company owned and it's less effort to change my docker VM wrapper than get shit past my company's purchasing department in a reasonable amount of time.
It doesn’t help that the compulsory “Business” edition is burdened with the anti-feature of Docker Registry but that SSO is still “on the roadmap.”
There’s no way we would have gotten the product through IT Security Management on time, much less through purchasing. Docker appears to have fallen down a bit on their market research - they forgot that their real customer for the Business subscriptions weren’t the developers at large companies, but their software purchasing processes.
Exactly, I think this is really going to backfire for the bean counters that took over Docker. It should either be free or $100k+ agreements for extremely large companies. They're way underestimating the inertia and pain with trying to nickle-and-dime small and medium business users.
It was the motivator for me. But having gone through the effort to evaluate alternatives, I’m happy where I ended up (lima).
It’s free and open source, and easier to install and configure via scripts than Docker Desktop. The goal for our team is to make getting new developers set up as simple as possible (ideally just a single command), but prior to now the instructions to install and configure Docker Desktop were always an asterisk in the prerequisites section.
I switched because of licensing changes and because I find the docker desktop UI to be laggy, frequently updating with no discernible benefit to me, and superfluous -- I would rather interact with my containers via the CLI, but had to use the desktop app to start the daemon.
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:
brew install lima
limactl start docker.yaml
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).
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).
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.
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.
I tried it out to today after struggling for more than a month with Docker for Mac with problem after problem. I know how exactly many turtles there are all the way down. Rancher fixed everything first try. Containerd/nerdctl doesn't work for us (too tired to figure out why), but Rancher can run Moby/docker.
Unfortunately this like other alternatives still misses some key features of Docker Desktop for Mac like utilizing VPNKit (https://github.com/moby/vpnkit) to make networking not constantly break when on a VPN without split tunneling, etc.
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 somebody address.
Important consideration: Docker Desktop isn't free software and isn't even source available.
It also includes on-by-default nonconsensual spyware that uploads a significant amount of private information about your system and network when it crashes.
Command line docker, the docker server (for Linux) and a Linux VM are all free software.
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.
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.
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.
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.
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."
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).
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.
> 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.
Install Barrier on both Mac and Linux, get an extra monitor, and then you can seamlessly work on both system at once as if it's a single computer with multiple monitors. Don't even need to press that switch button on your keyboard and mouse.
@blakesterz what kind of pain are you feeling when developing with containers on a Mac vs using your Linux box? I know perf is worse, but are you hitting other things?
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.
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.
> 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.
Apple will most likely continue to do what it always does: make billions of dollars while largely ignoring Linux.
iOS and macOS developers will continue to use Xcode the way they always have. (And perhaps Swift Playgrounds on iOS.)
While Microsoft might have lost the server battle, those of us deploying on Azure hardly bother with which OS the type 1 hypervisors are actually running, many Azure workloads could even running directly on the hypervisors that we wouldn't really notice.
As for the desktop, regardless of all screw ups since Windows 8, GNU/Linux has hardly made any gain there.
Then we can turn into mobile space, which they did lose, however in what concerns tablets, hybrid laptops running Windows win out clusmy Android tablets every day of the week.
Finally, WSL is there to cater to the same folks that buy Macs to develop Linux instead of supporting Linux OEMs.
Who knows, maybe Apple will upgrade sandboxing to jails/containers and add a FreeBSD-style Linux compatibility layer. Or maybe they'll go full-on MS and include a Linux kernel alongside Xnu using Hypervisor.framework. (Note that in my experience the networking design of Ubuntu on WSL broke containers that worked fine on regular Ubuntu in Virtualbox/VMware/etc., but YMMV.)
Something like that is certainly possible, though they'd have to have some reason for it, and they don't appear to at the moment.
Precisely - macOS already is a perfectly good native BSD that (as you note) is UNIX® certified by The Open Group.
However, linux app binaries (notably docker images, which we're talking about here) need some sort of linux runtime, compatibility layer, or VM, in order to run on macOS.
The original implementation/version of WSL was an interesting POSIX-compatibility personality/layer for the NT kernel, but Microsoft seems to have decided that running a Linux kernel in a VM provided a better user experience (and probably made it much easier to track feature parity with Linux.)
One can use Vagrant and VMware (instead of Virtualbox) on ARM M1. VMware fusion is free and Hashicorp has released the VMware vagrant plugin for free as well.
As well as the `--default-owner-` switches, I had some file permission issues on the Docker side. I ended up using `setfacl` to enforce really permissive permissions on `~/mysite` on the VM side, otherwise some Docker containers would complain. It turns out Docker for Mac fakes some file permissions, which is why it wasn't a problem before.
Other than that, it mostly just worked! Feel free to get in touch if you have more specific questions.
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.
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...).
> Are people doing stuff on their computers I'm not even aware we can do because I use Linux?
Yes, that’s mostly it. Fractional display scaling, good battery life, switching between audio devices that might be wireless or connected to a thunderbolt dock, seamless copy/paste, this kind of stuff. Some of it works on Linux too with some work but the question is what’s more economical. No system is perfect, honestly. It’s much easier for me to use Docker on a non-Linux system (or use a local or remote VM) than fix bluetooth audio.
In my experience MacOS users seems to have as much trouble with screens and thunderbolt dock as I do. We had to try nearly all double screens thunderbolt docks on the market and I think we lost hope to find one that works reliably out of the box with those 3 OSes.
I cannot say for battery life, people tend to be connected to power all day here, so that's probably not the reason.
Not even sure what is seamless copy/paste sorry.
But okay, admittedly I don't do anything fancy with my audio devices, or my screen scaling, that must be probably it
I also have issues plugging and unplugging external USB-C displays; I've found that I have to plug them in in reverse order in order to get them to be recognized.
Be that as it may, macOS has some cool display features from Sidecar (plug in an iPad and it becomes a poor man's Cintiq) to the upcoming Universal Access (seamless mouse/keyboard control over multiple devices including drag & drop and cut & paste.)
Seamless copy/paste means that multiple Apple devices can share the same clipboard, so you can copy on one devices and paste on another. Drag and drop is even cooler since you can drag something off an iPad and onto a Mac or vice-versa.
For some reason, Macbooks are considered sexy. No wonder; Apple produces fashion accessories that double as pieces of advanced technology. To my mind, their only outstanding quality is battery life.
Then, MacOS is bundled with these machines. It's very opinionated and highly integrated; little needs adjustment, or cab be adjusted at all. For some people, it's a relief.
Last but absolutely not least is that many companies standardize on few vendors and few models, ideally, only one vendor. Apple gladly fills this niche, admittedly offering good technical support, and enthusiastic sales force. As an engineer, you're not given a choice; I've been in such situation several times.
Before the butterfly keyboard disaster at least, Apple laptops were known for their excellent industrial design and usability. I'm not a huge fan of the screen notch (though arguably you're not losing anything from it) but the current MacBook Pro has an amazingly bright screen and terrific speakers (and they also fixed the keyboard.) An underrated feature of Mac laptops is that their integrated mics aren't terrible.
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)
Otherwise its a treat. No local storage eaten up, no cores pinned to 100%, no reserved memory, no (additional) VM layer, …
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?
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:
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.
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.
Lima absolutely rocks. For me, there are a few small nits, but overall probably the best to replace Docker. Out of the box ("brew install lima; limactl start") lima gives you an Ubuntu VM with containerd and nerdctl. Nerdctl is mostly compatible with the docker cli as others on this thread have mentioned. The examples/ directory also has configs for starting up k3s or k8s. Rancher Desktop is also using Lima.
Minikube also works, but I can't get host directories mounted in the VM; running nfsd on the Mac is a reasonable work-around. It does start up k8s containers, so if you just want a docker-like environment, it might be overkill.
I’m in the process of changing our local development containerisation strategy within the business from Docker for Desktop to Lima. So far it’s been absolutely flawless.
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?
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.
Not that I disagree about something being deeply wrong, but VM's your only option. Docker is more or less hardcoded to Linux, so you need a Linux kernel somewhere. Docker Desktop just runs a light one for you that you don't worry about managing much.
Docker is not hardcoded to Linux. There're Windows-native containers. That said, I agree that most useful images out there are built for Linux and having thousands of existing images is what makes docker useful at all.
I agree, but currently Docker on Mac is more about building/testing your server infra on your macOS dev machine before deploying it to Linux where it actually runs as "lightweight" containers.
Regardless, would still be great if we had native macOS container support!
Not if you run your entire dev setup through docker, though. I'm tired of python's craziness. Always someone on the team unable to do poetry install, because some variant of their system makes it not have a wheel, and suddenly a whole c++ toolchain needs to be installed. And if you maintain lots of projects with different versions it's such a hassle.
Now I volume mount the git clone folder into a container that has everything set up. And that setup works for everyone, on all OSes and not depending on local environments.
PyCharm uses that image as a remote interpreter, so pressing play in pycharm just works.
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
My organization decided to hold off on purchasing M1 MacBooks for developers until they're better supported by third party software. Too much stuff just crashes or doesn't work well, even with QEMU and Rosetta.
After the November 2020 release of the M1 Macs, Docker and many developer tools were still not available and you would have to wait 6 - 8 months for Docker to be fully supported and out of beta for M1 Macs.
Not quite ideal to wait for your tools to be available on your machine for more months in order to do any work on it.
The smartest thing anyone would have done to save themselves from disappointment and frustration as a developer is by simply using your existing Intel Macs and 'waiting' for the software ecosystem to catch up with the Apple Silicon Macs.
I don't have anything of substance to add but I can definitely echo your experience. I'm still in love with the M1 chips but it is definitely not a seamless transition if you work with Docker a lot. I've had containers behave really strangely and unreproducibly.
ARM 21.10. Greatly improved disk performance. (Not measured, just based on my dev experience with the RoR + MySQL app I am working on.). I did find file sharing via WebDAV and SMB to be lacking so ended up going with sshfs.
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.
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.
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?
I have just started using it, and I stopped short of telling people it was a great alternative because I don't have enough experience with it yet to say one way or another.
But so far it's pretty muchliving up to my expectations, with a few quirks: (1) I can use the buildkit plugin, at least it seems to work so far, but (2) things are not strictly compatible, for example the `kuby build` command has an issue and will need to be updated to support rancher desktop... it's refusing to log in right now, even though I logged into my registry already, with an error about not doing interactive logins without a TTY. I'm assuming there's an easy workaround, (but this part works fine with Docker Desktop already.)
By your "it's alright" I suspect you've seen other things I'll bump into that made you say "alright" rather than "great." Anything interesting you're able to share?
I just pulled it (and switched to dockerd as default container runtime to use 'docker') - it seems to work as a great swap for docker desktop on mac. I like that volumes work well vs podman. Nice that you an trivy scan an image, etc.
Have you hit any sharp edges yet? I imagine there might be a few. Anything you can share would be great
If you put your computer into sleep, the VM time will be out of sync. It's going to be fixed in the next release I believe. It's an old classic bug that happened to me with WSL so it was nice to see it again. https://github.com/rancher-sandbox/rancher-desktop/issues/83...
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.
We have been using it for years with few major issues, so I would definitely not call it completely broken. “Suboptimal”, maybe.
But we made the decision that the benefits of containerization outweigh the cost of having to run containers in a VM during development, and have been mostly happy with that decision. We’re certainly not considering going back to the old way of having to manage application runtime dependencies separately across hundreds of different servers.
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?
FWIW, I recently switched from an Intel to an M1 Macbook, and found shared volumes with Docker Desktop were unusably slow (previously, I'd used VirtualBox host docker and shared files into it via NFS).
However, using https://mutagen.io/ to keep the container in sync has worked remarkably well - it's greatly improved the speed of the container.
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?
They probably don't know. And it's fine to use docker desktop without paying as long as you're a small business or a private person. They can't automatically know if you're in violation or not.
They just assume people want to be in compliance. Same way I wouldn't misuse gpl code at my work.
This is a very heavy alternative. It is also not viable for those with ARM machines, as Virtualbox is x86 only.
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.
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?
YMMV but my big pain point is sharing a large project between my Mac and the VM running Docker Desktop. I don't think this will make the file sharing bit any faster.
Is there anything complex about setting this up that you'd want to use this, or is this more of a time saver?
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!
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.)
Awhile back, I wrote up a comparison of all the Docker Desktop Alternatives. [1]
[1] https://matt-rickard.com/docker-desktop-alternatives/