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.world
    link
    fedilink
    English
    815 hours 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.worldOP
      link
      fedilink
      English
      13 hours 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.

    • @mosiacmango@lemm.ee
      link
      fedilink
      English
      4
      edit-2
      13 hours ago

      Yup. I read it as “compose and manage containers with systemd.”

      Sure, there is a k8s layer abstracted into podman to do this, but you don’t manage or interact with it. Everything is a systemd unit file, a simple text document with a well understood structure. Containers are started and logged like services.

      Easy, direct, tidy.

      • @dont@lemmy.worldOP
        link
        fedilink
        English
        13 hours ago

        Understood, thanks, but if I may ask, just to be sure: It seems to me that without interacting with the kubernetes layer, I’m not getting pods, only standalone containers, correct? (Not that I’m afraid of writing kube configuration, as others have inferred incorrectly. At this point, I’m mostly curious how this configuration would be looking, because I couldn’t find any examples.)

        • @mosiacmango@lemm.ee
          link
          fedilink
          English
          2
          edit-2
          3 hours ago

          I’m still new to this myself, but yes that’s the gist of it. This isn’t k8s or even k3s. It’s an easy way to deploy a container via code on a single node system using the already present systemd for management. It let’s you pretend that Linux handles containers natively like it does daemons.

          This article from redhat has more information about the why and what.