Installer Podman sur un serveur dédié

Podman est un moteur de conteneurs sans daemon. Pas de service en arrière-plan, pas de socket possédé par root, et chaque conteneur tourne comme processus enfant de votre shell. Le jeu de commandes podman correspond à celui de Docker, lit le même Dockerfile et tire depuis les mêmes container registries, si bien qu'un simple alias de shell couvre la majeure partie du travail quotidien. Ce guide couvre l'installation complète sur un serveur dédié : le paquet, un compte podman-user, le stockage, le réseau, et un service systemd qui redémarre chaque conteneur après un reboot. Matériel à partir de 9,99 €/mois.

Prérequis et systèmes d'exploitation supportés

Il tourne nativement sur Linux et est le moteur de conteneurs par défaut sur les distributions Red Hat.

• Fedora, CentOS Stream et RHEL. Le paquet est livré dans les dépôts de base, maintenu par la distribution.

• Ubuntu et Debian. Le paquet est dans l'archive principale : Ubuntu 24.04 embarque la 4.9, les versions plus récentes une 5.x.

• Alpine. Dans les dépôts communautaires, pour un build serveur minimal.

• cgroup v2 activé, ce que chaque version courante fait par défaut.

Vous avez aussi besoin d'un accès root ou sudo par SSH, et de l'adresse IP de votre fournisseur. L'installation elle-même prend une commande sur chacun de ceux-ci.

Sur Windows et macOS, Podman n'a pas de port natif. Windows en particulier n'a aucun runtime de conteneurs utilisable directement. La commande podman machine crée une machine virtuelle Linux et le client lui parle, si bien que le jeu de commandes sur votre PC correspond exactement au serveur. Podman Desktop ajoute une GUI pour ceux qui en préfèrent une. Sur un PC Windows la VM tourne sur WSL 2, pilotée depuis PowerShell. Ouvrez PowerShell comme utilisateur normal, sans droits administrateur :

podman machine init
podman machine start
podman version

Chaque VM est un système Linux complet, si bien qu'un PC Windows ou macOS est un environnement de dev plutôt qu'une machine de production. Podman Desktop sur Windows enveloppe les mêmes appels de commande podman dans une fenêtre, et podman machine stop éteint la VM quand vous en avez fini avec le PC. Faire tourner une app sur Windows de cette façon va pour le développement ; l'app que vous livrez tourne encore sur Linux. Podman Desktop tourne aussi sur macOS, et les commandes PowerShell utilisées sous Windows ont des équivalents exacts dans le Terminal là-bas. Rien dans ce chemin Windows ne change le comportement de l'app une fois arrivée sur le serveur. Tout ce qui suit suppose une machine Linux que vous joignez par SSH.

Préparer l'environnement de votre serveur dédié

Accordez la machine au nombre de conteneurs qu'elle fera tourner. Ce sont des configurations Kimsufi actuelles :

Un build serveur minimal suffit : le moteur n'a besoin ni de bureau ni de service supplémentaire. Une configuration serveur minimale fait partie de l'attrait, et plus facile à auditer. Mettez à jour le système de base, puis créez le compte qui possédera chaque conteneur. Créez-le une fois et chaque commande ultérieure tourne sous lui :

sudo dnf -y upgrade
sudo useradd -m -s /bin/bash podman-user
sudo loginctl enable-linger podman-user

Le lingering compte plus qu'il n'y paraît. Sans lui, systemd démonte la session utilisateur à la déconnexion et chaque conteneur s'arrête avec. Vérifiez que le compte fonctionne avec sudo -u podman-user id.

Installer Podman sur Fedora, CentOS et Ubuntu

Installer depuis les dépôts de base est la route supportée sur chaque distribution ci-dessous.

Fedora, CentOS Stream et RHEL. Une commande :

sudo dnf -y install podman containers-common

Sur CentOS, la même ligne sudo dnf -y install tire tout, parce que CentOS suit le packaging RHEL directement. Les anciennes versions de CentOS utilisaient yum, où la ligne yum équivalente se comporte identiquement. CentOS Stream et RHEL partagent les dépendances listées plus bas.

Ubuntu et Debian. L'installation apt est aussi courte :

sudo apt update
sudo apt install -y podman uidmap

Sur Alpine, l'équivalent apk fait la même chose sur un serveur minimal.

L'installation tire les dépendances listées ci-dessous, et il vaut la peine de les connaître parce que le dépannage plus loin s'y réfère :

• conmon surveille chaque processus de conteneur et relaie ses logs. Un conmon tourne par conteneur, si bien qu'une machine avec dix conteneurs en cours a dix processus conmon. Un binaire conmon manquant est l'installation cassée la plus courante.

• crun ou runc est le runtime OCI qui lance le processus du conteneur. crun est l'implémentation C la plus rapide ; runc est l'original en Go, encore le fallback sur les systèmes à base Debian, et l'un ou l'autre runtime fonctionne pareillement en ligne de commande. Vérifiez quel binaire runc ou crun est en usage avant de remplir un bug.

• containers-common fournit la liste par défaut des container registries et la politique de signature, si bien que chaque registre d'où vous tirez se résout là. Ajoutez votre propre registre à ce fichier registries quand vous hébergez un registre privé, et gardez les registres publics premiers dans l'ordre de recherche.

• slirp4netns et fuse-overlayfs fournissent réseau et stockage pour chaque conteneur quand il tourne sans root.

Vérifiez quel runtime l'installation a choisi avec podman info --format '{{.Host.OCIRuntime.Name}}'.

💡 Astuce Builder depuis la source en vaut rarement la peine, mais si vous avez besoin d'une fonctionnalité non publiée, sudo dnf builddep installe les dépendances de build et le dépôt git a le reste. Restez sur les releases packagées sur une machine de production.

Configurer Podman rootless pour une sécurité renforcée

Un conteneur démarré par un compte ordinaire mappe ses UIDs sur une plage non privilégiée. Confirmez que les plages existent :

grep podman-user /etc/subuid /etc/subgid
sudo usermod --add-subuids 100000-165535 --add-subgids 100000-165535 podman-user

Puis, comme ce compte, prenez la nouvelle config :

sudo -u podman-user podman system migrate
sudo -u podman-user podman info --format '{{.Host.Security.Rootless}}'

La dernière commande retourne true. Si elle retourne false, la plage subuid manque ou la commande migrate n'a jamais tourné. Ces deux commandes sont toute l'installation.

Vérifier l'installation et les commandes de base

podman run --rm quay.io/podman/hello

Cette commande confirme l'installation. L'image hello imprime un message et se retire elle-même. Cette seule commande prouve toute la chaîne : le registre est joignable, le stockage initialisé, et runc ou crun peut lancer un processus de conteneur.

podman pull docker.io/library/nginx:alpine
podman ps -a

✅ Résultat attendu La commande version imprime un numéro de release, et le conteneur hello tourne sans sudo ni erreur de permission. Exécutez podman ps -a pour confirmer qu'il est sorti proprement.

Gérer les conteneurs avec podman run, ps et prune

Démarrez un conteneur, publiez un port, et vérifiez :

podman run -d --name web -p 8080:80 docker.io/library/nginx:alpine
podman ps
curl -I http://localhost:8080

podman ps liste les conteneurs en cours et podman ps -a inclut les arrêtés, si bien que les deux ensemble montrent chaque conteneur de la machine. Cette sortie correspond exactement à Docker, et c'est pourquoi la plupart des scripts n'ont pas besoin de changement. Le vrai écart se situe en dessous, dans ce qui distingue Docker et Podman côté daemon et privilèges. Exécutez-la après chaque changement jusqu'à ce que la sortie vous soit familière, et ajoutez -a quand un conteneur est déjà sorti.

podman stop web
podman ps -a
podman rm web
podman prune -f
podman ps

La commande prune récupère les conteneurs arrêtés, les réseaux inutilisés et les images dangling. Sur une machine active, c'est ce qui garde le disque de se remplir, si bien qu'une section ultérieure programme un timer podman-prune. Utilisez --format "{{.Names}} {{.Status}}" pour une ligne de statut courte plutôt que la table complète.

💡 Astuce Un conteneur sans root ne peut pas binder un port sous 1024, donc publiez haut et mettez un reverse proxy devant. Abaissez net.ipv4.ip_unprivileged_port_start seulement si vous comprenez ce que vous ouvrez.

Configurer les drivers de stockage et les filesystems overlay

Sans privilèges root, le moteur ne peut pas utiliser le driver overlay du kernel directement, si bien qu'il retombe sur fuse-overlayfs, une implémentation en userspace qui a besoin du dev node /dev/fuse.

sudo dnf -y install fuse-overlayfs

La commande info rapporte le driver actif sous .Store.GraphDriverName.

La configuration du stockage vit dans ~/.config/containers/storage.conf, où le mount program est déclaré :

[storage]
driver = "overlay"
[storage.options.overlay]
mount_program = "/usr/bin/fuse-overlayfs"

Les kernels récents supportent l'overlay natif sans fuse, qui est plus rapide. Vérifiez la commande info après une mise à niveau : si l'entrée mount program a disparu, le kernel gère le montage lui-même. Un bind mount fonctionne dans les deux cas, et -v /srv/data:/app/data monte un répertoire dans le conteneur de l'app. Gardez chaque mount explicite plutôt que de monter un arbre dev entier.

Configuration réseau : ports, pare-feu et slirp4netns

Un conteneur qui tourne sans root obtient son réseau à travers slirp4netns, une stack userspace, ou pasta sur les versions plus récentes. Ni l'un ni l'autre n'a besoin de privilèges.

sudo dnf -y install slirp4netns
podman run -d -p 8080:80 --name web docker.io/library/nginx:latest

Publier un port l'ouvre sur la machine, si bien que le pare-feu s'applique toujours :

sudo firewall-cmd --add-port=8080/tcp --permanent
sudo firewall-cmd --reload

Sur les systèmes à base Debian, sudo ufw allow 8080/tcp fait pareil. Mettez un reverse proxy sur le 443 et gardez chaque port de conteneur fermé à Internet. Un proxy nginx est le choix habituel, et comme ce proxy tourne lui-même en conteneur, toute la pile applicative reste au même endroit. Pointez le proxy vers le conteneur de l'app par son nom et les deux se résolvent par le réseau interne.

Automatiser les services Podman avec systemd

Quadlet est la réponse actuelle. Vous écrivez un court fichier déclaratif et systemd génère le vrai service au boot. Créez web.container dans ~/.config/containers/systemd/ :

[Container]
Image=docker.io/library/nginx:alpine
ContainerName=web
PublishPort=8080:80
AutoUpdate=registry
[Service]
Restart=always
[Install]
WantedBy=default.target

Puis rechargez le user manager et activez le service de l'app. Le drapeau --user sur chaque commande systemctl est ce qui garde cela non privilégié :

systemctl --user daemon-reload
systemctl --user enable --now web
systemctl --user status web
systemctl --user restart web
systemctl --user list-units --type=service

Pour le ménage, un timer podman-prune garde le disque sous contrôle. Créez podman-prune.service appelant podman system prune -af, puis créez podman-prune.timer sur un horaire hebdomadaire et activez-le :

systemctl --user enable --now podman-prune.timer
systemctl --user list-timers
systemctl --user status podman-prune.timer
systemctl --user cat podman-prune.service

Cette paire de timer est l'automatisation la plus utile sur une machine à conteneurs, parce que les layers inutilisés s'accumulent en silence. Vérifiez son statut après une semaine pour confirmer que le job a tiré.

⚠️ Attention La vieille commande generate-systemd existe toujours mais est dépréciée. Elle écrit une unité statique codant en dur un container ID, ce qui casse la première fois que vous recréez ce conteneur.

Intégrer Podman avec Ansible pour des déploiements reproductibles

Une fois plus d'une machine qui fait tourner des conteneurs, pilotez-la depuis Ansible plutôt qu'à la main. La collection containers.podman couvre les images, chaque conteneur, les pods et la génération systemd :

ansible-galaxy collection install containers.podman

Un jeu de tasks minimal installe le paquet, puis démarre le conteneur de l'app :

- name: Install Podman
  ansible.builtin.package:
    name: podman
    state: present
- name: Run the web container
  containers.podman.podman_container:
    name: web
    image: docker.io/library/nginx:latest
    state: started
    ports: "8080:80"

Exécutez-le contre une nouvelle machine et vous obtenez le même résultat chaque fois, sur CentOS comme sur Debian, parce que le module résout le bon gestionnaire. Ansible rend les installations reproductibles, mais ne déplace pas les conteneurs d'un nœud tombé en panne. Ce rôle revient à un orchestrateur, et notre comparatif Kubernetes et Docker montre quand vous en avez besoin.

Durcissement de sécurité : AppArmor, seccomp et user namespaces

Les user namespaces font le gros du travail. Un processus qui se croit root dans le conteneur se mappe à un UID non privilégié sur l'hôte. Ce mapping est pourquoi l'installation ci-dessus vaut l'effort.

seccomp filtre les syscalls qu'un conteneur peut faire. Un profil seccomp par défaut s'applique à chaque conteneur, donc gardez-le et écrivez un profil seccomp personnalisé plutôt que de le désactiver :

--security-opt seccomp=/path/to/profile.json

Un conteneur qui échoue après un changement de seccomp est presque toujours bloqué sur un seul syscall, visible dans le journal.

AppArmor sur les systèmes à base Debian, SELinux sur CentOS et RHEL, confinent ce que chaque conteneur peut toucher sur le filesystem. Les deux sont activés par défaut et les deux valent d'être laissés tranquilles. Les profils AppArmor vivent dans /etc/apparmor.d/, et un conteneur bloqué par AppArmor y journalise le refus.

Retirez des capabilities. Ajoutez --cap-drop=ALL à la commande run et remettez seulement ce dont l'app a besoin. La plupart des conteneurs web n'en ont besoin d'aucune.

Fermez chaque port que vous ne servez pas, et gardez les règles de pare-feu aussi serrées que la config de conteneur.

Scénarios de dépannage courants

Conclusion

Vous avez maintenant le moteur installé depuis les dépôts de votre distribution, tournant comme podman-user sans root, avec le stockage et le réseau configurés, chaque conteneur géré par systemd, et le timer podman-prune qui garde le disque en respect. Les parties dures de l'installation sont les plages subuid et les emplacements des fichiers Quadlet, et toutes deux sont un travail à faire une fois. À partir de là c'est de la gestion de conteneurs ordinaire : tirer une image, exécuter une commande, créer une unité.

Déployez vos conteneurs sur du bare metal Serveurs dédiés Kimsufi à partir de 9,99 €/mois. Accès root complet et protection DDoS intégrée.

FAQ