Lorsque vous executez des conteneurs avec Podman en mode rootless, un defi important se pose : les conteneurs demarres dans une session utilisateur s’arretent lorsque la session se termine, meme s’ils ont la politique restart=always. Cela se produit parce que les conteneurs rootless sont lies a la session utilisateur par defaut et ne persistent pas apres les deconnexions ou les redemarrages.
SystemD et Quadlet repondent a cette limitation. Introduit dans Podman 4.4, Quadlet simplifie l’integration avec SystemD en remplacant la commande obsolete podman generate systemd. Avec Quadlet, nous pouvons garantir que les conteneurs rootless persistent apres les redemarrages et les deconnexions utilisateur, en tirant parti des capacites de gestion de services de SystemD.
Configurer un conteneur comme service SystemD rootless
Pour integrer un conteneur Podman avec SystemD via Quadlet, creez des fichiers .container dans le repertoire ~/.config/containers/systemd/. L’exemple suivant illustre la configuration d’un serveur web NGINX.
Etape 1 : Creer le fichier de configuration Quadlet
Creez webserver.container :
[Unit]
Description=Webserver
[Container]
Image=docker.io/library/nginx:alpine
PublishPort=8080:80
[Service]
Restart=always
[Install]
WantedBy=default.targetPourquoi WantedBy=default.target ?
Pour les services rootless, utiliser WantedBy=default.target est essentiel. Specifier uniquement multi-user.target empechera le service de demarrer automatiquement apres un reboot, car cette cible s’applique aux services systeme (rootful), pas aux services utilisateur.
Pour verifier l’activation correcte au demarrage :
systemctl --user is-enabled webserverUne sortie “enabled” confirme la bonne configuration.
Etape 2 : Recharger et demarrer le service
systemctl --user daemon-reload
systemctl --user enable --now webserverEtape 3 : Verifier la creation du service
Contrairement a systemctl --user daemon-reload, qui ne fournit aucun message d’erreur pour les fichiers invalides, vous pouvez verifier la bonne generation du service avec :
systemctl --user cat webserverSi cette commande ne retourne pas le contenu attendu, des erreurs de syntaxe ou des directives manquantes existent probablement dans le fichier .container.
Note : Meme
journalctl --userfournit souvent peu d’informations utiles, faisant desystemctl --user catl’un des outils de diagnostic les plus efficaces pour les problemes de services Quadlet.
Ajouter une base de donnees PostgreSQL avec stockage persistant
Un exemple plus complexe illustre le deploiement d’un conteneur PostgreSQL avec des volumes persistants.
Etape 1 : Definir le conteneur de base de donnees
Creez project-postgres.container :
[Unit]
Description=Postgres DB Project
[Container]
Image=docker.io/library/postgres:14-alpine
Environment=POSTGRES_USER=podman
Environment=POSTGRES_PASSWORD=mysecretpassword
Environment=POSTGRES_DB=training
PublishPort=5432:5432
Volume=project-postgres.volume:/var/lib/postgresql/data
[Install]
WantedBy=default.targetEtape 2 : Definir le volume persistant
Creez project-postgres.volume :
[Unit]
Description=Postgres Project Volume
[Volume]Etape 3 : Recharger et activer les services
systemctl --user daemon-reload
systemctl --user enable --now project-postgresVerifiez la bonne creation du service :
systemctl --user cat project-postgresRootless vs. Rootful
Les emplacements de configuration et les commandes different entre les services rootless et rootful :
Les services rootless sont places dans ~/.config/containers/systemd/ avec des commandes a portee utilisateur :
systemctl --user daemon-reload
systemctl --user enable --now webserverLes services rootful vont dans /etc/containers/systemd/ avec des commandes privilegiees :
sudo systemctl daemon-reload
sudo systemctl enable --now webserverEt ensuite ?
Un prochain article montrera comment deployer plusieurs conteneurs interconnectes, creer des pods et automatiser la generation de fichiers Quadlet en utilisant Podlet.
Pour plus d’informations, consultez la documentation officielle Podman SystemD Unit.