Docker for Mac Without Docker Desktop(github.com)
github.com
Docker for Mac Without Docker Desktop
https://github.com/stenh0use/docker-machine-for-mac
197 comments
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
1. https://github.com/containerd/nerdctl mine came bundled with Rancher desktop, and 'nerdctl compose up' is all I've needed
1. https://github.com/containerd/nerdctl mine came bundled with Rancher desktop, and 'nerdctl compose up' is all I've needed
https://aws.amazon.com/blogs/containers/deploy-applications-... When this came out it was a great day. It really made things a lot simpler to just get going with Fargate.
Have you tried Kompose? Is it generating the crap files you were not fond of?
Have you tried Kompose? Is it generating the crap files you were not fond of?
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.
[1] https://rancherdesktop.io/
Disclaimer, I started Rancher Desktop.
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.
[1] https://rancherdesktop.io/
Disclaimer, I started Rancher Desktop.
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).
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.
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.
Huh, I thought kind was the spiritual successor to minikube (which I used fondly years ago). When should one reach for minikube over kind today?
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.
From the kind readme[1]...
> 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.
[1] https://github.com/kubernetes-sigs/kind
> 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.
[1] https://github.com/kubernetes-sigs/kind
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 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).
What hypervisor do you use? Do you run graphical apps in the VM, and if so is there any noticeable lag?
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.
The kind binary is decoupled from the node images that make up your cluster. V1.23.3 published 3 days ago
https://hub.docker.com/r/kindest/node/tags
You can also provide any kubeadm config options you want, as kind bootstraps with upstream kubeadm
https://hub.docker.com/r/kindest/node/tags
You can also provide any kubeadm config options you want, as kind bootstraps with upstream kubeadm
[deleted]
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:
https://macoscontainers.org/
Come on Apple. Microsoft can do it.
edit: this seems like a new development since my last whine/complaint on this topic:
https://macoscontainers.org/
I don’t think it’s lack of support so much as lack of demand. MacOS containers sound like a solution looking for a problem.
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.
And for anyone looking to migrate away from docker desktop on Windows for use with VSCode I wrote this guide: https://gist.github.com/tdamsma/06cafea175d6784aea7b3634bb94...
It doesn't help for Windows containers though.
https://github.com/woachk/dockerinstall for a very minimal install, stuff other than that is unneeded for Windows containers.
Thanks, that is more what I was looking for.
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.
If you need something like the docker desktop UI, check out portainer.
Thanks it doesn't help for Windows containers, that was my point.
> why the heck doesn't the macOS kernel support native containerization
It doesn't seem like a huge leap from sandboxing to containerization.
They also might consider supporting BSD-style jails.
It doesn't seem like a huge leap from sandboxing to containerization.
They also might consider supporting BSD-style jails.
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.
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.
That URL got me excited, but didn't seem to be a lot of progress on it in the last 6 months or s.
I have used the native launch agent system in macos to do what some people use docker containers for.
Do you have this written up anyplace sharable?
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.
Because most people want to run Linux containers (to get the same environment as their servers)
0xedd(5)
> 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.
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.
iOS, iPadOS, watchOS and macOS applications aren't made out of thin air, they also need developers.
Also creating their own SoC that outperforms others in the space.
"Exterior design and heavy marketing is their sales strategy" this is old, boring and not even true.
[deleted]
[deleted]
containerization won't just help in the server-space. It has use-cases in app development like CI.
Apple would like you to move to XCode Cloud[0] in the future, running CI pipelines on your local device is soooo last-century.
[0] https://developer.apple.com/xcode-cloud/
[0] https://developer.apple.com/xcode-cloud/
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 ...")
podman: https://podman.io/
colima: https://github.com/abiosoft/colima
Podman works with docker-compose 1.x only and needs some finagling to work. I have this wrapper script as podman-compose
#!/bin/bash
set -e
tmpdir=$(mktemp -d)
port=$(podman system connection ls | grep -Eo 'localhost:\d+' | head -1 | cut -d: -f2)
[[ -n $port ]] || exit 1
ssh -fnNT -L"$tmpdir/podman.sock":/run/user/1000/podman/podman.sock -i ~/.ssh/podman-machine-default ssh://core@localhost:"$port" -o StreamLocalBindUnlink=yes
export DOCKER_HOST="unix:///$tmpdir/podman.sock"
docker-compose "$@"
rm -r "$tmpdir"This is exactly why I ditched Podman.
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.
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.
Afaik podman-compose doesn't support "docker compose run" to do one-off stuff in a new container? Is there some alternative?
I do it all the time now, have the entire dev flow dockerized. So I run tests, lints, fixers, migration etc all through docker compose.
I do it all the time now, have the entire dev flow dockerized. So I run tests, lints, fixers, migration etc all through docker compose.
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.
> Afaik podman-compose doesn't support "docker compose run" to do one-off stuff in a new container? Is there some alternative?
Minikube, no sarcasm. I'm also going to use Minikube.
Minikube, no sarcasm. I'm also going to use Minikube.
Is this a short term issue or is nobody working on docker-compose 3.x compatibility?
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.
For the life of me, I could not make podman working to replace Docker. I keep getting various errors.
I just made the switch to colima. Thanks for mentioning it!
I just made the switch to colima. Thanks for mentioning it!
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`.
+1 to Colima. Works seamlessly. Made the switch not too long ago.
What drew you to switch up your workflow?
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.
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.
In case you missed it the license terms for Docker Desktop have changed and require companies with ~250 employees to start paying for it: https://www.docker.com/blog/updating-product-subscriptions/
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.
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.
gotcha. i was aware, but doesn't apply to my current circumstance.
is that the motivator for most, then?
is that the motivator for most, then?
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.
I suspect it was the docker licensing changes. We're largely switching to Colima at my work too.
https://news.ycombinator.com/item?id=28369570
https://news.ycombinator.com/item?id=28369570
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.
[1] https://github.com/lima-vm/lima
[2] https://github.com/lima-vm/lima/blob/master/examples/docker....
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.
[1] https://github.com/lima-vm/lima
[2] https://github.com/lima-vm/lima/blob/master/examples/docker....
As an alternative one can also consider Rancher Desktop (https://www.suse.com/c/rancher_blog/rancher-desktop-1-0-0-ha...) mentioned here few days ago.
+1 for Rancher Desktop. [ https://rancherdesktop.io/ ] you can alias the `docker` command with `nerdctl` as a one:one replacement.
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.
You have an interesting handle.. Any association to the neighborhood of Zamalek?
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.
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.
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.
Docker Desktop is just closed source fork of abandoned kitematic.
https://github.com/docker/kitematic
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).
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).
Can I ask what the monthly hosting costs are?
It’s about €30/month, but it is very much a business expense, so it comes out of my company account (I’m a freelancer)
You could probably grab a server for a bit less from their server auction.
You could probably grab a server for a bit less from their server auction.
thats a really good idea. I have so many docker and docker compose things to run and the mac is just not powerful enough.
I use hetzner already too.
Do you happen to have an makefiles or scripts that set up this on your mac that you can share ?
I use hetzner already too.
Do you happen to have an makefiles or scripts that set up this on your mac that you can share ?
> 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.
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 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.
https://github.com/debauchee/barrier
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.
https://github.com/debauchee/barrier
[deleted]
I was thinking to do the same but with Linux in a VM on top of MacOS, figuring that docker runs like crap on it anyway so I might as well.
Edit: upon inspection I see that is what the link is about, so it probably has some merit.
Edit: upon inspection I see that is what the link is about, so it probably has some merit.
@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 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.)
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.)
Maybe, but that's what we all said about Microsoft ten years ago.
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.
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.
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.
macOS doesn't need WSL, it is already a certified UNIX.
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.)
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.)
[deleted]
[deleted]
As others have pointed out, Virtualbox doesn't work on ARM (M1).
A few months ago I switched to a new setup on my M1 Max: running a Ubuntu VM in UTM (https://mac.getutm.app/), and installing Docker there.
I use Mutagen (https://mutagen.io/) for syncing files between macOS and the VM, which works really well.
There is a 10x-20x speed improvement running a large PHP (Drupal) project through the VM than Docker for Mac.
A few months ago I switched to a new setup on my M1 Max: running a Ubuntu VM in UTM (https://mac.getutm.app/), and installing Docker there.
I use Mutagen (https://mutagen.io/) for syncing files between macOS and the VM, which works really well.
There is a 10x-20x speed improvement running a large PHP (Drupal) project through the VM than Docker for Mac.
Any additional guidance or resources you can point to for setup with UTM and Mutagen? Lando on macOS with Docker Desktop is driving me insane...
It was pretty straightforward, following UTM's setup guide for Ubuntu, Docker's setup guide, and Mutagen's:
- https://mac.getutm.app/gallery/ubuntu-20-04 - https://docs.docker.com/engine/install/ubuntu/ - https://mutagen.io/documentation/introduction/installation
I create my Mutagen sync with a command like:
Other than that, it mostly just worked! Feel free to get in touch if you have more specific questions.
- https://mac.getutm.app/gallery/ubuntu-20-04 - https://docs.docker.com/engine/install/ubuntu/ - https://mutagen.io/documentation/introduction/installation
I create my Mutagen sync with a command like:
mutagen sync create --name=mysite ~/Sites/mysite [email protected]:~/mysite --ignore=node_modules,vendor --ignore-vcs --default-owner-alpha=tallytarik --default-group-alpha=staff
Other than that, it mostly just worked! Feel free to get in touch if you have more specific questions.
I'm using Multipass [https://multipass.run], 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.
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...).
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.
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 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.
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.
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.
It’s not local docker, but
Otherwise its a treat. No local storage eaten up, no cores pinned to 100%, no reserved memory, no (additional) VM layer, …
export DOCKER_HOST=ssh://[email protected]
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.
https://github.com/jedahan/podman-desktop
https://github.com/jedahan/podman-desktop
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 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.
[0] https://github.com/containerd/nerdctl/pull/642
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.
[0] https://github.com/containerd/nerdctl/pull/642
what about lima? it seems more easier to get.
https://github.com/lima-vm/lima
https://github.com/lima-vm/lima
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.
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?
Does this help or is the issue lower level?
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.
Something's gone deeply wrong somewhere.
Something's gone deeply wrong somewhere.
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!
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.
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.
Wow, I hadn't thought of that use case. I agree Python's toolchain is just not easy to work with.
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
Oracle has plenty of happy customers that don't think twice about using Virtualbox.
Plus they aren't the only game in town with VM tooling.
Plus they aren't the only game in town with VM tooling.
This won't work on the new M1 macs since it uses VirtualBox
Yeah :(
Ever since I switched to an M1, I haven't found a way to reliably build and run x86_64 containers on it.
Docker desktop with Qemu is not just painfully slow, it's also very buggy and some containers just can't be built without crashing.
Is there any alternative?
Ever since I switched to an M1, I haven't found a way to reliably build and run x86_64 containers on it.
Docker desktop with Qemu is not just painfully slow, it's also very buggy and some containers just can't be built without crashing.
Is there any alternative?
I haven't tested it, but Lima purports to support it:
https://github.com/lima-vm/lima/blob/master/docs/multi-arch....
https://github.com/lima-vm/lima/blob/master/docs/multi-arch....
Give
https://github.com/abiosoft/colima
A try, I’ve been using it for a few months on both m1 and x64.
It works really well.
A try, I’ve been using it for a few months on both m1 and x64.
It works really well.
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.
Exactly.
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.
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.
Have you tried
https://threedots.ovh/blog/2021/01/huawei-exagear-x86_64-app...
maybe it works faster than qemu for a chrooted environment.
maybe it works faster than qemu for a chrooted environment.
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.
Try UTM https://mac.getutm.app/
Run x86 Linux of your choice there, install Docker inside there. Run it there.
Run x86 Linux of your choice there, install Docker inside there. Run it there.
You'll get the same issues, since utm uses qemu. Tried it a few days ago with x64 linux only to have the os crash while copying stuff over smb
FWIW I switched from Docker Desktop to UTM+Ubuntu+Docker a few months ago and it has been great.
VMware fusion plus Vagrant.
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 heart of this is docker-machine which is deprecated
Yup..
> Docker Machine has been deprecated. Please use Docker Desktop instead.
https://docs.docker.com/machine/
> Docker Machine has been deprecated. Please use Docker Desktop instead.
https://docs.docker.com/machine/
[deleted]
Gitlab maintains a fork of docker-machine with critical bug fixes that I've been using recently since Docker deprecated it: https://gitlab.com/gitlab-org/ci-cd/docker-machine
5. Install Docker Machine docker-machine
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?
Just visit the repo: https://github.com/docker/machine It is archived and hasn't had a commit in almost 2.5 years. See also: https://github.com/docker/roadmap/issues/245
I use Rancher Desktop as an alternative to Docker Desktop. It’s alright.
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?
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 indeed did bump into a few things. You can check my other comment about that : https://news.ycombinator.com/item?id=30118961
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
Have you hit any sharp edges yet? I imagine there might be a few. Anything you can share would be great
Port forwarding is currently broken if you use dockerd but it will be fixed in the next release or you can run a command to fix it yourself. See https://github.com/rancher-sandbox/rancher-desktop/issues/12...
It fails to setup some filesystem links because of Unix permissions. You can fix it in command line. See https://github.com/rancher-sandbox/rancher-desktop/issues/11...
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...
It fails to setup some filesystem links because of Unix permissions. You can fix it in command line. See https://github.com/rancher-sandbox/rancher-desktop/issues/11...
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...
thanks!
Looks like the first and last issue is fixed in 1.0.0 (released 2 days ago). So only that second issue remains for now.
Looks like the first and last issue is fixed in 1.0.0 (released 2 days ago). So only that second issue remains for now.
That’s good news. I did miss the release.
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.
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.
However, using https://mutagen.io/ to keep the container in sync has worked remarkably well - it's greatly improved the speed of the container.
Awesome. I'll try it out. Thanks!
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.
They just assume people want to be in compliance. Same way I wouldn't misuse gpl code at my work.
I'm sure they just buy a list of $10million+ company ip reservations and let their lawyers go to town.
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).
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).
We also need an M1 compatible UTM version of that. To bad it seems UTM cannot be automated with vagrant like VirtualBox.
UTM is just QEMU under the hood, which should be easy to automate.
Tried colima and minikube.
Minikube has some complex network issue, colima works without any problem out of box.
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.
https://github.com/bcicen/ctop
https://github.com/bcicen/ctop
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?
Podman or minikube are the solutions I've gone with. Great software!
Ehh I prefer limactl/nerdctl to this.
Should this be faster than Docker Desktop?
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.
This is x86-only, right?
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!
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!
The proper way to develop with docker on Mac is using a Linux dual-boot.
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/