517
Every time I use podman (thelemmy.club)
submitted 3 weeks ago* (last edited 3 weeks ago) by to c/linuxmemes@lemmy.world
206 comments fedilink hide all child comments
 

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.

you are viewing a single comment's thread
view the rest of the comments
[–] 2 points 3 weeks ago (10 children)

Docker swarm uses compose files too. But really, when you have tools like Podlet that converts compose files to quadlets, it's a pretty good sign that the two fit 90% the same use cases.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 10 child comments
    •
  • [–] 1 point 3 weeks ago (9 children)

    I think its more than Compose does a small subset of what Quadlets can do. I can understand why if your only use case is Compose and you already like it, why change? For me, the rootless by default and daemonless nature of podman quadlets, and its clean design all make it the preferred choice.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 9 child comments
    •
  • [–] 1 point 3 weeks ago* (8 children)

    Podman-compose also works rootless and without a daemon. Naturally since it's daemonless, it does require a separate systemd service if you want services to automatically restart (I forget exactly what that systemd service is called).

    What do you mean by "clean design"? This is of course subjective but I just want to understand quadlets more.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 8 child comments
    •
  • [–] 1 point 3 weeks ago (7 children)

    What do you mean by “clean design”?

    If you are comfortable reading the source code for each project that is the most revealing way to see the difference.

    In short, Docker has a lot more code because it duplicates a lot of kernel and systemd functionality (often poorly), uses multiple components that communication over grpc with each other to do things, requires setuid binaries, and defaults to running everything as root.

    Podman, is a straight forward clean simple program that fully uses kernel and systemd interfaces rather than duplicating functionality. Quadlet is build on systemd generators and its use of templates via systemd instances lets you use deterministic dynamic configuration in ways that is unlike anything in Docker.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 7 child comments
    •
  • [–] 1 point 3 weeks ago (6 children)

    If you are comfortable reading the source code for each project that is the most revealing way to see the difference.

    Strongly disagree on this. Design can mean many different things. For example in the docker vs podman explanation you gave, you are talking about integration with Linux and adherence to Linux standards, and I agree that with you on that. That's one of the reasons I do prefer Podman over Docker.

    However when I think about "clean" in regards to podman-compose vs Quadlet, I think about the user/developer experience. Quadlets integrate with systemd, but as a consequence inherit the design and interfaces of systemd. This means putting Quadlet files into a global systemd folder. This makes GitOps harder since all your projects get combined into a single folder. Also I'm not a fan of how verbose systemd config format is, like the repetition of keys. Seeing PublishPort= repeated for every port mapping looks ugly imo. And every service needs to be defined in a separate file, even if some services are only a few lines of config. Which makes it harder to see all services at a glance.

    I recognize this is all my subjective preferences, but this is just what I think when I hear "design".

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 1 point 3 weeks ago (5 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 1 point 3 weeks ago (4 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 1 point 3 weeks ago (3 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 1 point 3 weeks ago (2 children)

    all kinds of configuration automation.

    Any cool examples? I'm still dipping my toes into systemd

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 3 weeks ago (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •