Docker for Mac Without Docker Desktop(github.com) |
Docker for Mac Without Docker Desktop(github.com) |
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?
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?
Have you hit any sharp edges yet? I imagine there might be a few. Anything you can share would be great
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...
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.
However, using https://mutagen.io/ to keep the container in sync has worked remarkably well - it's greatly improved the speed of the container.
They just assume people want to be in compliance. Same way I wouldn't misuse gpl code at my work.
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).
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!
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.
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://github.com/containerd/nerdctl mine came bundled with Rancher desktop, and 'nerdctl compose up' is all I've needed
Have you tried Kompose? Is it generating the crap files you were not fond of?
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.
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).
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 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.
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).
Come on Apple. Microsoft can do it.
edit: this seems like a new development since my last whine/complaint on this topic:
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....
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.
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 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).
You could probably grab a server for a bit less from their server auction.
A performance comparison between this solution and Docker for Mac would have been great.
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.
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.
Edit: upon inspection I see that is what the link is about, so it probably has some merit.
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.)
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.
do you know by any chance if vmware fusion has support for pxe boot?
- 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 ubuntu@192.168.64.2:~/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.
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...).
export DOCKER_HOST=ssh://user@some.nix.box
Otherwise its a treat. No local storage eaten up, no cores pinned to 100%, no reserved memory, no (additional) VM layer, …
We got lucky where I work, and already had a RHEL license which gives us Docker Desktop Enterprise too, I think.
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.
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.
Does this help or is the issue lower level?
Something's gone deeply wrong somewhere.
Regardless, would still be great if we had native macOS container support!
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.
Plus they aren't the only game in town with VM tooling.
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?
https://github.com/lima-vm/lima/blob/master/docs/multi-arch....
maybe it works faster than qemu for a chrooted environment.
Run x86 Linux of your choice there, install Docker inside there. Run it there.
> Docker Machine has been deprecated. Please use Docker Desktop instead.
If you need something like the docker desktop UI, check out portainer.
It doesn't seem like a huge leap from sandboxing to containerization.
They also might consider supporting BSD-style jails.
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.
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.
#!/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"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 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 just made the switch to colima. Thanks for mentioning it!
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.
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.
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
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.
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.
A try, I’ve been using it for a few months on both m1 and x64.
It works really well.
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 ?
https://hub.docker.com/r/kindest/node/tags
You can also provide any kubeadm config options you want, as kind bootstraps with upstream kubeadm
Minikube, no sarcasm. I'm also going to use Minikube.
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.
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.
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.
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.)
Otherwise they are just UNIX developers that don't care which POSIX platform they are actually using.
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.
is that the motivator for most, then?