Docker ou Podman : le mode rootless protège mieux, mais ralentit le réseau

Docker et Podman réduisent les privilèges des conteneurs sur l’hôte lorsqu’ils fonctionnent en mode rootless. Ce choix peut ralentir le réseau, mais le coût dépend du chemin emprunté par le trafic : le pilote actif et la publication des ports comptent davantage que le seul nom du moteur. Il faut donc comparer des configurations équivalentes avant d’attribuer un écart de débit à Docker ou à Podman.

Sur un poste déjà organisé autour de Docker Compose, conserver Docker peut éviter une migration coûteuse, à condition que le daemon utilisé soit réellement rootless. Sur un serveur Linux partagé ou pour un service géré par systemd, Podman offre un fonctionnement sans daemon central permanent. En CI/CD, où les conteneurs peuvent être nombreux et brefs, le temps de démarrage et le stockage méritent autant d’attention que le réseau.

Ce que les privilèges changent vraiment

En mode rootless, les processus du moteur et des conteneurs s’exécutent sous un compte ordinaire sur l’hôte. Les identifiants privilégiés visibles à l’intérieur d’un conteneur sont mappés dans un espace de noms utilisateur : ils ne donnent pas, à eux seuls, les droits de root sur l’hôte. Cela limite les conséquences d’une compromission du moteur ou d’une sortie du conteneur, sans protéger les fichiers et les secrets auxquels le compte utilisateur a déjà accès.

Docker conserve son architecture client–daemon : il faut installer et sélectionner le daemon rootless, puis vérifier que le client lui parle bien. La sortie de docker info doit notamment indiquer rootless dans les options de sécurité du serveur ; un simple changement de contexte affiché par le client ne suffit pas si la connexion vise un autre daemon. Podman ne dépend pas d’un daemon central pour lancer un conteneur, mais ses services d’API éventuels donnent accès aux ressources du compte qui les exécute. Dans les deux cas, les droits du compte et l’accès au socket restent des décisions de sécurité concrètes.

Démarrage et débit : ce que mesurent les chiffres

Dans le comparatif de Luca Berton, une boucle de 100 lancements séquentiels d’Alpine donne environ 0,35 s par conteneur pour Podman rootful et 0,45 s en rootless, contre 0,30 s et 0,42 s pour Docker ; son tableau iperf3 affiche environ 40 Gbit/s sur un pont rootful, 15 Gbit/s avec pasta en rootless et 3 Gbit/s avec slirp4netns en rootless. Les temps affichés ne correspondent pas à un surcoût relatif identique pour les deux moteurs. Le tableau réseau compare des chemins de trafic, pas deux installations actuelles placées dans des conditions identiques.

Ces résultats donnent un ordre de grandeur, pas une vitesse à attendre sur un autre hôte. Le comparatif ne détaille pas assez le matériel, le sens du trafic et les paramètres des ports pour isoler l’effet de chaque composant. Un test iperf3 mesure un transfert soutenu ; une tâche de CI peut surtout payer la création du conteneur, tandis qu’un service durable amortit ce coût de démarrage. La taille des messages, le nombre de connexions et le trajet des clients peuvent aussi modifier le résultat réseau.

Identifier le chemin réseau réellement utilisé

Le guide de performance de Podman indique que pasta est son seul pilote réseau rootless depuis la version 6.0.0 et qu’il entraîne un coût de performance. Il donne la commande podman info -f '{{.Host.RootlessNetworkCmd}}' pour afficher le pilote rootless par défaut. Pour un conteneur en cours d’exécution, podman inspect -f '{{.HostConfig.NetworkMode}}' NOM révèle son mode réseau ; la valeur par défaut ne décrit pas, à elle seule, un conteneur lancé en mode host ou raccordé à un réseau nommé.

Avec Docker rootless, le chemin réseau et celui des ports publiés peuvent utiliser des pilotes différents dans RootlessKit. L’API de RootlessKit expose séparément networkDriver et portDriver dans la sortie de rootlessctl info, lorsque la commande est connectée au socket de l’instance active. Si nécessaire, rootlessctl --socket "$ROOTLESSKIT_STATE_DIR/api.sock" info --json interroge ce socket après avoir défini ROOTLESSKIT_STATE_DIR pour cette instance. La présence de pasta ou de slirp4netns parmi les programmes installés ne dit pas lequel traite effectivement le trafic.

Le débit d’un port publié doit être mesuré par ce port, depuis l’emplacement réel des clients. Un essai entre processus sur l’hôte, un essai entre conteneurs et une connexion entrante peuvent traverser des composants différents. De même, choisir le réseau de l’hôte pour éviter un pilote en espace utilisateur change l’isolation réseau du conteneur ; ce réglage ne représente plus le même compromis de sécurité.

Les limites fonctionnelles avant la migration

La documentation de Docker rootless exclut AppArmor, les réseaux overlay et l’exposition de ports SCTP ; elle limite aussi les pilotes de stockage disponibles et conditionne la gestion des cgroups à cgroup v2 avec systemd. Elle distingue le débit du réseau de celui des ports publiés dans son tableau des combinaisons RootlessKit. Une application qui exige l’une de ces fonctions, ou qui dépend de l’adresse IP d’origine des clients, impose donc une vérification fonctionnelle avant tout arbitrage sur la vitesse.

Le stockage constitue une autre mesure indépendante. Une écriture dans la couche modifiable du conteneur, une écriture dans un volume monté et la construction d’une image n’empruntent pas le même chemin. Le pilote de stockage et les mappages d’identifiants peuvent influer sur les performances et sur les droits d’accès aux répertoires montés. Un ralentissement observé sur des fichiers ne doit pas être attribué au pilote réseau ; il faut reproduire les montages et les opérations de l’application pour savoir ce qui change.

Quel choix selon l’environnement ?

• Poste de développement : Docker est le choix le plus simple si les scripts, les outils et les fichiers Compose de l’équipe en dépendent déjà. Podman mérite un essai lorsque l’exécution sous un compte ordinaire est prioritaire. Son interface de commande couvre de nombreux usages courants, mais podman compose délègue l’exécution à un fournisseur Compose externe : tester les volumes, les ports et les services du projet est plus révélateur qu’un simple alias docker=podman.
• Serveur partagé : privilégier des comptes séparés, avec leurs propres répertoires et secrets, quel que soit le moteur. Podman évite un daemon central permanent pour l’exécution ordinaire ; Docker rootless convient aussi si ses limites couvrent les besoins du service. Le débit à examiner est celui du trajet entrant prévu en production, notamment lorsque des ports sont publiés.
• CI/CD : comparer la durée complète d’une tâche à images, caches et montages équivalents. Une suite qui crée de nombreux conteneurs courts peut être sensible au démarrage ; une suite qui transfère beaucoup de données peut dépendre surtout du chemin réseau. Le temps de téléchargement des images et les écritures sur disque doivent rester visibles séparément pour éviter de désigner le mauvais responsable.
• Service systemd : les unités Quadlet de Podman permettent de générer un service systemd utilisateur à partir d’une définition de conteneur, avec un réseau configurable ; elles exigent cgroup v2. Cette intégration rend Podman particulièrement adapté à un service rootless durable. Le compte utilisateur, le démarrage après redémarrage de l’hôte et le mode réseau du conteneur lancé restent à vérifier dans l’environnement retenu.

À lire aussi :

• Podscribe mesure les campagnes YouTube, mais seulement par estimation
• Freelance : le portage protège mieux, mais ne vous trouve aucun client
• AnyCreator Stream centralise les revenus, mais démarre avec YouTube Live