I’m afraid this is going to attract the “why use podman when docker exists”-folks, so let me put this under the supposition that you’re already sold on (considering) using podman for whatever reason. (For me, it has been the existence of pods, to be used in situations where pods make sense, but in a non-redundant, single-node setup.)

Now, I was trying to understand the purpose of quadlets and, frankly, I don’t get it. It seems to me that as soon as I want a pod with more than one container, what I’ll be writing is effectively a kubernetes configuration plus some systemd unit-like file, whereas with podman compose I just have the (arguably) simpler compose file and a systemd file (which works for all pod setups).

I would get that it’s sort of simpler, more streamlined and possibly more stable using quadlets to let systemd manage single containers instead of putting podman run commands in systemd service files. Is that all there is to it, or do people utilise quadlets as a kind of lightweight almost-kubernetes distro which leverages systemd in a supposedly reasonable way? (Why would you want to do that if lightweight, fully compliant kubernetes distros are a thing, nowadays?)

Am I missing or misunderstanding something?

  • just_another_person@lemmy.worldEnglish
    6·
    2 months ago

    It’s a systemd-style way to manage podman containers that aims to be as easy to manage as compose/swarm. Not quite an integration, but operates similarly, and about as easy to read. Less heavy than managing a local micro-k8s cluster. That’s about it.

    • dont@lemmy.worldOPEnglish
      2·
      2 months ago

      Thank you, I think the “less heavy than managing a local micro-k8s cluster”-part was a great portion of what I was missing here.

  • markstos@lemmy.worldEnglish
    2·
    2 months ago

    I like to manage services maximally with systemd so it was a natural fit for me.

    It did not seem difficult to set up web and database quadlets so they are properly networked.

  • oranki@lemmy.worldEnglish
    2·
    2 months ago

    I didn’t read all the comments, so someone may have pointed this out already.

    One of the main ideas is probably something like Fedora CoreOS, where the Quadlet systemd files are automatically created during first boot with something like Kickstart or cloud-init.

    Instead of shipping the applications with the image, the OS image can be very minimal, while still being able to run very complex stuff.

    When you add the fact that CoreOS and other atomic distros can update themselves in the background, and boot to an updated base image, the box just needs periodic reboots and everything stays updated and running with basically no interaction from the admin at all, best case.

    Probably not so useful in the self-hosting / homelab context, but I can imagine the appeal on a larger scale.

    I’ve been using Quadlet+Podman kube YAMLs for a while for my own self-hosted services, and it’s pretty rock solid. Currently experimenting with k3s, but I think I’ll soon switch back. Kubernetes is nice, but it’s a lot more fragile for just a single node. And there’s way too much I don’t understand…

    I wrote a couple blog posts about the homelab setup, planning to add more when I have time. Give a read if you’re interested: https://oranki.net/tags/self-hosting-my-way/

    • dont@lemmy.worldOPEnglish
      2·
      2 months ago

      Thanks, the bootstrapping idea was not mentioned in the comments, yet. And your blog looks promising, will have a more through look soon.