Exécuter des conteneurs Podman comme services systemd avec Quadlet

Objectif

Définir un conteneur géré par Podman comme service systemd natif à l'aide d'un fichier d'unité Quadlet .container, au lieu de l'ancienne approche par unités générées.

Prérequis

Podman 4.4 ou ultérieur (première version upstream dotée du générateur Quadlet ; vérifiez avec podman --version, car les versions entreprise plus anciennes peuvent ne pas l'inclure ou proposer moins de clés) ; systemd sur l'hôte. Un accès root pour un service à l'échelle du système, ou un compte utilisateur ordinaire (avec le « lingering » si le service doit tourner sans session de connexion) pour un service rootless.

Étapes

1. Commencez par comprendre le mécanisme : podman-systemd.unit(5) décrit Quadlet comme un générateur systemd qui convertit des fichiers déclaratifs .container (ainsi que .volume, .network, .pod, .kube, .image, .build) en unités .service classiques au démarrage ou lors d'un daemon-reload, sans qu'il faille maintenir séparément un fichier d'unité généré.
2. N'utilisez pas podman generate systemd pour de nouveaux services : sa propre page de manuel déclare la commande obsolète et recommande Quadlet.
3. Placez une unité système dans /etc/containers/systemd/myapp.container, ou une unité par utilisateur dans ~/.config/containers/systemd/myapp.container (les autres chemins de recherche sont listés dans le manuel). Exemple minimal :

[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

Pour une unité rootless (utilisateur), utilisez WantedBy=default.target ; le gestionnaire utilisateur ne dispose pas de multi-user.target. 4. Faites régénérer les unités par systemd à partir du nouveau fichier : sudo systemctl daemon-reload (système) ou systemctl --user daemon-reload (rootless). Le manuel de systemctl indique que daemon-reload recharge les fichiers d'unité et, pour les générateurs, les réexécute. 5. Démarrez le service : sudo systemctl start myapp.service (ou systemctl --user start myapp.service). N'exécutez pas systemctl enable : les unités générées ne peuvent pas être activées. Le démarrage au boot découle de la section [Install], que le générateur applique lui-même à chaque exécution. Le conteneur se nomme systemd-myapp, sauf si ContainerName= est défini. 6. AutoUpdate=registry marque le conteneur avec un label pour podman auto-update, qui télécharge une image plus récente et redémarre l'unité. Cette commande ne s'exécute que lorsqu'on l'invoque ou lorsque podman-auto-update.timer est activé (sudo systemctl enable --now podman-auto-update.timer, ou avec --user) ; un aperçu est possible avec podman auto-update --dry-run. L'image doit être une référence pleinement qualifiée. Vérifiez le label avec podman inspect --format '{{ index .Config.Labels "io.containers.autoupdate" }}' systemd-myapp.

Résultat attendu

systemctl status myapp.service --no-pager montre l'unité générée comme active ; l'arrêter et la démarrer arrête et démarre le conteneur, en respectant l'ordre des dépendances systemd, les politiques de redémarrage et la journalisation habituels (journalctl -u myapp.service). Pour annuler, arrêtez le service, supprimez le fichier .container et relancez daemon-reload.

Limites et base de vérification

La syntaxe des fichiers Quadlet et les clés disponibles dépendent du générateur et suivent les versions de Podman ; consultez man podman-systemd.unit en local pour connaître les clés prises en charge par la version installée avant d'en utiliser une qui n'apparaît pas ici. Une erreur de syntaxe ou une clé non prise en charge fait ignorer le fichier par le générateur, de sorte que systemctl signale ensuite Unit myapp.service not found. Affichez la sortie générée et les erreurs avec /usr/lib/systemd/system-generators/podman-system-generator --dryrun (ajoutez --user pour les unités rootless).