EDIT: For some context, I recently gave podman another go. I have a few services on my homelab server set up in docker containers, so I tried migrating to podman.

After the second major bug (open issue on github) I encountered looked like it would require completely dropping using compose files to work around, I gave up and went back to docker.

I like the idea of podman, but it’s just not stable. I’ll try again in a year or so.

As a bonus, docker’s CLI is significantly nicer.

  • CallMeAl (like Alan)@piefed.zipEnglish
    1·
    9 days ago

    Sounds like you are more interested in how the “house” was painted while I’m more focused on the construction materials and architecture.

    If you truly don’t care what the source code looks like or how it works internally, then we aren’t even having the same conversation.

    • hirihit640@sh.itjust.worksEnglish
      1·
      9 days ago

      For sure, that’s why I asked what you meant by “clean”.

      Ultimately, I’m a podman user, not a podman developer. So the interface and user experience matter a lot more to me than the internal architecture. Though architectural decisions to tend to affect the trajectory of a project as a whole, docker compose still seems to be holding up just fine.

      • CallMeAl (like Alan)@piefed.zipEnglish
        1·
        9 days ago

        I agree that ergonomics are also important, but for me not the top priority for me. For Podman, I like the way I can use Quadlet to quickly deploy and run containerized stuff.

        However I really like it for building and running my own app stack pods. The combination of Quadlet and SystemD instance aliases is very powerful. I use this to drive all kinds of configuration automation.

          • CallMeAl (like Alan)@piefed.zipEnglish
            2·
            8 days ago

            The usage is simple. If you name a quadlet (or systemd service unit file) with an @ in it then you can use it. Like foo@.container then anything you put between the @ and . is passed into the resulting unit file as %i.

            So systemctl start foo@bar.service will pass ‘bar’ in where %i exists in the unit file. From there you can use it in a StartPreExec or whatever else to do instance specific stuff when the instance of the containerized service start.

            Like ExecStartPre=/usr/local/bin/activate_config %i for example. A contrived example but hopefully you get the idea: with one quadlet file and a little scripting you can start many instances of a service that each automatically pull in their own configs.