On Linux, Docker will continue to be free so usage of Podman might be for other reasons (the fact it doesn’t have a daemon is quite nice).
Not clear to me if this works on Windows though, seems like it’s only macOS.
(the fact it doesn’t have a daemon is quite nice)
(the fact it doesn’t have a daemon is quite nice)
Wow this is a great feature. I’m going to have to check out podman now. I never really sweat the overhead of the daemon but in most cases I don’t need it, so doing without it and managing everything through my supervisor system would be fantastic.
Yeah, it’s not even really about “overhead”, it’s about “there’s this long running thing that you ask to do everything on your behalf”. With podman, when you run a container, you are running it, it starts as a child process of the process that ran it, it has your permissions, etc. Which also makes it work with process supervisors in a way that docker doesn’t really… /usr/bin/docker is just an RPC client.
Yeah, this is currently focussed on MacOS (and not yet compatible with the new M1 CPUs) but it should be roughly the same for Windows also as the approach Podman has taken is same for both Mac and Windows (leverage a linux VM for the Podman engine).
I’d be really intersted to hear if anyone follows this on Windows and what the differences are.
https://podman.io/getting-started/installation#windows doesn’t list machine. I guess there’s WSL though.
Q: Why choose Docker or Podman over Nix or Guix?
Edit with some rephrasing: why run containers over a binary cache? They can both do somewhat similar things in creating a reproductible build (so long as you aren’t apt upgradeing in your container’s config file) and laying out how to glue you different services together, but is there a massive advantage with one on the other?
I can’t speak for the OP, but for myself there are three reasons:
Docker for Mac is just so damn easy. I don’t have to think about a VM or anything else. It Just Works. I know Nix works natively on Mac (I’ve never tried Guix), but while I do development on a Mac, I’m almost always targeting Linux, so that’s the platform that matters.
The consumers of my images don’t use Nix or Guix, they use Docker. I use Docker for CI (GitHub Actions) and to ship software. In both cases, Docker requires no additional effort on my part or on the part of my users. In some cases I literally can’t use Nix. For example, if I need to run something on a cluster controlled by another organization there is literally no chance they’re going to install Nix for me, but they already have Docker (or Podman) available.
This is minor, I’m sure I could get over it, but I’ve written a Nix config before and I found the language completely inscrutable. The Dockerfile “language”, while technically inferior, is incredibly simple and leverages shell commands I already know.
I am not a nix fan, quite the opposite, I hate it with a passion, but I will point out that you can generate OCI images (docker/podman) from nix. Basically you can use it as a Dockerfile replacement. So you don’t need nix deployed in production, although you do need it for development.
As someone who is about to jump into nixos, Id love to read more about why you hate nix.
I’m not the previous commenter but I will share my opinion. I’ve given nix two solid tries, but both times walked away. I love declarative configuration and really wanted it to work for me, but it doesn’t.
This speaks to my experience with Nix too. I want to like it. I get why it’s cool. I also think the language is inscrutable (for Xooglers, the best analogy is borgcfg) and the thing I want most is to define my /etc files in their native tongue under version control and for it all to work out rather than depend on Nix rendering the same files. I could even live with Nix-the-language if that were the case.
I also think the language is inscrutable (for Xooglers, the best analogy is borgcfg)
I also think the language is inscrutable (for Xooglers, the best analogy is borgcfg)
As a former Google SRE, I completely agree—GCL has a lot of quirks. On the other hand, nothing outside Google compares, and I miss it dearly. Abstracting complex configuration outside the Google ecosystem just sucks.
Yes, open tools exist that try to solve this problem. But only gcl2db can load a config file into an interactive interface where you can navigate the entire hierarchy of values, with traces describing every file:line that contributed to the value at a given path. When GCL does something weird, gcl2db will tell you exactly what happened.
Thanks for the reply. I’m actually not a huge fan of DSLs so this might be swaying me away from setting up nixos. I have a VM setup with it and tbh the though of me trolling through nix docs to figure out the magical phrase to do what I want does not sound like much fun. I’ll stick with arch for now.
If you want the nix features but a general purpose language, guix is very similar but uses scheme to configure.
I would love to use Guix, but lack of nonfree is killer as getting Steam running is a must. There’s no precedence for it being used in the unjamming communities I participate in, where as Nix is has sizable following.
So use Ubuntu as the host OS for Guix if you need Steam to work. Guix runs well on many OS
Sorry for the very late reply. The problem I have with nixos is that it’s anti-abstraction in the sense that I elaborated on here. Instead it’s just the ultimate wrapper.
To me, the point of a distribution is to provide an algebra of packages that’s invariant in changes of state. Or to reverse this idea, an instance of a distribution is anything with a morphism to the category of packages.
Nix (and nixos) is the ultimate antithesis of this idea. It’s not a morphism, it’s a homomorphism. The structure is algebraic, but it’s concrete, not abstract.
People claim that “declarative” configuration is good, and it’s hard to attack such a belief, but people don’t really agree on what really means. In Haskell it means that expressions have referential transparency, which is a good thing, but in other contexts when I hear people talk about declarative stuff I immediately shiver expecting the inevitable pain. You can “declare” anything if you are precise enough, and that’s what nix does, it’s very precise, but what matters is not the declarations, but the interactions and in nix interaction means copying sha256 hashes in an esoteric programming language. This is painful and as far away from abstraction as you can get.
Also notice that I said packages. Nix doesn’t have packages at all. It’s a glorified build system wrapper for source code. Binaries only come as a side effect, and there are no first class packages. The separation between pre-build artefacts and post-build artefacts is what can enable the algebraic properties of package managers to exist, and nix renounces this phase distinction with prejudice.
To come to another point, I don’t like how Debian (or you other favorite distribution) chooses options and dependencies for building their packages, but the fact that it’s just One Way is far more important to me than a spurious dependency. Nix, on the other hand, encourages pets. Just customize the build options that you want to get what you want! What I want is a standard environment, customizability is a nightmare, an anti-feature.
When I buy a book, I want to go to a book store and ask for the book I want. With nix I have to go to a printing press and provide instructions for printing the book I want. This is insanity. This is not progress. People say this is good because I can print my book into virgin red papyrus. I say it is bad exactly for the same reason. Also, I don’t want all my prints to be dated January 1, 1970.
For me personally, I never chose Docker; it was chosen for me by my employer. I could maybe theoretically replace it with podman because it’s compatible with the same image format, which Guix (which is much better designed overall) is not. (But I don’t use the desktop docker stuff at all so I don’t really care that much; mostly I’d like to switch off docker-compose, which I have no idea whether podman can replace.)
FWIW Podman does have a podman-compose functionality but it works differently. It uses k8s under the hood, so in that sense some people prefer it.
This quite nicely sums up for me 😄 and more eloquently than I could put it.
If you’re targeting Linux why aren’t you using a platform that supports running & building Linux software natively like Windows or even Linux?
… to call WSL ‘native’ compared to running containers/etc via VMs on non-linux OS’s is a bit weird.
I enjoy using a Mac, and it’s close enough that it’s almost never a problem. I was a Linux user for ~15 years and I just got tired of things only sorta-kinda working. Your experiences certainly might be different, but I find using a Mac to be an almost entirely painless experience. It also plays quite nicely with my iPhone. Windows isn’t a consideration, every time I sit down in front of a Windows machine I end up miserable (again, YMMV, I know lots of people who use Windows productively).
Because “targeting Linux” really just means “running on a Linux server, somewhere” for many people and they’re not writing specifically Linux code - I spend all day writing Go on a mac that will eventually be run on a Linux box but there’s absolutely nothing Linux specific about it - why would I need Linux to do that?
WSL2-based containers run a lightweight Linux install on top of Hyper-V. Docker for Mac runs a lightweight Linux install on top of xhyve. I guess you could argue that this is different because Hyper-V is a type-1 hypervisor, whereas xhyve is a type-2 hypervisor using the hypervisor framework that macOS provides, but I’m not sure that either really counts as more ‘native’.
If your development is not Linux-specific, then XNU provides a more complete and compliant POSIX system than WSL1, which are the native kernel POSIX interfaces for macOS and Windows, respectively.
Prod runs containers, not Nix, and the goal is to run the exact same build artifacts in Dev that will eventually run in Prod.
Lots of people distribute dockerfiles and docker-compose configurations. Podman and podman-compose can consume those mostly unchanged. I already understand docker. So I can both use things other people make and roll new things without using my novelty budget for building and running things in a container, which is basically a solved problem from my perspective.
Nix or Guix are new to me and would therefore consume my novelty budget, and no one has ever articulated how using my limited novelty budget that way would improve things for me (at least not in any way that has resonated with me).
Anyone else’s answer is likely to vary, of course. But that’s why I continue to choose dockerfiles and docker-compose files, whether it’s with docker or podman, rather than Nix or Guix.
Not mentioned in other comments, but you also get process / resource isolation by default on docker/podman. Sure, you can configure service networking, cgroups, namespaces on nix yourself, just like any other system and setup the relevant network proxying. But getting that prepackaged and on by default is very handy.
You can get a good way there without much fuss with using the Declarative NixOS containers feature (which uses systemd-nspawn under the hood).
I’m not very familiar with Nix, but I feel like a Nix-based option could do for you what a single container could do, giving you the reproducibility of environment. What I don’t see how to do is something comparable to creating a stack of containers, such as you get from Docker Compose or Docker Swarm. And that’s considerably simpler than the kinds of auto-provisioning and wiring up that systems like Kubernetes give you. Perhaps that’s what Nix Flakes are about?
That said I am definitely feeling like Docker for reproducible developer environments is very heavy, especially on Mac. We spend a significant amount of time rebuilding containers due to code changes. Nix would probably be a better solution for this, since there’s not really an entire virtual machine and assorted filesystem layering technology in between us and the code we’re trying to run.
Is Nix a container system…? I though it was a package manager?
It’s not, but I understand the questions as “you can run a well defined nix configuration which includes your app or a container with your app; they’re both reproducible so why choose one of the over the other?”
It’s possible to generate Docker images using Nix, at least, so you could use Nix for that if you wanted (and users won’t know that it’s Nix).
These aren’t mutually exclusive. I run a few Nix VMs for self-hosting various services, and a number of those services are docker images provided by the upstream project that I use Nix to provision, configure, and run. Configuring Nix to run an image with hash XXXX from Docker registry YYYY and such-and-such environment variables doesn’t look all that different from configuring it to run a non-containerized piece of software.
Other TL;DR: Just pay for the thing if you’re a big company.
It’s kind of easy to say, and likely doable in the smaller end of the “big company”. But at some level of corporate, you also have to fight with “the process”. In other words, if I get a choice to spend a week migrating to podman or to deal with expense approval chains, legal, it, management, etc. then there’s a really good chance I’m going with podman. (If no critical features are missing)
Wouldn’t you also have to get legal and IT approval to introduce Podman in places where you were previously using Docker?
Depends on the project. In some cases yes, in others, if it already comes with an approved distro then no.
No doubt these places exist, but the theoretical company you describe sounds like a really miserable place to work
There’s also an argument that we should try to support good open source projects when they offer paid products that we actually also use.
I made this dumb little script to replace Docker-Desktop. It uses multipass to create an ubuntu vm, and sets up podman for it. Any feedback is appreciated.
podman-desktop --cpus 2 --disk 10G --identity ~/.ssh/github
On Windows/WSL it was fairly painless. I uninstalled Docker Desktop. Uninstall docker-ce from my WSL. installed podman. Didn’t even alias it and just use the command directly.
Found the minikube thing, which is a great alternative. There is also: https://rancherdesktop.io for those that want more of a Docker Desktop solution.
Honestly works great and I don’t miss it. Give Rancher Desktop a try if you don’t want the hassle of moving to Podman or dealing with other stuff.
but i think between Rancher Desktop, Minikube and Podman, Docker and Docker desktop wont be missed by me.
Tl;dr only mini kube is a good replacement on Mac, according to the author
Timely, going to try this. Does anyone have recommendations for other replacements?
One issue if podman runs 1 instance for each pod, and that’s about 40MB rss. Docker doesn’t have that issue
Since the projects I use at work rely on docker-compose, I can’t make the switch. Unfortunately, podman-compose doesn’t support the whole syntax and features. It is possible to rewrite a compose file in a shell script, but this is not handy to maintain. I used such alternative for deploying and updating a container on a server though.
A big advantage of podman on Linux servers is that it doesn’t bypass netfilter unlike Docker, which is a pain to get it right.