Qu'est-ce que Cirrus CLI ? La description suivante est tirée de la description de la page Cirrus CLI GitHub :
Cirrus CLI est un outil permettant d'exécuter des tâches conteneurisées de manière reproductible dans n'importe quel environnement. Le plus souvent, les tâches Cirrus sont utilisées dans le cadre de workflows d'intégration continue, mais peuvent également être utilisées dans le cadre d'un processus de développement local en remplacement hermétique des scripts d'assistance/Makefiles. Cirrus CLI exécute vos tâches localement de la même manière qu'elles sont exécutées dans CI ou sur la machine de votre collègue. L'immuabilité des conteneurs garantit que les tâches seront exécutées de la même manière dans des années, quelles que soient les versions de packages que vous aurez localement.
Cirrus CLI a pris en charge Docker depuis sa création, mais exiger un démon de conteneur qui s'exécute en tant que root et fournit un accès aux utilisateurs moins privilégiés n'est parfois pas une option :par exemple, lors de la construction sur une machine partagée, en isolant des conteneurs imbriqués ou simplement en tant que sécurité -conscient de ce qui s'exécute sur votre bureau.
Et même si Docker a introduit le mode sans racine il y a environ un an, son expérience utilisateur fait actuellement défaut à notre avis, principalement en raison d'un emballage manquant et d'une histoire de Docker en tant que démon. Podman, d'autre part, a commencé comme un moteur de conteneur sans démon, et son processus d'installation couvre pratiquement toutes les distributions.
De plus, en étudiant Podman comme option supplémentaire pour exécuter des tâches Cirrus, nous avons réalisé que c'était un petit pas vers la rupture de la monoculture logicielle car, au final, sa qualité logicielle augmente. De nouvelles normes et blocs de construction comme le projet Rootless Containers émergent qui ouvrent la voie à l'avenir du logiciel.
Les conteneurs sans racine sont alimentés par... des espaces de noms ?
Les espaces de noms Linux sont la pierre angulaire la plus importante de ce qui fait fonctionner les conteneurs sous Linux. Ils sont très spécifiques à Linux, au point qu'une machine virtuelle Linux distincte est lancée lorsque vous exécutez des conteneurs sur Windows et macOS.
Les espaces de noms permettent une séparation granulaire des ressources. Par exemple, si un processus est attaché à un espace de noms PID spécifique, il ne voit que les autres processus attachés au même espace de noms. Ou si un système de fichiers FUSE est monté à la racine (/ ) tout en étant dans un espace de noms de montage séparé, l'hôte ne plantera pas soudainement en raison de fichiers binaires manquants.
L'un des espaces de noms les plus délicats est celui des utilisateurs. Les espaces de noms d'utilisateurs permettent essentiellement d'être une racine à l'intérieur de cet espace de noms, mais apparaissent comme un utilisateur normal de l'extérieur. Étant donné que la plupart des images de conteneurs s'attendent à s'exécuter en tant que racine pour certaines opérations, la mise en œuvre d'espaces de noms d'utilisateurs est cruciale pour les conteneurs sans racine.
Voyons ce qui se passe lorsque plusieurs utilisateurs lancent leurs commandes de construction en utilisant Docker sans espaces de noms d'utilisateurs activés :
Lors de l'observation des ID de ces processus à partir de l'hôte du conteneur, tous les travaux s'exécutent sous root, même s'ils sont démarrés par différents utilisateurs. Il en va de même pour containerd . Et même si vous auriez pu lui passer le --userns-remap flag, le conteneur fonctionnera toujours en tant que root et sera un point de défaillance unique.
Les choses fonctionnent comme ça en mode par défaut car la mise en œuvre de conteneurs sans racine n'est pas triviale.
Les espaces de noms d'utilisateurs eux-mêmes sont probablement l'une des configurations les plus complexes à implémenter et produisent de nombreux bogues liés à la sécurité. Certaines distributions comme Debian ont même choisi de les désactiver par défaut il y a quelque temps.
[ Au cas où vous l'auriez manqué : Principes de sécurité de base pour les conteneurs et les environnements d'exécution de conteneur ]
Comment Podman résout les difficultés d'exécution sans racine
Démarrer un conteneur sans privilèges root implique des compromis et des solutions de contournement.
Par exemple, en tant qu'utilisateur, lorsque vous créez un espace de noms de réseau (qui devrait être accompagné d'un espace de noms d'utilisateur), vous n'obtenez qu'un lo interface. Normalement, un moteur de conteneur crée également un veth paire d'appareils et déplace l'une de ses extrémités vers l'hôte pour le connecter à une véritable interface réseau ou à un pont (pour la communication inter-conteneurs).
Cependant, la connexion d'interfaces sur l'hôte nécessite que vous soyez une racine dans l'espace de noms de l'hôte, ce n'est donc pas possible. Podman contourne ce problème en utilisant slirp4netns, une pile réseau qui achemine les paquets entre le conteneur et le moniteur lui-même, au lieu d'utiliser les fonctionnalités du noyau. Ainsi, il ne nécessite aucun privilège de superutilisateur.
En raison de la complexité des espaces de noms d'utilisateurs, vous ne pouvez pas non plus utiliser certains systèmes de fichiers normalement disponibles pour la racine de l'hôte. L'un de ces systèmes de fichiers est OverlayFS, qui aide grandement à dédupliquer les couches d'image de conteneur et améliore l'expérience du conteneur. Cependant, on peut toujours utiliser FUSE. L'équipe Podman a implémenté fuse-overlayfs , qui est utilisé s'il est installé, se contentant d'extraire simplement le contenu de l'image dans un répertoire au détriment des performances.
Maintenant, si nous exécutons les mêmes tâches que nous avons exécutées auparavant, mais avec Podman, le résultat ressemble à ceci :
Notez que rien ne s'exécute en tant que root maintenant et qu'il n'y a pas de point de défaillance unique si un moteur de conteneur tombe en panne pour une raison quelconque.
Intégration avec Podman
Lorsque vous démarrez un nouveau build avec cirrus run , il génère le processus Podman sous le capot et lui parle via l'API REST, qui a été introduite récemment en tant que successeur de l'ancienne API Varlink.
L'API elle-même ressemble étroitement à l'API Docker Engine, ce qui permet une abstraction propre pour les deux API dans la même base de code.
En fait, le même point de terminaison Podman offre une couche de compatibilité de l'API Docker Engine, mais il s'agit toujours d'un travail en cours au moment de la rédaction.
Activer Podman dans la CLI
Si vous n'avez pas encore installé Podman, suivez les instructions de votre distribution Linux, puis lisez le didacticiel sans racine.
La CLI prend en charge Podman version 0.17.0 et versions ultérieures. Vous pouvez l'activer en passant le --container-backend=podman drapeau :
cirrus run --container-backend=podman Lint Notez que si Docker n'est pas installé sur votre système, vous n'avez même pas besoin de spécifier quoi que ce soit, tout fonctionne automatiquement.
[ Vous débutez avec les conteneurs ? Découvrez ce cours gratuit. Déploiement d'applications conteneurisées :présentation technique. ]
Récapitulez
Les builds sans racine sont un composant important des déploiements de conteneurs. Cirrus CLI travaille avec Podman pour fournir cette fonctionnalité. Utilisez ces deux utilitaires pour mieux gérer et sécuriser vos environnements de conteneurs.