RHEL 9 fournit les dernières technologies de conteneurs pour le développement et la production

Il y a trois ans, avec la sortie de Red Hat Enterprise Linux 8 (RHEL 8), nous avons mis à disposition de nos utilisateurs un nouvel ensemble d'outils de conteneurisation avec un nouveau concept : les flux d'applications. Ces nouveaux outils de conteneurisation ont permis aux utilisateurs de RHEL de rechercher, d'exécuter, de créer et de partager des conteneurs. Vous trouverez plus d'informations sur les raisons à l'origine du passage de RHEL de Docker à Podman (et sur le parcours que nous avons suivi), dans l'article « RHEL 8 enables containers with the tools of software craftsmanship ».

Dans notre article précédent, « What's new in Red Hat Enterprise Linux 8.5 Container Tools? », nous avons présenté de nombreuses fonctions et capacités fondamentales nécessaires pour passer à RHEL 9.

Avec la sortie de RHEL 9, nous continuons à fournir les mêmes outils de conteneurisation basés sur Pod Manager (Podman), Buildah, Skopeo, Udica, CRIU et d'autres utilitaires Linux. Nous avons conçu RHEL 9 toujours dans l'optique de fournir le meilleur outil possible et avons facilité la mise à niveau de RHEL 8 vers RHEL 9 pour les utilisateurs de conteneurs. Cet article se penche sur les dernières technologies au cœur de cette solution et sur les changements dans la façon dont elle met en paquet les outils de conteneurisation.

• Qu'est-ce qui a changé entre RHEL 8.6 et RHEL 9.0 ?

• Gestion centralisée des mappages d'identités

• Prise en charge du protocole NFS pour le stockage des conteneurs

• Pile réseau avancée pour Podman 4.0

• Certificat portable et conteneur de signature

• crun : l'environnement d'exécution de conteneurs par défaut dans RHEL 9.0

• cgroup 2 : le groupe de contrôle par défaut dans RHEL 9 et Podman

Qu'est-ce qui a changé entre RHEL 8.6 et RHEL 9.0 ?

Commençons par quelques informations générales sur RHEL. RHEL 8.6 et RHEL 9.0 sont ce que nous appelons des versions synchronisées. Elles ont été publiées à peu près au même moment et continueront de se synchroniser jusqu'à ce que RHEL 8 atteigne la version 8.10 et passe en phase de prise en charge de la maintenance, pendant que RHEL 9 continuera de proposer de nouvelles fonctionnalités. Ainsi, les utilisateurs profitent des mises à jour des fonctions sur les deux plateformes pendant deux ans et d'un délai raisonnable pour effectuer la mise à niveau. Le cycle de vie de RHEL est intentionnellement conçu pour faciliter la mise à niveau, ce qui est également vrai pour les outils de conteneur.

Vous noterez dans le graphique ci-dessous que les versions suivantes de RHEL 8 et 9 sont synchronisées :

• RHEL 9 Alpha -> RHEL 8.4

• RHEL 9 Beta -> RHEL 8.5

• RHEL 9.0 GA -> RHEL 8.6

• RHEL 9.1 -> RHEL 8.7

• RHEL 9.2 -> RHEL 8.8

• RHEL 9.3 -> RHEL 8.9

• RHEL 9.4 -> RHEL 8.10

Cette synchronisation entre RHEL 8 et 9 simplifie les mises à niveau et s'étend aux versions de Podman, Buildah et Skopeo. En effet, les versions rapides et stables de Podman, Buildah et Skopeo sont alignées entre les versions. Par exemple, vous noterez que la dernière version de Podman est la même entre RHEL 8 et 9 :

Sur RHEL 8

cat /etc/redhat-release  Red Hat Enterprise Linux release 8.6 (Ootpa) [root@lance ~]#  podman --versionpodman version 4.0.2

Sur RHEL 9

cat /etc/redhat-release  Red Hat Enterprise Linux release 9.0 (Plow) podman --version podman version 4.0.2

La synchronisation des logiciels importants tels que Podman entre les versions majeures de RHEL simplifie les mises à niveau, mais vous devez néanmoins prendre en compte certains changements. Dans RHEL 8.X, nous avons publié deux flux d'applications, l'un pour permettre aux développeurs d'accéder aux dernières versions de Podman, Buildah et Skopeo, et l'autre, plus stable, pour fournir aux équipes d'exploitation un cycle de vie d'assistance de deux ans.

Flux d'applications de RHEL 8

La méthode utilisée dans RHEL 8 nous a posé quelques problèmes. Tout d'abord, le flux stable n'a pas été utilisé aussi souvent que nous l'imaginions quand nous avons lancé RHEL 8. Nous avons lancé les flux rapides et stables dans RHEL 8, pensant que les utilisateurs voulaient accéder à une API de conteneur stable (Podman) tout en utilisant les éléments du système d'exploitation les plus récents et performants (noyau Linux, systemd, etc.). Cela avait toujours été le cas avec les systèmes d'exploitation basés sur des conteneurs.

Mais cette fois, cette hypothèse s'est révélée fausse. Au lieu de cela, les utilisateurs de RHEL cherchaient principalement à accéder au flux d'outils de conteneurisation stable associé à la prise en charge étendue des mises à jour (EUS) pendant deux ans pour RHEL dans son ensemble. Conclusion : les utilisateurs de RHEL préfèrent accéder à un système d'exploitation complet avec un cycle de vie plus long. Par conséquent, nous avons changé notre mode de publication des outils de conteneurisation dans RHEL 9.

RHEL 9 : flux d'applications et EUS

Dans RHEL 9, nous proposons également deux façons d'utiliser les outils de conteneurisation, l'une qui favorise la rapidité et l'autre qui privilégie la stabilité. Les développeurs et les utilisateurs qui souhaitent accéder aux versions les plus récentes et les plus performantes de Podman, Buildah et Skopeo peuvent utiliser un flux d'applications publié toutes les 12 semaines (comme RHEL 8). Par défaut, ce flux est synchronisé avec le flux rapide de RHEL 8 (jusqu'à la version 8.10, quand RHEL 8 ralentira le développement), ce qui facilite les mises à niveau entre les versions principales. 

Si les utilisateurs de RHEL 9 ont besoin d'accéder à un flux stable pris en charge pendant deux ans avec rétroportage de la sécurité, ils peuvent opter pour l'offre RHEL Extended Update Support (EUS), en achetant une souscription supplémentaire. Par défaut, chaque version des outils de conteneurisation dans les versions EUS de RHEL 9 est synchronisée avec un flux stable correspondant dans RHEL 8. Encore une fois, cela facilite la mise à niveau de RHEL 8 vers RHEL 9, et assure ainsi la cohérence au niveau de la version de Podman, en plus de réduire les risques de régressions.

Il est important de noter qu'à l'avenir RHEL 8 sera toujours distribué exactement tel qu'il a été conçu. La nouvelle méthode utilisée dans RHEL 9 ne s'appliquera pas. Si vos développeurs, administrateurs ou architectes ont prévu un déploiement de RHEL 8 basé sur des flux stables, vous pouvez continuer à les utiliser comme d'habitude et vous n'aurez pas besoin de l'offre EUS.

Notez également que dans RHEL 8.6, le module container-tools:2.0 est désormais obsolète. Vous devez donc passer à une version plus récente (3.0, 4.0, etc.) pour continuer à recevoir les correctifs de sécurité. Pour en savoir plus, consultez la page consacrée au cycle de vie des flux d'applications RHEL. 

Gestion centralisée des mappages d'identités

Rootless Podman est une technologie très intéressante. Elle renforce la sécurité des conteneurs en les exécutant en tant qu'utilisateur non root, de la même manière que les processus normaux s'exécutent sur un système. Pour une charge de travail malveillante, cela représente une couche de sécurité supplémentaire à traverser. Elle devrait d'abord passer par les contrôles de conteneur, puis trouver un moyen d'obtenir les privilèges root. Cette solution est idéale pour les grands parcs d'ordinateurs portables/de bureau, dans les environnements HPC et même pour les développeurs qui utilisent des serveurs partagés.

Cependant, la gestion d'un grand nombre d'utilisateurs non root sur un grand nombre de stations de travail RHEL, de nœuds HPC ou de serveurs partagés a toujours relevé du défi, car l'administrateur devait gérer les fichiers /etc/subuid et /etc/sugid manuellement sur chaque nœud.

Ce n'est plus le cas aujourd'hui. Avec RHEL 9, nous avons introduit une fonction dans Identity Management (IdM) qui permet aux administrateurs de gérer facilement les utilisateurs Podman rootless à grande échelle. Les utilisateurs peuvent attribuer des ID subuid/subgid à un seul utilisateur ou à tous les utilisateurs d'un serveur Directory Server. C'est vraiment pratique. Pour plus d’informations à ce sujet, reportez-vous au Chapitre 29. Gestion manuelle des plages de sous-ID.

Prise en charge du protocole NFS pour le stockage des conteneurs

Comme nous l'avons vu, Rootless Podman est une fonction intéressante, et les administrateurs doivent souvent gérer de nombreux utilisateurs sur de nombreux nœuds (postes de travail, HPC, serveurs de développement partagés, etc.). Dans ces scénarios, les utilisateurs souhaitent importer leurs propres données. Par exemple, s'ils effectuent une opération « podman pull » sur un nœud, ils veulent que cette image soit disponible sur n'importe quel nœud du cluster. Un moyen simple de le faire avec des processus normaux consiste à utiliser le protocole NFS, mais avec Podman et les containers, cette solution ne fonctionnait pas.

Aujourd'hui, avec cette nouvelle fonction, Podman peut stocker des données sur n'importe quel serveur NFS qui prend en charge les attributs étendus (xattrs). Les utilisateurs non root/rootless peuvent extraire une image une fois, puis l'utiliser partout où leur répertoire personnel est disponible. Cette option est extrêmement pratique avec les stations de travail, les nœuds HPC ou même les serveurs de développement partagés où est mise en œuvre la CI/CD. Pour en savoir plus à ce sujet, lisez cet article : New features for running containers on NFS with rootless Podman

Pile réseau avancée pour Podman 4.0

Dans RHEL 9 avec Podman 4.X, les utilisateurs dispose d'une nouvelle pile réseau. Elle intègre de nouvelles fonctions, notamment une meilleure prise en charge d'IPv6, ainsi que des conteneurs sur plusieurs réseaux et des performances améliorées.

L'article suivant en donne un excellent aperçu : Podman 4.0's new network stack: What you need to know.

Certificat portable et conteneur de signature

Avec la sortie de RHEL 8.4, nous avons introduit UBI Micro, l'une des images de conteneur les plus petites et les plus rapides du marché (Introduction to Red Hat UBI Micro).

Avec la sortie de RHEL 9, nous nous sommes appuyés sur cette technologie pour créer une petite image de conteneur OpenSSL (12,5 Mo) qui peut servir pour le chiffrement simple, par exemple la génération de demandes de certificat SSL, la vérification de certificats SSL ou même la signature de fichiers.

Les développeurs disposent ainsi d'un moyen standardisé d'exécuter des processus de chiffrement fiables, que ce soit en production ou sur leurs ordinateurs de bureau/portables. Comme avec toutes les images de base universelles de Red Hat, vous et vos développeurs pouvez utiliser et distribuer ce nouveau conteneur de certificat et de signature portable partout où vous en avez besoin.

Pour en savoir plus, consultez la liste dans le catalogue des écosystèmes Red Hat

• ubi9/openssl

• ubi8/openssl

crun : l'environnement d'exécution de conteneurs par défaut dans RHEL 9.0

En 2020, les contributeurs Red Hat ont introduit crun, un environnement d'exécution de conteneurs rapide, à faible mémoire et compatible OCI. Dans RHEL 9, crun est devenu l'environnement d'exécution de conteneurs par défaut. crun et runc seront pris en charge pendant tout le cycle de vie de RHEL 9.

L'utilisation de crun par défaut simplifie de nombreuses tâches de configuration de base pour les administrateurs, améliore les performances et l'utilisation de la mémoire et débloque toutes sortes de nouveaux cas d'utilisation intéressants. Pour plus d'informations, je vous renvoie à l'article : An introduction to crun, a fast and low-memory stack container runtime

cgroup 2 : le groupe de contrôle par défaut dans RHEL 9 et Podman

Le projet cgroup 2 se définit comme suit : « un composant du noyau Linux qui fournit un mécanisme pour isoler, mesurer et contrôler la distribution des ressources pour un ensemble de processus sur un serveur ». Il donne aux administrateurs et aux logiciels d'infrastructure, tels que les moteurs et les environnements d'exécution de conteneurs, un mécanisme puissant pour limiter les ressources utilisées par un processus donné, ce qui est particulièrement utile avec les conteneurs. 

cgroup 2 était déjà disponible dans RHEL 8, mais les utilisateurs devaient l'activer, puis redémarrer leur système pour l'utiliser. Dans RHEL 9, cgroup 2 est le mécanisme par défaut, prêt à l'emploi, qui permet un contrôle plus précis des conteneurs rootless (First Look: Rootless Containers and cgroup v2 on Fedora 31). Pour en apprendre plus sur cgroup 2, je vous conseille la présentation suivante : World domination with cgroups in RHEL 8: welcome cgroups v2!

Conclusion

RHEL 9.0 avec Podman 4.0.2 intègre beaucoup de nouvelles fonctions de conteneurisation, mais nombre d'entre elles sont également disponibles dans RHEL 8.6. Que vous souhaitiez passer à la dernière version ou tirer le meilleur parti de votre version actuelle, vous aurez tout ce qu'il vous faut grâce à la conception et à l'architecture du flux d'applications des outils de conteneurisation.

Avec RHEL 9, non seulement nous continuons à offrir un accès rapide aux versions les plus récentes et optimisées de Podman, Buildah et Skopeo, mais en plus, nous mettons à votre disposition un flux stable via EUS. Nous avons essayé de rendre RHEL 9 encore plus facile à utiliser pour nos clients, et nous espérons que cette version vous plaira. Votre avis nous intéresse.

N'hésitez pas à faire part de vos commentaires à notre nouveau responsable produit Container Tools, Mark Russell (https://www.linkedin.com/in/marrusl/), à notre responsable produit RHEL Server, Scott McCarty (@fatherlinux), à notre responsable marketing technique, Eric Hendricks (@itguyeric), ou envoyez vos tweets sur notre compte Red Hat Enterprise Linux officiel, (@rhel).