Ejecutar contenedores Podman como servicios systemd con Quadlet

Objetivo

Definir un contenedor gestionado por Podman como un servicio systemd nativo mediante un archivo de unidad Quadlet .container, en lugar del enfoque más antiguo de unidad generada.

Requisitos previos

Podman 4.4 o posterior (el primer release upstream con el generador Quadlet; comprobar podman --version, ya que releases empresariales más antiguos pueden carecer de él o tener menos claves); systemd en el host. Root para un servicio de todo el sistema, o una cuenta de usuario normal (más lingering, si debe ejecutarse sin una sesión de inicio de sesión) para uno sin privilegios (rootless).

Pasos

1. Entender primero el mecanismo: podman-systemd.unit(5) documenta Quadlet como un generador de systemd que convierte archivos .container declarativos (y .volume, .network, .pod, .kube, .image, .build) en unidades .service normales durante el arranque o al hacer daemon-reload, en lugar de exigir un archivo de unidad generado mantenido por separado.
2. No usar podman generate systemd para servicios nuevos: su propia página de manual marca el comando como en desuso y recomienda Quadlet.
3. Colocar una unidad de todo el sistema en /etc/containers/systemd/myapp.container, o una por usuario en ~/.config/containers/systemd/myapp.container (otras rutas de búsqueda aparecen en el manual). Un ejemplo mínimo:

[Unit]
Description=My application container

[Container]
Image=docker.io/library/nginx:stable
PublishPort=8080:80
AutoUpdate=registry

[Service]
Restart=on-failure

[Install]
WantedBy=multi-user.target

Para una unidad de usuario (rootless), usar WantedBy=default.target; el gestor de usuario no tiene multi-user.target. 4. Hacer que systemd regenere las unidades a partir del archivo nuevo: sudo systemctl daemon-reload (sistema) o systemctl --user daemon-reload (rootless). El manual de systemctl documenta daemon-reload como la recarga de los archivos de unidad y, para los generadores, su reejecución. 5. Iniciarlo: sudo systemctl start myapp.service (o systemctl --user start myapp.service). No ejecutar systemctl enable: las unidades generadas no se pueden habilitar. El inicio en el arranque proviene de la sección [Install], que el propio generador aplica en cada ejecución. El contenedor se llama systemd-myapp a menos que se establezca ContainerName=. 6. AutoUpdate=registry etiqueta el contenedor para podman auto-update, que descarga una imagen más nueva y reinicia la unidad. Solo se ejecuta cuando se invoca o cuando podman-auto-update.timer está habilitado (sudo systemctl enable --now podman-auto-update.timer, o --user); previsualizar con podman auto-update --dry-run. La imagen debe ser una referencia totalmente cualificada. Comprobar la etiqueta con podman inspect --format '{{ index .Config.Labels "io.containers.autoupdate" }}' systemd-myapp.

Resultado esperado

systemctl status myapp.service --no-pager muestra la unidad generada como activa; detenerla e iniciarla detiene/inicia el contenedor mediante el orden de dependencias, las políticas de reinicio y el registro normales de systemd (journalctl -u myapp.service). Para deshacerlo, detener el servicio, eliminar el archivo .container y volver a ejecutar daemon-reload.

Límites y base de verificación

La sintaxis de los archivos Quadlet y las claves disponibles son específicas del generador y están versionadas junto con el release de Podman; comprobar el man podman-systemd.unit local de la versión instalada antes de confiar en una clave no mostrada aquí. Un error de sintaxis o una clave no admitida hace que el generador omita el archivo, por lo que systemctl más tarde informa Unit myapp.service not found. Mostrar la salida generada y los errores con /usr/lib/systemd/system-generators/podman-system-generator --dryrun (añadir --user para unidades rootless).