RHEL 10 : Red Hat conteneurise la gestion des déploiements de son OS
Red Hat espère uniformiser la gestion des mises à jour, des déploiements de RHEL et des applications qui l’utilisent en reprenant le modèle qu’il a mis en place pour OpenShift. Pour l’instant, les paquets RPM côtoieront les images de conteneurs bootc.
Outre le fait d’avoir détaillé le rapprochement d’Ansible et de Hashicorp Terraform, lors de sa conférence annuelle il y a un mois, Red Hat a dévoilé la disponibilité générale de RHEL 10 (Red Hat Enterprise Linux 10).
En ce sens, Red Hat fait évoluer la manière de mettre à jour l’OS, de gérer ses versions et son déploiement. C’est la « principale nouveauté » de RHEL 10, selon David Szegedi, chief architect au sein de la direction technique de Red Hat.
« Depuis plusieurs décennies, nous nous appuyons sur la gestion par paquets RPM pour les mises à jour et le développement logiciel », rappelle-t-il lors d’un point presse cette semaine. « Cependant, certains clients atteignent les limites de ce système, notamment en ce qui concerne la gestion du cycle de vie », poursuit-il. « Ils rencontrent des problèmes d’obsolescence, des complications liées à la gestion des paquets et des dépôts en raison du nombre élevé de machines ou du manque de personnel, ou encore des difficultés dues à la rotation rapide des machines dont la durée de vie est trop courte pour ce système par paquet ».
« Image Mode » : RHEL entre en mode « GitOps »
« Nous utilisons les outils de conteneurisation, dont Podman, pour construire une image de l’OS. »
David SzegediChief Achitect, direction technique, Red Hat
Pour pallier ce défaut, Red Hat mise sur le mode image. « Nous décrivons toute l’architecture de l’OS avec un Dockerfile. Nous utilisons les outils de conteneurisation, dont Podman, pour construire une image de l’OS », décrit David Szegedi. « L’idée n’est pas de l’exécuter comme un conteneur, parce que c’est un conteneur bootable avec un Kernel. En revanche, l’on peut intégrer les images d’OS dans la gestion logicielle d’une entreprise ».
Mise à jour de l’OS, signature de l’image, génération d’un SBOM sont alors intégrées dans l’usine logicielle, en mode « GitOps ».
Plus spécifiquement, il s’agit de partir d’une image bootc incluant le kernel, le bootloader « et d’autres briques exclues des conteneurs applicatifs ». Il convient d’ajouter les logiciels et les dépendances à cette image avant de la pousser vers le registre de conteneurs de type OCI. L’image est ensuite testée à travers les pipelines CI/CD de l’entreprise. L’image peut être poussée vers un environnement Kubernetes, convertie en image disque pour s’exécuter sur une VM KVM ou sur un serveur bare-metal.
L’Image mode est disponible pour RHEL 9.6 et 10. Red Hat avait introduit les fondamentaux de cette fonctionnalité dès la présentation de RHEL 9.
Pour ce faire, Red Hat a revu RHEL Image Builder en améliorant son outil bootc-image-builder afin de prendre en charge davantage d’options de partitionnement. Image builder prend en charge les images pour le cloud public, les instances bare-metal, les VM et WSL (Windows Subsystem for Linux).
À côté de ça, Red Hat maintient des images « optimisées » pour AWS, GCP et Azure.
ABB et Salesforce utiliseraient déjà le mode image. « Le mode image permet de consolider nos pipelines et nos processus de build, qui sont de plus en plus orientés vers la conteneurisation », affirme Anish Bhatt, architecte logiciel chez Salesforce, dans un communiqué de presse. « Il a également apporté de la stabilité à nos environnements, en réduisant les dérives de configuration et en permettant une expérience de déploiement plus cohérente ».
Aussi la fonctionnalité faciliterait les rollbacks au moment de passer à une version mineure de RHEL qui ne serait pas compatible avec la stack Salesforce.
Selon David Szegedi, le mode image a été réclamé par les grands clients et les industriels qui gèrent des déploiements sur des équipements Edge, IoT et embarqués.
Pour autant, il n’a pas vocation à remplacer les paquets RPM, en tout cas pas dans l’immédiat. « Ce n’est pas une obligation. Et l’on peut “combiner” les deux, RPM et Image mode. Nous voulons laisser le choix aux clients », assure David Szegedi.
Et d’ajouter : « l’idée, c’est de se rapprocher de la manière dont nous gérons OpenShift. RHEL CoreOS (RHCOS), le système d’exploitation d’OpenShift est déjà géré de cette manière ».
Faire cohabiter RPM et images
Le chief architect n’écarte pas l’arrêt du mode RPM. « Peut-être que dans cinq ou dix ans, ce sera suffisamment efficace pour que nous n’ayons plus besoin du RPM ».
Ces deux modes pourraient cohabiter sur le long terme. La préférence de Red Hat semble claire. « Les mécanismes de gestion, de registres, de scans de conteneurs sont à des années-lumière de ce qui existe en matière de templates OS, l’on ne va pas se mentir », déclare David Szegedi.
« La plupart du temps, ces clients qui conservent d’anciennes versions de RHEL y exécutent des applications certifiées pour une certaine version de l’OS. »
Rémy MandonDirecteur général, Red Hat France
En parallèle, l’éditeur a présenté Red Hat Insights Planning for RHEL, un tableau de bord qui permet d’identifier l’évolution de certaines fonctionnalités et de prévoir les montées de version – et les dépréciations – qui peuvent affecter les systèmes des entreprises à partir de RHEL 8.
« La majorité des clients sont passés sur RHEL 8, la version 9 étant sortie un peu rapidement. Certains clients ont encore du RHEL 7, et il y a encore quelques “mauvais élèves” qui ont conservé des versions plus anciennes », relate David Szegedi.
« La plupart du temps, ces clients qui conservent d’anciennes versions de RHEL y exécutent des applications certifiées pour une certaine version de l’OS », nuance Rémy Mandon, directeur général de Red Hat France.
« Nous offrons jusqu’à 13 ans de support pour RHEL 8, 9 et 10 », rappelle-t-il de son côté. Plus précisément, l’éditeur fournit cinq ans de support complet, cinq ans de maintenance supplémentaires, et trois ans au-delà pour les entreprises qui paient le LTS étendu.
Red Hat passe RHEL 10 au régime du chiffrement post-quantique
L’autre ajout mis en avant par Red Hat concernant RHEL 10 n’est autre que la prise en charge en préversion des algorithmes de chiffrement post-quantique.
« C’est un peu marketing, mais cela dénote une tendance de fond », estime le chief architect.
« C’est un peu marketing, mais cela dénote une tendance de fond. »
David SzegediChief Achitect, direction technique, Red Hat
Les politiques de chiffrement, OpenSSL, GnuTLS, OpenSSH, la suite d’outils NSS sont désormais compatibles avec ces algorithmes du standard FIPS 203 et 204 du NIST. Plus particulièrement, l’éditeur supporte les mécanismes d’encapsulation et de désencapsulation de clés ML-KEM (Module Lattice-Based Key Encapsulation Mechanism), et RSASVE (RSA Secret Value Encapsulation). Red Hat prend partiellement en charge les algorithmes ML-KEM 512, 768 et 1024 bits.
Pour la signature de certificats numérique, les algorithmes ML-DSA 44, 65 et 87 bits qui sont principalement utilisés. L’éditeur tient une liste des algorithmes qu’il prend (ou pas) en charge.
« C’est une demande des clients. Toutefois, avec OpenSSL, les applications connectées à un point de terminaison TLS ne se comportent pas toujours bien, mais des clients l’ont testé en production », assure David Szegedi.
De fait, si la spécification algorithmique a été posée sur la table par le NIST, la standardisation de l’implémentation provoque encore des débats chez les éditeurs et fournisseurs cloud. Pour rappel, des acteurs comme Oracle, pour Java, Google Cloud, Eviden ou encore Microsoft avancent chacun de leur côté sur la prise en charge de ces protocoles.
D’abord pour les agences fédérales américaines, RHEL 10 prend en charge le chiffrement des DNS. Aussi en préversion technique, il est possible de stocker toutes les clés de chiffrement sur un serveur HSM (Hardware Security Module).
Outre des ajouts incrémentaux pour la gestion de la sécurité, des accès et des rôles, Red Hat a présenté une extension payante (RHEL Security Select Add-on) pour prioriser le traitement des vulnérabilités marquées d’une CVE.
Pour les développeurs, Red Hat fourni les versions 8.3 de PHP, 1.26 de NGINX, 3.9 de Maven, 8.4 de MySQL, tandis que la prise en charge de Redis et Valkey (7.2) a été étendue. Ruby 3.3, Node.js 22, Python 3.12, Perl 5.40, Git 2.45, ou encore PostgreSQL 16, peuvent être déployés depuis la console RHEL ou la GUI.
Enfin, il est difficile d’y échapper actuellement, Red Hat décline une version de son assistant IA LightSpeed pour guider la configuration de RHEL 10, notamment en le connectant à Red Hat Insights et à Image Builder.
RHEL 10 est disponible sur les architectures x 86-64, ARM, IBM Power, IBM Z et, en préversion sur RISC V.
