CentOS Stream : ce qui va changer et comment se préparer
11 décembre 2020
En tant que Directeur de l’activité de Conseil de LINAGORA, c’est ma fierté quotidienne de travailler avec des experts enthousiastes, brillants, et passionnés.
Tel est le cas de Pascal Vilarem, Directeur de l’agence LINAGORA Grand Sud-Est, couvrant la belle ville de Marseille et sa région. J’ai la chance d’être souvent accompagné par Pascal lors de nos missions de conseil, au cours desquelles il décrypte pour nos clients leur état de l’art technologique, les évolutions de notre écosystème et de ses communautés, les architectures les plus complexes.
C’est donc avec plaisir que je reproduis ici, une partie de l’échange que j’ai pu avoir avec Pascal dans la foulée de son premier post le 9 décembre 2020 à propos de l’irruption, le jour même, de CentOS Stream dans notre environnement.
En janvier 2014, RedHat annonçait se “rapprocher” de CentOS, et via ce sponsorship, en profitait pour recruter la quasi totalité de son board.
A cette date l’immense majorité des observateurs y voyaient une opération prudente, destinée à sécuriser son écosystème.
Or, si c’était déjà le cas en 2014, il est possible que, depuis, le rachat de Red Hat par IBM ait modifié un certain nombre de partis-pris stratégiques.
Toujours est-il que, en se réveillant le matin du 9 décembre 2020, la communauté découvre un changement majeur, et potentiellement durable, annoncé par CentOS, et faisant de CentOS 8.0 :
- la dernière des versions CentOS telles qu’on les connaissait jusqu’à ce jour ;
- une distribution supportée seulement jusqu’à fin 2021, soit une division par trois de la durée de support restante prévue.
Par conséquent, à compter de 2022 et à défaut de MaJ, l’utilisation de CentOS 8.0 en production dans des parcs Linux ne sera plus synonyme de sécurité et de stabilité.
En revanche, une nouvelle CentOS, nommée CentOS Stream, voit le jour : cette distribution n’est plus un clone a posteriori d’une RedHat stable, mais une ouverture au testing public de la version de développement de la future RedHat.
Dès lors, il faut considérer que CentOS ne sera plus une version stable et apte à la production, mais une version préfigurant la RedHat à venir. Cette version sera idéale pour que les salariés, fournisseurs et partenaires de RedHat puissent tester et développer leurs propres applications compatibles RedHat. En revanche, tous ceux qui utilisaient CentOS en production comme une alternative gratuite à RedHat vont devoir revoir leur stratégie de décommissionnement.
Comment réagir donc, et quelles sont les options ?
Pour l’année qui vient, ne rien changer en catastrophe, car les CentOS vont rester des CentOS et les RedHat vont rester des RedHat.
Mais cette année doit absolument être mise à profit pour réagir.
- L’option n°1 a vu le jour de manière quasi instantanée, et a été annoncée par Gregory Kurtzer (le créateur originel de CentOS) via la création d’un Repository Github nommé Rocky OS : “a community enterprise Operating System designed to be 100% bug-for-bug compatible with Red Hat Enterprise Linux”
Voici donc la communauté CentOS RockyOS face à un défi de taille : faire en sorte que cette distribution devienne viable en moins d’un an, avant la fin du support de CentOS 8.0.
Un challenge que la communauté est en capacité de remporter ? On l’espère.
- Option n°2 : basculer sur Ubuntu ou OpenSUSE, qui sont les deux distributions avec pignon sur rue alternatives à RedHat, Entreprise Ready, et avec des éditeur sur lesquels prendre appui.
- Option n°3 : basculer sur une Debian ou une Mageia qui sont des distributions “Full communautaires”, donc sans éditeur officiel aux commandes
- Point positif n°1: l’indépendance. Et la sécurité par rapport aux décisions potentiellement brutales que peuvent connaître les éditeurs en leur qualité d’organisations à but commercial.
- Point positif n°2 : la transparence. Et une discussion publique des roadmaps dans une processus démo/méritocratique permettant aux utilisateurs d’anticiper leurs évolutions.
- Point de vigilance n°1 : l’absence d’éditeur. Et donc pas de choix de choix évident unique et inévitable de l’interlocuteur unique prenant les engagements. Il faut donc choisir l’acteur qui fournira le support correspondant au besoin.
- Point de vigilance n°2 : pas de version long terme par défaut, même si les durées de vie des versions communautaires sont en général relativement longues. Il convient donc de négocier un support long terme spécifique généralement sous la forme d’une assurance Open Source (ou d’un tiers accompagnement opérationnel).
Raoul Delpech