Rocky Linux ou AlmaLinux pour un VPS ?

Rocky Linux ou AlmaLinux : réponse courte

Pour presque tous les serveurs, choisir entre Rocky Linux et AlmaLinux ne présente pas de mauvais choix. Les deux projets recompilent le même code source que Red Hat Enterprise Linux (RHEL). Ils fournissent donc les mêmes paquets, avec le même cycle de support de dix ans. Les différences sont réelles, mais elles concernent la gouvernance et quelques cas particuliers, pas l’administration quotidienne d’un serveur.

Deux éléments déterminent le choix lorsqu’il ne s’agit pas de choisir au hasard. AlmaLinux 10 fournit encore une build pour les processeurs antérieurs à Intel Haswell, contrairement à Rocky Linux 10. Cela compte sur les VPS (virtual private server) moins chers ou dotés d’un matériel plus ancien. AlmaLinux garantit également la compatibilité ABI plutôt qu’un comportement identique. Cela compte si vous utilisez un produit éditeur soumis à une matrice de support stricte.

D’où provenaient les deux distributions

Le 8 décembre 2020, le projet CentOS a annoncé que CentOS Linux 8, une reconstruction de RHEL 8, arriverait en fin de vie à la fin de 2021. Sa date de fin de vie avait été annoncée pour 2029. L’avenir du projet serait CentOS Stream. Dans la même annonce, celui-ci était décrit comme une version qui suit de peu une version actuelle de RHEL et qui sert de branche de développement en amont de RHEL. CentOS Linux 7 a conservé son calendrier initial et est arrivé en fin de vie le 30 juin 2024.

Le problème ne venait pas de CentOS Stream lui-même. Le problème était qu’un cycle de vie prévu jusqu’en 2029 a été raccourci de huit ans, avec environ un an de préavis, sur des machines déjà installées. Rocky Linux et AlmaLinux existent tous les deux pour cette raison. Ils sont apparus en 2021 et visaient le même objectif : fournir une reconstruction gratuite de RHEL qu’un administrateur pouvait installer, puis laisser fonctionner pendant dix ans. La raison pour laquelle CentOS remplissait initialement ce rôle, ainsi que l’évolution d’un Linux de Red Hat vers Fedora, RHEL et une série de reconstructions, sont présentées dans l’histoire plus détaillée de Red Hat, CentOS, Rocky et AlmaLinux.

Ce que Rocky Linux et AlmaLinux ont en commun

Commencez par ce point, car la partie commune représente l’essentiel. Les deux distributions sont reconstruites à partir des mêmes sources RHEL en amont. Elles fournissent donc les mêmes versions de paquets, le même gestionnaire de paquets dnf, la même politique SELinux (security enhanced Linux), la même interface firewalld et la même organisation des unités systemd. Les fichiers de configuration se trouvent dans les mêmes chemins. Un guide écrit pour l’une fonctionne sur l’autre en remplaçant simplement le nom de la distribution. Cela vaut aussi pour les tâches courantes : installer Docker Engine s’effectue de la même façon sur les deux, jusque dans le paquet podman qui fournit la commande docker et le réétiquetage SELinux requis par les bind mounts. Le pare-feu se comporte également de la même manière. Ainsi, ouvrir SSH et un port web avec firewalld utilise des commandes firewall-cmd identiques sur les deux distributions, y compris le flag --permanent qui détermine si une règle est conservée après un redémarrage.

Les deux distributions suivent de près les versions mineures de RHEL. AlmaLinux 10.2 est sortie le 26 May 2026 et Rocky Linux 10.2 le 28 May 2026. La série 9 a évolué durant la même semaine : AlmaLinux 9.8 le 26 May 2026 et Rocky Linux 9.8 le 27 May 2026. L’écart était plus important auparavant. AlmaLinux 10.0 est sortie le 27 May 2025 et Rocky Linux 10.0 le 11 June 2025.

Cette différence concerne les supports des versions mineures, pas la sécurité. Les deux projets publient continuellement des errata entre les versions mineures, chacun depuis son propre service d’errata. Un décalage de deux semaines dans la disponibilité d’une image .2 ne signifie pas deux semaines sans correctifs. Récupérer ces errata sans se connecter demande la même configuration sur les deux distributions. Ainsi, configurer dnf-automatic pour installer automatiquement les mises à jour de sécurité suit les mêmes étapes, quelle que soit la distribution installée. Installer un correctif ne revient pas à l’appliquer. déterminer quelles mises à jour nécessitent un redémarrage et lesquelles nécessitent un redémarrage de service utilise la même commande needs-restarting sur les deux distributions, car elles l’héritent du même paquet RHEL.

Les deux distributions appliquent également le cycle de vie de dix ans hérité de RHEL : environ cinq ans de support actif, puis cinq ans de maintenance limitée aux correctifs de sécurité. La série 10 des deux distributions est prise en charge jusqu’en 2035.

Qui se trouve derrière chaque projet ?

Rocky Linux appartient à la Rocky Enterprise Software Foundation (RESF), une benefit corporation de droit public du Delaware créée par Gregory Kurtzer, cofondateur de CentOS. En novembre 2022, la RESF a ratifié des statuts et une charte qui ont transféré le contrôle des mains de son fondateur vers cette structure écrite. CIQ, une entreprise également fondée par Kurtzer, est le sponsor fondateur et vend un support commercial pour Rocky Linux.

AlmaLinux appartient à l’AlmaLinux OS Foundation, une organisation à but non lucratif de type 501(c)(6), constituée dans le Delaware et fondée en mars 2021. Son conseil d’administration est élu par les membres de la fondation pour des mandats de quatre ans échelonnés. Les comptes rendus des réunions sont publiés dans un délai de quatorze jours. Un article des statuts interdit à un même employeur de détenir plus d’un siège avec droit de vote au conseil, quel que soit le montant de son sponsoring. CloudLinux a lancé le projet et a renouvelé en octobre 2024 un sponsoring platinum d’un million de dollars par an. Sa division TuxCare vend le support commercial.

Les deux structures ont été conçues pour empêcher une entreprise unique de reproduire ce qui s’est produit avec CentOS Linux 8. Aucune n’est manifestement plus sûre que l’autre. Ce que vous pouvez réellement vérifier est identique dans les deux cas : vous pouvez lire les statuts et identifier l’organisation qui finance le projet.

Qu'est-ce qui a changé en 2023 et est-ce toujours important ?

Le 21 juin 2023, Red Hat a annoncé que CentOS Stream deviendrait le seul dépôt public du code source lié à RHEL. Auparavant, les sources des paquets RHEL apparaissaient sur git.centos.org, où les projets de reconstruction les récupéraient. La suppression de ce flux n’a pas arrêté les reconstructions. Elle a obligé chaque projet à expliquer publiquement comment il obtiendrait les sources.

Rocky a répondu le 29 juin 2023. Le projet obtient les sources de RHEL à partir des images de conteneurs Universal Base Image (UBI) et d’instances de cloud public à l’usage, en partant du principe que « personne ne peut empêcher la redistribution de logiciels sous licence GPL ». En août 2023, CIQ, Oracle et SUSE ont créé l’Open Enterprise Linux Association (OpenELA), qui publie les sources nécessaires à une reconstruction d’Enterprise Linux compatible bug pour bug. AlmaLinux n’en est pas membre.

AlmaLinux a répondu le 13 juillet 2023, mais sa réponse consistait à changer d’objectif. Le projet a abandonné la compatibilité bug pour bug 1:1 et a adopté la compatibilité ABI. Pour reprendre ses propres termes, « nous ne serons plus tenus de respecter une compatibilité bug pour bug avec Red Hat, ce qui signifie que nous pouvons désormais accepter des corrections de bugs en dehors du cycle de publication de Red Hat ». Le même article indiquait aux utilisateurs de s’attendre à « très peu de changements » au quotidien.

Trois ans plus tard, la question de l’accès aux sources est réglée dans la pratique. Les deux projets ont publié chaque version mineure de RHEL depuis, selon des calendriers similaires. Ce qui reste de cette controverse, c’est la différence entre les engagements de chacun.

Compatibilité bug pour bug ou compatibilité ABI : quelle différence ?

La page d’accueil de Rocky Linux décrit toujours la distribution comme conçue pour être compatible à 100 % bug pour bug avec RHEL. Bug pour bug signifie que la reconstruction reproduit le comportement de RHEL, y compris ses défauts. Si un paquet RHEL contient un bug, le même paquet dans Rocky Linux le contient aussi. Une solution de contournement proposée dans un article de la base de connaissances Red Hat s’applique donc sans adaptation.

La compatibilité ABI est plus restreinte et plus précise. L’ABI, ou interface binaire d’application, est le contrat binaire dont dépend un programme compilé : noms des symboles, disposition des structures, conventions d’appel et versions des bibliothèques. Si ce contrat reste stable, un binaire compilé pour RHEL se charge et s’exécute. Cette garantie ne dit rien sur la reproduction des bugs de RHEL.

La conséquence est simple. AlmaLinux peut corriger un bug avant Red Hat et conserver un pilote que Red Hat a supprimé. Ces deux choix éloignent volontairement son comportement de celui de RHEL. Rocky Linux ne fera ni l’un ni l’autre, conformément à sa conception. Son comportement reste donc prévisible, exactement comme l’exige une certification.

La question est donc de savoir de quelle garantie vous avez besoin. Le serveur doit-il se comporter exactement comme RHEL, ou les logiciels conçus pour RHEL doivent-ils pouvoir s’y exécuter ? Presque tout le monde a besoin de la seconde.

Les paquets du fournisseur conçus pour RHEL s’installent-ils sur les deux systèmes ?

Oui. Un paquet RPM conçu pour RHEL 9 ou RHEL 10 s’installe et fonctionne sur les deux systèmes, car l’ABI correspond et les deux distributions se présentent aux outils comme des systèmes de la famille Red Hat. Le fichier qui assure cette identification est /etc/os-release.

NAME="AlmaLinux"
ID="almalinux"
ID_LIKE="rhel centos fedora"

La copie de Rocky Linux a la même structure avec NAME="Rocky Linux" et ID="rocky", et elle indique également rhel dans ID_LIKE. Un script d’installation qui lit ID_LIKE, trouve rhel et utilise le chemin Red Hat fonctionne sur les deux systèmes. Un script qui compare uniquement ID à une liste codée en dur contenant rhel, centos et fedora échoue sur les deux systèmes, de la même manière, avec un message indiquant que la distribution n’est pas prise en charge. Le problème vient du script, pas d’une différence entre les deux systèmes.

La véritable exception est commerciale, et non technique. Une matrice de prise en charge est un document commercial. Le paquet d’un fournisseur peut s’installer et fonctionner parfaitement sur une distribution qui n’apparaît pas dans la matrice, mais le fournisseur peut tout de même refuser de vous aider en cas de problème. Si vous payez ce support, consultez la matrice et laissez-la guider votre choix. C’est le seul cas où la décision est prise pour vous.

Lequel fonctionne encore sur les anciens processeurs ?

RHEL 10 a relevé le niveau de microarchitecture x86-64 minimal à x86-64-v3. Ce niveau correspond à la génération Haswell d’Intel et à Excavator d’AMD. Il nécessite des extensions du jeu d’instructions telles qu’AVX2. Rocky Linux 10 suit RHEL sur ce point. Sa documentation indique que x86-64-v3 constitue le niveau minimal et que le niveau v2 et les niveaux antérieurs ne sont plus pris en charge.

AlmaLinux 10 fournit par défaut la build v3 et ajoute une build x86-64-v2 distincte. Selon ses propres termes, cela permet aux utilisateurs équipés de ce matériel plus ancien de continuer à recevoir des mises à jour de sécurité pendant encore dix ans. AlmaLinux reconstruit également les paquets EPEL pour cette architecture, car les paquets RHEL 10 tiers ciblent v3. C’est le point important à connaître avant de vous appuyer dessus : la build v2 convient à l’ensemble de paquets par défaut ainsi qu’à l’EPEL v2 d’AlmaLinux, mais tout le reste doit être recompilé par vos soins pour v2.

Cela compte davantage sur un VPS que sur du matériel qui vous appartient, car vous ne choisissez pas le processeur de l’hôte. Sur les hôtes anciens ou moins chers, ou lorsque l’hyperviseur présente au guest un modèle de CPU conservateur, la machine virtuelle peut ne pas exposer AVX2, même si la puce physique le prend en charge. Les paquets compilés pour v3 tentent alors d’utiliser des instructions absentes du processeur et échouent. Vérifiez ce que votre instance expose réellement avant de déployer une flotte en version 10. La version 9 des deux distributions fonctionne encore au niveau v2. Sur les instances ARM plutôt que les instances x86, la question ne se pose jamais, car les niveaux de microarchitecture sont propres à x86-64.

Cette même liberté se retrouve ailleurs dans AlmaLinux 10. Le projet a rétabli la prise en charge de plus de 150 périphériques supprimés en amont, notamment les PCI IDs d’anciens contrôleurs RAID et iSCSI. Il a également rétabli la prise en charge de SPICE côté serveur et côté client. Les frame pointers sont activés par défaut, ce qui permet le profiling à l’échelle du système. Une promesse de compatibilité bug pour bug interdit chacune de ces modifications. La décision prise en 2023 a donc créé la marge nécessaire pour les effectuer.

Comment migrer un serveur CentOS ou RHEL existant ?

Rocky Linux publie des scripts de conversion dans son dépôt rocky-tools. migrate2rocky.sh convertit un système Enterprise Linux 8 en Rocky Linux 8, et migrate2rocky9.sh fait de même pour la série 9. Chaque script fonctionne au sein d’une même version majeure. En août 2026, le dépôt ne contient aucun script équivalent pour Enterprise Linux 10. Passer à Rocky Linux 10 nécessite donc une réinstallation.

AlmaLinux publie almalinux-deploy.sh. Cet outil prend en charge Enterprise Linux 8, 9 et 10 et effectue la conversion depuis CentOS Stream, Oracle Linux, RHEL, Rocky Linux, MiracleLinux et Virtuozzo Linux, sur x86_64, aarch64, ppc64le et s390x. Lisez ses limites documentées avant de commencer. Seul le boot loader GRUB2 est pris en charge sur les systèmes qui en ont besoin. Un kernel personnalisé tel que l’UEK (unbreakable enterprise kernel) d’Oracle n’est pas supprimé automatiquement, ce qui empêche la machine de démarrer avec Secure Boot.

Pour passer d’une version majeure à une autre, AlmaLinux maintient ELevate, basé sur le framework leapp de Red Hat. Les chemins documentés sont CentOS 7 vers EL8, AlmaLinux 8 ou CentOS Stream 8 vers EL9, et AlmaLinux 9 ou CentOS Stream 9 vers EL10. La documentation indique la cible sous la forme EL8, EL9 ou EL10 au lieu de nommer une distribution précise, car vous choisissez l’Enterprise Linux sur lequel vous aboutissez.

Toutes ces procédures réécrivent les release packages et réinstallent une grande partie du système. Créez d’abord un snapshot chez votre fournisseur. Exécutez la conversion dans screen ou tmux, comme le recommande la documentation d’AlmaLinux. Une déconnexion SSH au milieu de la procédure laisserait la machine dans un état qu’il serait difficile de diagnostiquer depuis une rescue console.

Alors, lequel choisir ?

Pour une charge de travail VPS classique, les deux conviennent. Ils installent les mêmes paquets et arrivent en fin de support la même année. Choisissez-en un, utilisez-le sur tous les serveurs que vous administrez et n’y pensez plus. La cohérence compte davantage que leurs différences, car une flotte mixte double le nombre d’images et de flux d’errata à suivre. Ce coût augmente rapidement dès que vous administrez plusieurs serveurs Linux à la fois.

Les exceptions sont limitées, et chacune dépend d’un facteur extérieur à votre préférence.

• Le processeur de votre hôte est antérieur à Haswell, ou l’hyperviseur masque AVX2 au guest. AlmaLinux 10 propose un build x86-64-v2. Rocky Linux 10 n’en propose pas.
• Un fournisseur auquel vous payez un support indique une seule distribution dans sa matrice de support. Utilisez celle-ci.
• Vous avez besoin d’un comportement identique à RHEL pour une certification ou un audit. L’objectif déclaré de Rocky Linux est la compatibilité bug pour bug, tandis que celui d’AlmaLinux ne l’est explicitement pas.
• Vous convertissez un serveur en fonctionnement au lieu d’en créer un nouveau. Les outils d’AlmaLinux couvrent actuellement davantage de distributions sources et de versions majeures, notamment Enterprise Linux 10.

Si la vraie question porte sur Enterprise Linux par rapport à une autre solution, c’est le modèle de cycle de vie que vous choisissez. Une distribution Enterprise Linux vous offre dix ans avec un même ensemble de paquets, sans saut de version à planifier. Les versions Ubuntu à support long terme offrent cinq ans de support standard, avec un chemin de mise à niveau pris en charge tous les deux ans. C’est un compromis différent, expliqué dans la comparaison entre Ubuntu LTS et les versions interim. Quelle que soit la distribution installée, la première heure sur la machine se déroule de la même manière. Suivez donc les dix premières minutes sur un nouveau VPS avant d’y installer quoi que ce soit.

FAQ

Rocky Linux ou AlmaLinux est-il le plus proche de Red Hat Enterprise Linux ?

Rocky Linux, selon son objectif déclaré. Sa page d’accueil décrit la distribution comme conçue pour être compatible à 100 %, bogue par bogue, avec RHEL. Elle vise donc à reproduire le comportement de RHEL, y compris ses défauts. AlmaLinux a annoncé le 13 juillet 2023 qu’elle viserait plutôt la compatibilité ABI (interface binaire d’application). Les logiciels compilés pour RHEL peuvent ainsi fonctionner dessus, même si le code sous-jacent contient des correctifs que RHEL n’a pas encore intégrés. Pour exécuter des logiciels serveur courants, les deux distributions sont équivalentes. Pour une certification qui exige le comportement de RHEL, cette distinction est essentielle.

Puis-je passer de Rocky Linux à AlmaLinux sans réinstaller le système ?

Oui, dans ce sens. La page almalinux-deploy.sh d’AlmaLinux liste Rocky Linux 8, 9 et 10 parmi ses sources prises en charge, ainsi que CentOS Stream, Oracle Linux, RHEL et MiracleLinux. Le passage inverse est plus limité : le dépôt rocky-tools de Rocky fournit des scripts de conversion pour Enterprise Linux 8 et 9 uniquement. Il n’existe donc pas de procédure de migration sur place vers Rocky Linux 10 en août 2026. Créez un snapshot avant toute conversion et exécutez-la depuis une session qui résiste à une coupure de connexion, car le processus remplace les paquets de release et réinstalle une grande partie du système.

Les paquets compilés pour RHEL fonctionnent-ils sur les deux distributions ?

Oui, pour les paquets RPM classiques et les dépôts tiers. Les deux distributions conservent l’interface binaire d’application de RHEL et s’identifient avec ID_LIKE="rhel centos fedora" dans /etc/os-release. Un paquet ou un script d’installation qui vérifie la présence d’un système de la famille Red Hat choisit donc le chemin approprié. L’exception est commerciale, et non technique : un éditeur peut prendre en charge uniquement les distributions mentionnées dans sa matrice de support, même si son paquet s’installe et fonctionne sur les deux. Si vous payez ce support, fiez-vous à la matrice.

Quelle distribution utiliser sur un VPS peu coûteux équipé d’un processeur ancien ?

AlmaLinux, si vous voulez la série 10. RHEL 10 a relevé la configuration minimale x86-64 au niveau de la microarchitecture v3. Il faut donc un processeur au niveau d’un Intel Haswell ou d’un AMD Excavator. Rocky Linux 10 suit cette configuration minimale. AlmaLinux 10 fournit en plus une build x86-64-v2 pour les matériels plus anciens, avec dix ans de mises à jour de sécurité. Vérifiez ce que votre instance expose avant de vous décider, car une machine virtuelle voit le modèle de processeur fourni par l’hyperviseur, et pas toujours l’ensemble des instructions du serveur hôte. La série 9 des deux distributions fonctionne encore sur du matériel v2.