L’annonce est tombée en décembre 2020, sans réel préavis pour les équipes d’exploitation qui géraient des parcs entiers de serveurs sous CentOS 8 : Red Hat a décidé d’arrêter le support de cette version dès le 31 décembre 2021, contre 2029 initialement promis au lancement de la distribution. CentOS, jusque-là clone stable et gratuit de Red Hat Enterprise Linux, devenait CentOS Stream, une branche de développement en amont, moins adaptée à un usage de production stable et prévisible.
Pour notre parc de serveurs WordPress sous CentOS 8, cette annonce imposait une migration de distribution complète, sans être accompagnée de la moindre montée de version PHP en parallèle : nous avons volontairement traité ces deux chantiers séparément, pour limiter les risques en cas d’incident et pouvoir identifier immédiatement la source d’un éventuel problème.
Choisir la distribution de destination
Deux alternatives se sont rapidement imposées comme successeurs crédibles de CentOS dans son rôle historique : Rocky Linux, porté par un des cofondateurs historiques de CentOS, et AlmaLinux, soutenu par CloudLinux. Les deux visaient une compatibilité binaire complète avec Red Hat Enterprise Linux, la même promesse que tenait CentOS avant son changement de modèle.
Notre choix s’est porté sur Rocky Linux, principalement pour deux raisons pragmatiques : la gouvernance annoncée comme une fondation à but non lucratif inspirait davantage de confiance sur la durée, et l’outil de migration migrate2rocky, publié rapidement par le projet, permettait une bascule sans réinstallation complète du serveur, un gain de temps considérable sur un parc de plusieurs dizaines de machines.
La méthode suivie, serveur par serveur
Contrairement à une tentation de scripter la migration en masse sur l’ensemble du parc en une seule nuit, nous avons délibérément traité chaque serveur individuellement, avec une fenêtre de validation complète entre chaque bascule :
# Sauvegarde complète avant toute opération
tar czf /backup/pre-migration-$(date +%F).tar.gz /etc /var/www
# Récupération et exécution du script de migration
curl -O https://raw.githubusercontent.com/rocky-linux/rocky-tools/main/migrate2rocky/migrate2rocky.sh
chmod +x migrate2rocky.sh
./migrate2rocky.sh -rLe script remplace les dépôts CentOS par ceux de Rocky Linux, puis réinstalle l’ensemble des paquets système avec leurs équivalents Rocky, en conservant la configuration existante. Le serveur redémarre ensuite sur le nouveau système, avec les services déjà configurés (nginx, PHP-FPM, MariaDB) qui doivent être vérifiés individuellement après le redémarrage.
Ce qui a demandé une vérification manuelle malgré tout
La compatibilité binaire annoncée entre CentOS et Rocky Linux a globalement tenu ses promesses, mais plusieurs points ont nécessité une vérification manuelle systématique après chaque migration :
- Les dépôts tiers ajoutés manuellement au fil du temps (dépôts EPEL, dépôts spécifiques à certaines versions de PHP) référençaient parfois encore explicitement CentOS dans leur configuration, nécessitant une mise à jour de leurs fichiers de définition pour pointer vers les miroirs compatibles Rocky Linux.
- Les certificats SELinux et les règles de pare-feu (firewalld) ont été revérifiés systématiquement, la migration ayant occasionnellement réinitialisé certaines règles personnalisées ajoutées manuellement sur certains serveurs.
- Les scripts de supervision internes, qui identifiaient parfois la distribution par une chaîne de caractères codée en dur (« CentOS Linux »), ont dû être ajustés pour reconnaître également « Rocky Linux » dans leurs vérifications automatiques.
Le calendrier réel de l’opération sur notre parc
Sur l’ensemble du parc concerné, l’opération s’est étalée sur plusieurs semaines, jamais en urgence absolue malgré l’échéance annoncée, grâce à une planification anticipée dès l’annonce de fin de vie. Chaque migration individuelle, en incluant sauvegarde préalable et vérification complète post-migration, prenait entre une heure et une heure trente selon la complexité de la configuration du serveur concerné.
- Semaine 1 : migration des serveurs de test et de recette, sans client en production dessus, pour valider la méthode et affiner le script de vérification post-migration.
- Semaines 2 à 5 : migration progressive des serveurs de production, par ordre croissant de criticité, en commençant par les sites au trafic le plus modeste.
- Semaine 6 : migration des serveurs les plus critiques, une fois la méthode éprouvée sur l’ensemble des cas précédents sans incident notable.
Une fin de vie de distribution annoncée avec un préavis raccourci reste gérable sans urgence excessive, à condition de ne pas attendre les derniers mois pour s’y mettre. Le vrai risque n’était pas technique, il était calendaire.
En résumé
La migration de CentOS 8 vers Rocky Linux, menée serveur par serveur avec sauvegarde systématique et vérification manuelle après chaque bascule, s’est déroulée sans incident majeur sur notre parc. L’outil migrate2rocky a tenu sa promesse de compatibilité binaire, à condition de ne pas négliger les dépôts tiers et les scripts internes qui référençaient encore explicitement CentOS. La montée de version PHP associée à ce parc a fait l’objet d’un chantier distinct, mené dans un second temps.
