1. 36
  1.  

  2. 3

    This is pretty neat. I know I have one or two system services on my home network running as podman containers that are managed by systemd, and the unit files are certainly too complex. I’m going to have to read the documentation to see if quadlet is configurable enough to meet the needs of one weird container I run, though.

    1. 3

      My thoughts too. Interesting that they’re pursuing integrating this with podman. I would have thought it would make more sense to integrate with systemd, perhaps make .Container a first class unit type.

      1. 2

        What’s the setup/usecase here? Is it basically, I want to run this as a system service and have it be managed by systemd PID1, but upstream insists on distributing it as a Docker image and I don’t want to run the Docker daemon?

        1. 7

          Couple/three issues to separate.

          1. I don’t want to run the Docker daemon; I want to use podman, which is daemonless and is included in my distribution’s repositories.
          2. I want all of the system services on my server to be managed by systemd, not by a variety of things.
          3. I need to run this service as a container because:
            1. Upstream insists on distributing it as a Docker image OR
            2. the service needs substantially different (e.g.) network settings from the main system.
          1. 2

            Have you considered using systemd-nspawn directly? You can export docker images to a tarball and import them as systemd machines. That allows you to do everything at systemd level and skip podman/docker system entirely.

            1. 2

              Have you considered using systemd-nspawn directly? You can export docker images to a tarball and import them as systemd machines. That allows you to do everything at systemd level and skip podman/docker system entirely.

              I think you miss out on upgrades this way? But that also means you aren’t hosed by upgrades…

              1. 2

                It’s the same process just different implementation for upgrades. “podman pull, restart” vs “podman pull, create save, nspawn restart”. Unless you mean some other kind of upgrades?

                1. 3

                  You would need to write scripts that Dora’s all the things you mentioned there. Why not just use script prepared by someone else? By a coincidence that other script is called Podman.

              2. 1

                It would probably be a good idea, but not a priority for me.

            2. 2

              For me, this is all about user interface around a more powerful chroot. Do I want to run some random daemon (like transmission-daemon) without any security protection, or do I want to run it in a jail? Now, what’s the easiest way to cram this into a namespace? For me, it’s something docker-esque. A decent amount of control on versioning, with an easy way to pull from upstream. I then chose podman over docker for the systemd integration being super easy.

          2. 2

            I’m getting flashbacks to sendmail what with its configuration file for its configuration file. When will this madness end?

            1. 1

              I’ve never used podman but… why is the generated unit file so complicated? Accordingly to other sources it seems that there are easier ways to use podman with systemd, and this feels much more appealing to me.

              1. -1

                I don’t understand what this things does at all. Podman can already generate a systemd config so why use another tool to generate a systemd config.

                Wrappers wrapping other wrappers. Fuck this.

                1. 5

                  Dynamic generation is important. The source of truth is the container unit file, not some random commands that produced a unit file once. What do you do when there is a new best practice? For example, I like this formulation better than previous generated unit files:

                  ExecStopPost=-/usr/bin/podman rm -f -i –cidfile=%t/%N.cid

                  I get this for free with every upgrade, without hard coding old versions of podman’s result.

                  1. 2

                    Dynamic generation is important.

                    Important for what?

                    The source of truth is the container unit file

                    There is a single source of truth in any case.

                    not some random commands that produced a unit file once

                    It’s not some random command that happened to ran for some reason, it’s a very specific command that I chose to run and deploy.

                    What do you do when there is a new best practice?

                    Why would there be a new best practice? What’s wrong with the old one, and if there’s a new one, it means the old one wasn’t the best. I deploy things I understand not what some imaginary authority decides to call best this day of the week.

                    For example, I like this formulation better than previous generated unit files:

                    Then use that one instead! Also, if it’s about some thing that you like that does the exact same thing as some other thing all your problems are syntactic, not semantic, so any claims of “solving” anything are dubious. In fact, if it changes at every upgrade it means it can break at every upgrade.

                    I get this for free with every upgrade, without hard coding old versions of podman’s result.

                    You get this for free… and so what? Who cares? It’s an intermediary artefact of the code generation that doesn’t have any actual effect. In fact it can’t have any effect, else the code generation thing would not be forwards compatible.

                    You’re just introducing another component in an already too complex system just because you like a different syntax. And this component can’t even have any effect by design. I’ll pass.

                    1. 9

                      I’ll take a stab at this, but the tone here is rather aggressive for what is essentially someone showing off something cool they did – whether or not this is upstreamed into Podman, this affects nothing for people that don’t want to use it. For me, this is not only cool but incredibly useful, and would simplify the CoreOS Home Server integration I’ve been working on by quite a bit. In any case:

                      Dynamic generation is important.

                      Important for what?

                      As the blog itself alludes to, the integration between systemd and Podman is not static – the underlying mechanisms by which Podman operates evolve, which sometimes necessitates setting options on either the Podman invocations or the systemd units themselves. One example of this is how Type=notify services interact with conmon, and how this affects readiness signals for containers.

                      Targeting higher-level semantics allows the underlying integration to change (as it relates to non-default options) without any change to the user-facing unit files themselves. The idea of systemd generators isn’t even that controversial itself – your system probably already uses some of these, as installed into /usr/lib/systemd/system-generators.

                      The source of truth is the container unit file

                      There is a single source of truth in any case.

                      The difference between a systemd generator and podman generate systemd is, as mentioned before, the fact that the former evolves against user-defined semantics, whereas the latter is static and is generated based on Podman-defined semantics (there’s not much optionality in the Podman generator).

                      not some random commands that produced a unit file once

                      It’s not some random command that happened to ran for some reason, it’s a very specific command that I chose to run and deploy.

                      Indeed, and you’re still given a choice of providing your own additional options with PodmanArgs=. Again, the specific commands that pertain to the integration between Podman and systemd tend to change with both of these projects (especially in terms of new security capabilities), and are already quite convoluted.

                      The examples of generated systemd units are quite gnarly, and it’s implied that these patterns need to be re-created time and time again unless podman generate systemd is used (which again, offers little optionality in the way things are generated).

                      In fact, I’ll stop myself here, as all subsequent points are just variations on the above – the issue at play here (and what Quadlet is attempting to fix) is the integration between systemd and Podman, which evolves separately to the integration between Podman and the container. I’d probably go as far as saying that podman generate systemd was the wrong abstraction, as systemd unit files are meant to be human-readable and editable, and need to support a wide variety of options that cannot necessarily be derived from Podman container definitions. Quadlet seems like a much better approach to solving this issue.

                      1. 1

                        I agree with most of this. I think we all have an intuitive ‘correct’ layer of abstraction and yours can be very different from mine.