Bien avant l’apparition de Linux, je travaillais comme administrateur système Unix. À l’époque, je téléchargeais le code source, je décompressais l’archive tarball, je le compilais et je l’installais chaque fois que j’avais besoin de mettre à jour mon système ou d’installer un nouveau paquet. C’était une véritable plaie.
Avec l’arrivée de Unix System V Release 4 (SVR4) en 1989, les choses se sont améliorées avec le premier système de gestion de paquets : pkgadd, pkgrm et pkginfo. Des sociétés comme IBM, avec sa distribution Unix AIX et son System Management Interface Tool (SMIT), et Sun, avec Solaris 2.0, ont publié leurs propres versions. Et ma vie d’administrateur système s’est considérablement simplifiée.
Pendant ce temps, Linus Torvalds, qui avait annoncé en 1991 qu’il travaillait sur un système d’exploitation (libre) (« juste un hobby », disait-il) pour les clones AT 386(486), était heureux de voir que les gens adoptaient progressivement Linux et le prenaient au sérieux.
Évolution des gestionnaires de paquets
Inspirés par les gestionnaires de paquets de SVR4, les premières distributions visant à faire de Linux un rival d’Unix pour les serveurs d’entreprise ont repris l’idée. En 1993-1994, les premiers gestionnaires de paquets spécifiques à Linux ont vu le jour. Le système de gestion des paquets de Rik Faith a ouvert la voie avec le peu connu Linux distro BOGUS. Il a inspiré la création du bien plus important Red Hat Package Manager (RPM) en 1994. À peu près au même moment, Ian Murdock, créateur de Debian Linux, a créé le gestionnaire de paquets Debian (dpkg).
Ces gestionnaires de paquets incluaient un suivi basique des dépendances. Ce n’est que lorsque des outils plus sophistiqués tels que Debian apt et Red Hat yum sont apparus à la fin des années 1990 que la résolution automatique des dépendances est devenue la norme. À partir de ce moment, la gestion des paquets est devenue la façon dont presque tout le monde installe et gère les correctifs et les programmes du système d’exploitation.
Mais à partir des années 2010, l’idée d’une distribution Linux immuable a commencé à prendre forme. Suite à la popularisation des conteneurs avec l’essor de Docker, les gens se sont intéressés aux distributions Linux minimales où les fichiers du système central sont verrouillés en lecture seule et ne peuvent être mis à jour que dans leur ensemble (c’est-à-dire de manière atomique) au lieu d’être mis à jour paquet par paquet.
Vous corrigez tout en même temps, y compris les mises à jour du système, lors d’un redémarrage
Avec les distributions Linux immuables, vous ne corrigez pas des problèmes individuels. Vous corrigez tout en même temps, y compris les mises à jour du système, lors d’un redémarrage. Cela signifie que tout est mis à jour en une seule transaction. En cas de problème, vous pouvez facilement revenir à un système opérationnel en redémarrant simplement l’ancienne image. Pas de problème, pas d’ennui.
Cette approche architecturale renforce considérablement la sécurité et la stabilité du système en empêchant les modifications non autorisées et en réduisant le risque de corruption du système. Au lieu de mettre à jour au coup par coup, comme le font la plupart des grandes distributions Linux, tout est mis à jour en une seule fois.
Outre l’essor des conteneurs, la sécurité et la fiabilité sont également à l’origine de ce changement dans la conception des plateformes. Avec un noyau en lecture seule, les serveurs sont moins vulnérables aux logiciels malveillants, aux erreurs de configuration accidentelles et aux modifications non autorisées.
La conteneurisation est une caractéristique clé
La conteneurisation est une caractéristique clé, qui isole les applications du système central et les unes des autres, ce qui réduit encore la surface d’attaque. Les distributions immuables simplifient également la maintenance en garantissant que chaque serveur exécutant la même image est cohérent et prévisible. Ce qui facilite la gestion des déploiements à grande échelle.
Le premier grand Linux immuable, CoreOS, est apparu en 2013 et a été conçu spécifiquement pour l’exécution de conteneurs à grande échelle.
Sa conception garantissait que le cœur de l’OS était en lecture seule, les mises à jour étant appliquées de manière atomique et déployées sous forme de nouvelles images. Cela le rendait idéal pour les environnements cloud-native et les clusters Kubernetes.
RHEL 10 adopte une approche immuable
En 2018, Red Hat, sachant reconnaître une bonne chose, a acheté CoreOS pour une bouchée de pain, 250 millions de dollars. À partir de CoreOS, Red Hat a créé trois autres distributions Linux importantes.
- La première d’entre elles est Fedora CoreOS, conçue pour le minimalisme et les mises à jour automatiques et atomiques. Fedora CoreOS est idéale pour l’hébergement de conteneurs et les clusters Kubernetes. Elle utilise rpm-ostree pour gérer la base immuable et autorise des paquets supplémentaires ou des charges de travail conteneurisées.
- Vient ensuite Fedora Silverblue, une variante immuable de Fedora Workstation. Silverblue a apporté l’immutabilité au bureau, en utilisant Flatpak pour la gestion des applications et ostree pour les mises à jour atomiques.
- Enfin, il y a Red Hat Enterprise Linux (RHEL) 10. Oui, c’est bien cela : Le système d’exploitation phare de Red Hat, RHEL 10, est la première grande distribution Linux d’entreprise à adopter l’approche immuable.
« Et si nous conteneurisions la couche du système d’exploitation ? »
Pourquoi ? Lors du Red Hat Summit qui s’est tenu le mois dernier à Boston, Chris Wells, directeur principal du marketing produit pour RHEL, a expliqué :
« Je parle à beaucoup d’administrateurs. Et ils me disent que leur bête noire est de devoir mettre à jour et mettre à niveau les systèmes. Ils savent qu’ils doivent le faire. Ils veulent le faire. Ils se demandent pourquoi c’est si difficile. Et si l’on y réfléchit bien, la façon dont nous prenons et corrigeons ces systèmes aujourd’hui vient vraiment du monde Unix d’où nous venons il y a 20 ans. C’est ainsi que nous avons traditionnellement fait les choses. Dans le monde Unix/Linux, nous avons de petits progiciels. Ils sont tous liés les uns aux autres, avec toutes les dépendances qu’il faut aller chercher pour les mettre à jour, et il faut croiser les doigts. Tout fonctionne.
Nous nous sommes dit qu’il y avait peut-être une meilleure façon de procéder. Nous nous sommes donc dit : « Et si nous conteneurisions la couche du système d’exploitation ? Et si je l’utilisais sur mes systèmes de production ? Et si la prochaine fois que je construis un nouveau système, au lieu de le faire de manière traditionnelle, en mode paquetage, je conteneurisais à la fois la couche d’application et le système d’exploitation, et que je mettais tout cela dans une image ? » Maintenant, tout d’un coup, j’ai cette image et je peux la déployer sur ces systèmes si quelque chose ne va pas. Au lieu de devoir revenir en arrière comme dans le passé, il suffit de remettre l’ancienne image en place, parce que, encore une fois, tout sera immuable ».
Opération très pénible pour les systèmes à haute disponibilité
Red Hat n’est pas la seule entreprise à avoir compris l’utilité d’un Linux immuable. Bien qu’il ne s’agisse pas de noms connus comme Ubuntu et SUSE Linux Enterprise Server (SLES), il existe de nombreuses distributions Linux immuables axées sur les entreprises, notamment Flatcar Container Linux et Ubuntu Core. Il existe également des distributions immuables axées sur la sécurité, comme Chainguard OS.
Cependant, il y a des compromis à faire. Les administrateurs système habitués à la gestion traditionnelle des paquets doivent s’adapter à de nouveaux flux de travail. Certaines personnalisations nécessiteront également des solutions de contournement. Par exemple, supposons que vous deviez modifier un paquet. C’est facile avec les anciennes méthodes. Avec les systèmes immuables, vous devez redémarrer le système. Cette opération peut s’avérer très pénible pour les systèmes à haute disponibilité.
Néanmoins, Red Hat est convaincu qu’à l’avenir, les avantages de Linux immuable l’emportent sur ses inconvénients. Historiquement, Red Hat a longtemps été le Linux d’entreprise dominant. Je ne parierais pas contre eux lorsqu’ils opèrent ce changement radical.