Comment by koe123

6 hours ago

Honestly I reach for podman or `nix develop` any chance I get. What is the edge that docker provides these days?

> What is the edge that docker provides these days?

hub.docker.com mainly, the centralized docker registry. A bit like Github, there are plenty of alternatives. But that's where you find most people pushing their containers.

And then there is Docker Desktop which a lot of users seem to like.

I switched to colima myself recently (on a mac). I think people overthink all this stuff a bit. Colima doesn't have a UI; but that's fine for me. I mainly use it to run stuff from the command line or from scripts. I wasn't using the Docker Desktop UI very much either.

Colima is a simple wrapper around Lima, which is a simple wrapper around qemu or Apple's virtualization layer. The resulting vm runs a simple Linux distribution with some file mounts and network tunneling to give you a similar experience as Docker Desktop. Which does exactly the same thing in the end of course.

Linux runs containers just fine. The main thing you need for containerization is a Linux kernel. People have actually hacked together docker alternatives with just bash and namespaces. I used a plain qemu vm for a while with the docker socket pointing to an ssh tunnel on my mac. Works amazingly well but it has some limitations. Colima is easier to manage.

People have mentioned several of the other alternatives already. They all can work with the same command line tooling. If you need a UI, colima is probably too barebones. But otherwise, things like IDEs and other tools work (e.g. lazydocker, vs code, intellij, etc.) just fine with it. So the added value of extra UI is limited to me at least.

I think the container runtime inside the vm (podman, containerd, whatever) is mostly not that relevant for developers. It's a bit of an implementation detail. As long as docker and docker compose work on the command line, I'm happy.

How do you manage your containers in podman declaratively?

I tried to substitute docker-compose with Podman and Quadlets on a test server the other day, but was shocked how badly described the overall concept is. Most materials I found glimpsed through ability to run it as root/user and how different that is in configuration, and repeated the same 4-6 commands mantra.

Spent a few hours on it and just... failed to run a single container. systemctl never noticed my qualdet definitions, even if podman considered my .container file registered.

A bit.. frustrating, I expected smoother sailing.

  • This has also been my experience, I'm used to using compose everywhere. I like the declarative file - tried podman and I found the documentation around the concept so scarce and all related to running things as non-root instead of telling me how my docker-compose becomes podman-compose. Still using docker everywhere because of that. Docker swarm mode has also worked wonders as an evolution to my compose files.

    • I know podman-compose, have some homelab services running on it for a few years, but honestly found multiple ones that failed. It's far from drop-in replacement.

  • The podman kube support? It provides similar functionality as docker-compose, using a yaml file which is a subset of the Kubernetes pod definition syntax.

    Then you can just create a few line systemd unit definition, and it integrates as a normal systemd unit, with logs visible via journalctl etc.

    • This seems to be the way.

      Short of weeding through the docs, I found the "Play with Kube using Podman" talk on DevConfs YouTube channel helpful.

      2 replies →

  • Podman supports Compose files, so there's that. I've only glimpsed at Quadlets and I agree they seem very esoteric, especially if you're not very well versed in systemd service definitions.

  • Yeah I think Quadlet just has bad docs. They document the whole API but iirc there is no: ok this is the hello world for running cowsay as a systemd unit

  • quadlets fully depend on systemd doing its work. So, assuming you are running rootless, if you change your quadlets, you will need

      systemctl --user daemon-reload
    

    to let systemd ingest the changes. And, if you have configured to start your container on boot, then still you have to start the container by hand, as you typically won't reboot during development. If you have multiple containers, it might be easiest to have them in one pod, so you only need to start the pod.

    I agree that the documentation needs a good tutorial to show the complete concept as a starting point. There are multiple ones though on the internet.

    • yeah, that's exactly what every tutorial says. And I know systemd more or less, daemon-reload is no stranger to me.

      That was not sufficient. Both for global o user setup.

    What is the edge that docker provides these days?

Enterprise support and Docker Desktop makes it nearly seamless to get set up using containers. I've tried Rancher/podman/buildah and the experience introduced too much friction for me without being on a Linux system.

  • > [...] without being on a Linux system.

    I'll add that needing to be on the "right" Linux system is another strike against Podman. Last I checked if I wasn't on a RedHat derivative I was in the wilderness.

    • Huh. I tried docker. Didn’t like the odor of enshittification, and so switched to podman (desktop). I use it on macOS, and deploy on Ubuntu. It’s been smooth sailing.

      I found the signal to noise ratio better in Podland. As a newb to docker space, I was overwhelmed with should I swarm, should I compose, what’s this register my thing? And people are freaking about root stuff. I’m sure I still only use and understand about 10% of the pod(man) space, buts way better than how I felt in the docker space.

      I miss when software engineering put a high value on simplicity.

      1 reply →

> What is the edge that docker provides these days?

That you are not the average developer

  • Not very clear what you mean... well you haven't actually given them an answer to their question.

    Are you suggesting that docker provides an (unspecified) edge to developers who are better than average? Or to those who are mediocre? Or...

    • I mean that the average developer will follow/use what has the most traction already and in the containers space, like it or not, it's still Docker.