Ubuntu 24.04 LTS (nom de code Noble Numbat) est sorti en avril 2024 avec l’engagement habituel de cinq ans de support standard, extensible via Ubuntu Pro. Pour une agence qui gère un parc de plusieurs serveurs WordPress en production, la question n’est jamais « faut-il migrer », mais « comment migrer sans faire tomber un site client au passage ». Ce planning couvre les douze serveurs migrés sur un trimestre, un par un, avec les pièges concrets rencontrés en route.
La première décision structurante a été de renoncer à l’upgrade in place (do-release-upgrade) sur les serveurs les plus anciens, au profit d’une reconstruction depuis une image neuve. La deuxième a été de traiter chaque serveur individuellement plutôt qu’en vagues automatisées, pour isoler tout problème sur un seul client à la fois plutôt que sur l’ensemble du parc simultanément.
Upgrade in place ou image neuve : le choix décisif
Sur des serveurs anciens (22.04, voire 20.04 pour certains legacy), la tentation de l’upgrade progressif via do-release-upgrade existe, mais elle accumule les couches d’historique : paquets tiers ajoutés au fil des années, configurations manuelles jamais documentées, dépendances obsolètes toujours présentes. Sur neuf des douze serveurs du parc, le choix a été de provisionner une machine neuve en 24.04, d’y reconstituer la stack (nginx, PHP-FPM, MariaDB) via les scripts de provisioning existants, puis de migrer les sites un par un vers cette nouvelle machine plutôt que de faire évoluer l’ancienne sur place.
Ce qui a réellement changé sous le capot
- PHP : le dépôt officiel Ubuntu 24.04 embarque PHP 8.3 par défaut, ce qui a nécessité de vérifier la compatibilité de certains plugins encore ancrés sur des pratiques PHP 7 avant la bascule.
- Noms d’interfaces réseau : avec
netplandésormais généralisé, certaines interfaces ont changé de nom entre l’ancienne configuration et la nouvelle installation, cassant silencieusement des règles de pare-feu qui référençaient l’ancien nom d’interface. - systemd et les unités de service : quelques scripts de démarrage personnalisés écrits pour d’anciennes versions de systemd ont nécessité une adaptation mineure de leurs unités.
# Vérifier le nom réel des interfaces avant d'écrire une règle de pare-feu
ip -br link show
# Exemple de fichier netplan minimal pour une interface renommée
network:
version: 2
ethernets:
enp1s0:
dhcp4: true
Le piège du pare-feu qui référence l’ancienne interface
Sur deux des douze serveurs, une règle iptables personnalisée faisait explicitement référence à eth0, nom hérité d’une ancienne convention de nommage. Sur la nouvelle installation 24.04, l’interface est apparue sous le nom enp1s0, laissant la règle de pare-feu totalement inopérante sans erreur visible au démarrage. Le trafic passait, mais aucune des restrictions prévues ne s’appliquait plus, un risque de sécurité silencieux découvert uniquement lors d’un audit de configuration post-migration.
La checklist suivie pour chaque serveur
- Provisionner la machine neuve en 24.04 LTS via les scripts de provisioning maison, sans copier l’ancienne configuration telle quelle.
- Vérifier les versions de PHP, MariaDB et nginx installées par défaut face aux versions utilisées sur l’ancien serveur.
- Recréer les règles de pare-feu en vérifiant le nom réel des interfaces réseau avec
ip -br link show. - Migrer un site pilote non critique en premier, observer une semaine complète avant de poursuivre.
- Basculer les sites restants un par un, avec surveillance renforcée sur les 48 premières heures de chacun.
- Ne désactiver l’ancien serveur qu’après une période de recouvrement d’au moins deux semaines.
| Composant | Version sur 22.04 | Version par défaut sur 24.04 |
|---|---|---|
| PHP (dépôt officiel) | 8.1 | 8.3 |
| Noyau Linux | 5.15 | 6.8 |
| Gestion réseau | netplan (partiel) | netplan généralisé |
Une montée de version de système d’exploitation ne se planifie jamais sur le calendrier de la distribution : elle se planifie sur la disponibilité réelle de l’équipe pour surveiller de près chaque serveur migré pendant les premiers jours.
Ce qui n’a pas posé de problème
Contrairement aux craintes initiales, la migration de MariaDB s’est révélée moins problématique que prévu : les fichiers de dump SQL classiques importés sur la nouvelle version se sont comportés normalement, sans incompatibilité de syntaxe rencontrée sur ce parc. La montée de version PHP associée à cette migration système, elle, fait l’objet d’un traitement séparé et n’est volontairement pas détaillée ici.
En résumé
Migrer un parc de serveurs WordPress vers Ubuntu 24.04 LTS se joue moins sur la distribution elle-même que sur la discipline de migration : préférer une image neuve à un upgrade in place sur les serveurs anciens, vérifier systématiquement les noms d’interfaces réseau avant de recréer les règles de pare-feu, et avancer serveur par serveur plutôt qu’en vague groupée. Le vrai risque n’est jamais dans la nouveauté de la distribution, mais dans les habitudes silencieuses héritées de l’ancienne configuration.
