Podman peut utiliser le système de fichiers de superposition natif avec les versions 5.13 du noyau Linux. Jusqu'à présent, nous utilisions des superpositions de fusibles. Le noyau a obtenu un support sans racine dans le noyau 5.11, mais un bogue a empêché l'utilisation de SELinux avec le système de fichiers; ce bogue a été corrigé en 5.13.
Il semble que Fedora rétroporte le correctif dans ses noyaux 5.12, de sorte que les utilisateurs devraient pouvoir l'utiliser une fois qu'ils auront accès au noyau.
Pourquoi devriez-vous vous en soucier ?
Jusqu'à la version 5.11, le noyau permettait aux utilisateurs de monter un nombre limité de types de systèmes de fichiers dans un espace de noms d'utilisateur. Ils comprenaient tmpfs, bind mounts, procfs, sysfs et fuse. Podman a utilisé le système de fichiers fuse-overlayfs monté à l'aide de ce support de montage de fusible dans l'espace de noms de l'utilisateur pendant de nombreuses années.
La superposition de fusibles a été excellente. Cependant, il s'agit d'un système de fichiers en espace utilisateur, ce qui signifie qu'il doit effectuer presque deux fois plus de travail que le noyau. Chaque lecture/écriture doit être interprétée par le fuse-overlay avant d'être transmise au noyau hôte. Pour les charges de travail lourdes qui martèlent le système de fichiers, les performances de la superposition de fusibles en souffrent. Vous pouviez voir les superpositions de fusibles arrimer le CPU. En bout de ligne, nous devrions voir de meilleures performances avec les superpositions natives, en particulier pour les conteneurs lourds en lecture/écriture en mode sans racine. Par exemple, podman build . les performances devraient nettement s'améliorer. Notez que lors de l'écriture sur des volumes, le fuse-overlayfs est rarement utilisé, les performances ne seront donc pas affectées.
Un autre inconvénient de fuse-overlayfs est qu'il nécessite un accès à /dev/fuse . Lorsque des personnes essaient d'exécuter Podman et Buildah dans un conteneur confiné, nous supprimons les privilèges CAP_SYS_ADMIN, même lors de l'exécution en tant que root. Cela nous oblige à utiliser un espace de noms d'utilisateurs afin de pouvoir monter des volumes. Pour que cela fonctionne, les utilisateurs doivent ajouter /dev/fuse au conteneur. Une fois que nous avons une superposition native pour le mode sans racine (pas de CAP_SYS_ADMIN ), /dev/fuse ne sera plus nécessaire.
Comment puis-je l'utiliser ?
Malheureusement, vous ne pourrez utiliser la superposition native qu'avec un nouveau stockage, ce qui signifie que vous devrez détruire tout le stockage existant de votre conteneur. Il est nécessaire de faire une podman system reset si vous avez déjà des images/conteneurs.
La raison en est que lorsqu'un programme de montage est utilisé, nous stockons un fichier d'indicateur dans le répertoire de stockage :$STORAGE/overlay/.has-mount-program . Si le fichier est présent, alors c/storage ignore la prise en charge native de la superposition. La raison d'une telle vérification est qu'il existe des différences dans la façon dont fuse-overlayfs stocke les métadonnées, y compris les fichiers de voile blanc sur les noyaux plus anciens qui ne permettaient pas de créer le périphérique de voile blanc spécial pour les utilisateurs non privilégiés, et cela ne fonctionnerait pas si la superposition native est activée. . Cela signifie que la simple suppression des fichiers entraînera des problèmes avec vos conteneurs existants.
La podman system reset La commande supprime également le fichier d'indicateur. Ensuite, la superposition native sera utilisée si elle est prise en charge par le noyau sous-jacent.
En ce qui concerne les autres distributions, ce support apparaîtra lorsque le noyau 5.13 sera publié. Pour le flux RHEL/CentOS, nous prévoyons de rétroporter la fonctionnalité pour la version RHEL8.5 à l'automne.
Allons-nous continuer à utiliser/supporter fuse-overlayfs ?
Nous prévoyons de continuer à utiliser et même d'améliorer les superpositions de fusibles. Nous utilisons cette plate-forme pour expérimenter de nouvelles fonctionnalités, puis en discuter avec l'équipe du noyau pour voir si nous pouvons les intégrer en natif.
Une fonctionnalité importante que nous avons ajoutée est la prise en charge du stockage des attributs de sécurité des fichiers dans les attributs de fichier étendus (xattrs). Nous en avons besoin pour prendre en charge les répertoires personnels NFS. Les serveurs NFS bloquent l'utilisation de conteneurs avec plusieurs UID dans l'espace de noms d'utilisateur. Cela arrête les utilisateurs de NFS homedirs d'utiliser Podman sans configurer de stockage supplémentaire. Avec fuse-overlayfs, nous pouvons avoir tout le contenu créé par Podman stocké dans le système de fichiers comme appartenant à l'utilisateur exécutant Podman. Dans le conteneur en cours d'exécution, le contenu est représenté sous la forme de différents UID/GID basés sur xattrs. Lorsqu'un processus s'exécutant dans ce mode crée un fichier avec un UID différent, fuse-overlay intercepte la création de l'UID, crée le fichier avec l'UID du monteur et stocke l'UID différent dans un xattr.
[ Vous débutez avec les conteneurs ? Découvrez ce cours gratuit. Déploiement d'applications conteneurisées :présentation technique. ]
Récapitulez
Les contenants Podman sans racine continuent d'évoluer et deviennent de plus en plus pratiques. Pour les charges de travail lourdes, la superposition native devrait offrir une expérience de performances bien meilleure qu'avec les superpositions de fusibles. Les noyaux sont également rétroportés pour fournir un meilleur support. Faites-nous savoir comment vous avez l'intention d'utiliser cette formidable nouvelle fonctionnalité.