2.3 KiB
+++ title = "Notes on Rootless Podman, Quadlet, and Systemd" date = 2023-12-11 draft = true [taxonomies] tags= ["guides"] +++
The following are notes I collected while working with a rootless Podman pod at work. Information has been redacted for security while still being helpful. This information will focus primarily on rootless podman because that seems to be a gap in online knowledge/documentation.
Podman-Kubes in Systemd
Podman comes with a system-level podman-kube@.service template file. (For those unfamiliar with it: a template file allows you to specify a parameter after the "@" to use with the service.) The syntax to use it is pretty simple:
# Allow *users* to have services that start on boot and exist after the user logs out.
# This example is for a user called "appuser".
loginctl enable-linger appuser
# Have the pod launch on startup, run as the user
systemctl --user enable podman-kube@$(systemd-escape /opt/app/app_kubernetes_file.yaml).service
It's worth noting that this does not work well with relative paths to Dockerfiles/Containerfiles. It will probably be sufficient if you are pulling pre-made images from Dockerhub or Quay.
Podman Systemd Service Generator: Quadlet
For context: Systemd can use executables called "generators" to convert non-native configurations into Systemd unit files. These generators are located in /usr/lib/systemd/system-generators, but Quadlet's is actually a symlink on RHEL.
Quadlet is specifically a generator for Podman services such as individual containers, Kubes/pods, networks, or volumes. You can put the configurations in ~/.config/containers/systemd/ for user-level items. The resulting unit files are not output to any filesystem directory (as far as I can tell), but do show up in systemctl --user list-units.
If you're debugging the config files generated by Quadlet, you can use /usr/libexec/podman/quadlet -user -dryrun (thank you to Fale's blog post for that one).
Using Generated Files
Genereated files are a little different than normal .service files that most of us are probably used to. For one, they don't get "enabled" the traditional way. Instead they are started the usual way and have a line within them to specify where they are "installed".