Lightweight Alpine VMs on macOS(beringresearch.github.io) |
Lightweight Alpine VMs on macOS(beringresearch.github.io) |
They are not all the same when you get down to it, though. The "different opinions" about how to plumb traffic back out from a container (DNAT/SNAT via a bridge, macvlan, whether using a CNI directly is supported), whether a service/daemon should be the primary entrypoint (docker, containerd) or whether it's optional (podman), whether they speak to runc at all (containerd/docker yes, podman defaults to crun, kata is also an option, and others), what kind of storage overlays and plugins are allowed, etc are more than "opinions".
The devil is in the details. Colima is "basically a drop in replacement for docket desktop" under the assumption that you aren't doing anything very complex with Docker. In particular, complex networking is likely to fail/explode.
Does Colima work with Docker Compose?
I abandoned Docker on the Mac because of that, and haven't touched it since. That was early 2021; maybe it's faster now.
I mean I want to use containers but on top of setting up the host, they require composing containers (even when ready made for customizations), networking, logging and fight for more memory when using memory hungry stuff in conjunction (like elastic or other db).
If my main job was devops, I suppose I would make myself more valuable by doing everything in containers but when I deploy an app it is because I have to on top of many other duties so being able to not only setup but troubleshoot and fix outages quickly is most important (and I hope a full time devops person, if I ever get one) will help me migrate all that some day so it looks nice and neat.
- spyware (transmits private data off your machine without consent when it crashes, which it does a lot)
- nonfree software
- has a git repo so you don't notice it's nonfree software
Colima is a little but lower level but works very well. Rancher Desktop had some struggles a while back but most of the developers who are new to the company seem to be using it for local kubernetes.
That's the key part: Your positive experience is with PCs running linux I guess.
Slight aside though, they have used the Material theme for MKDocs, which is much more than a theme, it's a whole extension package of bells a whistles for MKDocs. I'm not actually too keen on "Material for MKDocs" [0], I like all the clever plugins, but the theme itself I find distracting and too "loud". The theme jumps out more than the content itself.
In the Python ecosystem Material for MKDocs seems to be the leading default at the moment, however I much prefer Furo for Sphinx, it's much cleaner, it's about putting the content front and centre. It does also have a similar set of plugins for Sphinx adding those bells and whistles.
[0]: https://squidfunk.github.io/mkdocs-material/customization/#a...
[1]: https://twitter.com/squidfunk/status/1598341366869856257/pho...
But I often don’t. When I’m using Docker on my Mac it’s usually because I’m trying to use Docker. I need to use an existing Docker container or build a new one to fit some purpose with a Dockerfile.
I guess it’s nice that there would be a simpler way to launch one-off containers or containers for myself that aren’t expected to work like every other Docker container.
Is this a common need? Is there something that makes this more than I’ve noticed? The fact I work in a “Docker for containers” place may be preventing me from seeing what would make this shine.
Sublime is just one case. We had a Python service running in an Alpine container because it was thought as "mean and lean" by someone. Sound choice, right?
Guess what: we used a handful of (popular) Python modules that are backed by native libraries and PyPi didn't have musl-linked versions for them. The "mean and lean" Alpine-based image ended up weighing more than a debian-slim-based image.
IIRC npm will compile native extensions, sounds like PyPi (is that a package manager?) distributes binaries.
https://pkgs.alpinelinux.org/package/edge/testing/x86_64/cod...
Edit: which... Might also be available?
As someone with MacAlpine heritage I have never been more disappointed in two letters, though.
I actually have a Manjaro laptop that I used for work for almost a year and it was great. Except for the hardware (generic cheapo wintel garbage). I'm back on a Mac now. Nice M1 laptop. Fast, silent, good keyboard and screen. Wonderful to use. Mostly my biggest headache is muscle memory for different key bindings and keyboard layout because I still use the linux laptop once in a while. But otherwise all my stuff (including docker) just works on both sides.
Docker for mac is nice but the licensing can be a bit of a show stopper. I've yet to try some of the alternatives mentioned here. I did use qemu on my old intel mac for a while with some simple environment variables to make the homebrew version of docker use ssh to my vm. It works but it can be a bit wonky with things like port forwarding and volumes. You can make all that work but it is a bit fiddly. Most of the proper alternatives make this a bit more seamless. But I'd recommend trying it just to de-mystify the whole process.
There is a docker desktop for linux even; which just goes to show that it does do a few things that are worthwhile having for some people. Even on Linux. I'm mostly a cli guy so I don't care about the UI/UX that it provides. But some people seem to like that.
The question applies both ways: what advantage (other than native container support) do I get by running Linux?
Personally I would love to see OCI containers supported natively on other operating systems. Currently you get the same VM crapshow on e.g. OpenBSD, except the community is several orders of magnitude smaller, so you don't even get prepackaged solutions.
> Personally I would love to see OCI containers supported natively on other operating systems. Currently you get the same VM crapshow on e.g. OpenBSD, except the community is several orders of magnitude smaller, so you don't even get prepackaged solutions.
Talk to your OS vendor. They are the ones who are preventing this from working.
I believe improvements have been made, but a lot of people these days check out their code directly in the container rather than using bind mounts, leveraging the fact that a lot of editors/IDEs now will interface directly with the containers.
But... watch out for software compatibility: m1/m2 requires recompiling from source which is painless... when it works. I recently needed syslinux and had to move to x86 cloud instance. Fortunately, docker made that easy.
https://pkgs.alpinelinux.org/package/edge/testing/aarch64/co...
Imho Mac hardware, especially with M1/M2 is the best value for money one can buy right now. Performance is outstanding, coupled with all day battery life. Build is also super premium including the keyboard now. I tried Lenovo X1, Dell XPS 13 which are supposedly the best PC laptops and found them way inferior... and more expensive!
Regarding macOS, I completely understand that some people like it, some don't. But we all want good tools on that hardware :)
So Macs are what corporate provides to developers.
There are also some pretty good apps for macOS that just aren’t available on Linux.
And then some of us really enjoy the desktop experience of macOS.
When I need Linux tools they are easy to access via Lima. (One could also use Parallels or VirtualBox, but IMHO Lima is far more ergonomic.)
What can you use to do that?
I think there’s stuff that uses it under the hood like colima and rancher.
Basically the issue is that quite a lot of software is amd64 only and they haven’t cross complied binary layers for arm64.
So for local development you have to emulate.
It’s a shame there’s not a way to leverage rosetta2 really.
You can either run an alternative architecture or an alternative OS. Running MacOS software for x86 is running through an interpreter.
If you want to run x86 Linux software, then MacOS on Arm is just one too many steps away.
I've never suggested this at any point.
> OpenBSD already has containerd support.
So what are the leftover steps we'd need to take, from "has containerd support" until "pkg_add docker && rcctl start dockerd && docker run -ti --rm hello-world"?
But the proposal here isn't about running NixOS as your OS, since we're talking about macOS. It's about using Nix as an additional package/environment manager on top of another OS/kernel, in this case macOS, though of course Linux is well-supported too.
Each file in Nix is stored in a path that's computed based on the hash of the relevant source code, and depends on other files (e.g., libraries) via their hash-based paths, too. So you can straightforwardly have multiple execution environments with their own dependencies that don't interfere. It's an alternative solution to the dependency problem: containers leave paths alone, but create a new root filesystem for each container. Nix programs all share one root filesystem, but modify the paths so nothing uses e.g. /usr/bin or /usr/lib.
Precisely because Nix binaries isolate themselves from /usr and carry their own dependencies, the Nix packaging repo "nixpkgs" can be used on any Linux machine, not just NixOS ones. And the Nix folks also build nixpkgs for macOS, so most software in nixpkgs can be installed on a macOS machine too. This gets you a solution to the dependency problem on macOS itself (because there are no Linux-style containers on macOS). If you want, it also gets you a relatively consistent dev environment for applications that will be eventually deployed on Linux: although the kernel is different and of course the binaries are compiled for different kernels, the entire userspace can be the same on macOS and Linux.
For very complicated reconfigurations, it might be advisable to reboot if that involves changes to services that are only started during boot time. But that's the case for nearly any OS...
And of course it does not require a reboot.
Also, are you using AMD or ARM images for those?
even if the containers themselves only use 128MiB total: the VM will cordon off everything it's told to; which most people are unlikely to change until there's an issue, and is configurable down to 1GiB as a minimum.
FWIW Docker Desktop on my machine (M2 Macbook Air; 24GiB Ram) defaulted to using 8GiB of RAM.
Scratching my head as to why devs are buying up these new macs knowing up front that they will not work well for the job they were bought for.
Why not make it easier for yourself and have your dev machine match up with prod?
You can run a constant VM with 2/4/8/128gb of ram or whatever you need. I use one at work for years and I think mine is 16gb of ram and it’s way over provisioned most of the time. Unlike how you might expect, treat the cloud vm like a work laptop not a production service. Let people write scripts that stay there, let people keep it on 24/7, available on demand, etc. It’s a cloud laptop not a production VM.
Even giving people a headless Intel NUC to connect their laptops too would be way, way cheaper (assuming you're just doing development).
Having said that, cloud development means you don't need big capex orders for laptops all the time, and it's probably easier to secure.