Ubuntu 24.04 : les changements Netplan ne s’appliquent pas — pourquoi (et comment les rendre persistants)

Feuille de route pour un diagnostic rapide

Quand les changements Netplan ne s’appliquent pas, le moyen le plus rapide est d’arrêter de deviner et de répondre à trois questions :
(1) Qui rend le réseau ? (2) Qui écrase le YAML ? (3) Qu’est-ce que Netplan a généré ?
Vous pouvez faire cela en moins de cinq minutes si vous restez discipliné.

1) Confirmer le renderer actif (NetworkManager ou systemd-networkd)

• Vérifiez quel service gère réellement l’interface (pas celui que vous préférez).
• Si NetworkManager la gère, éditer renderer: networkd ne vous donnera pas automatiquement raison.

2) Vérifier si cloud-init réécrit la configuration réseau au démarrage

• Si vous êtes sur une image cloud (ou dérivée), supposez que cloud-init a des opinions.
• Recherchez /etc/netplan/50-cloud-init.yaml et les journaux associés.

3) Valider le YAML et inspecter la sortie générée

• Netplan compile le YAML en configurations backend.
• Si les fichiers générés ne correspondent pas à ce que vous attendez, Netplan n’a pas compris votre YAML ou ne l’a pas lu.

4) Appliquer en toute sécurité (ne pas s’auto-DDoS son propre SSH)

• Utilisez netplan try pour des changements à distance.
• Puis vérifiez avec ip addr, ip route et la résolution DNS.

Si vous ne devez faire qu’une chose : cessez d’éditer des fichiers YAML au hasard tant que vous n’avez pas identifié quel fichier YAML est autoritatif et quel renderer est actif.
Sinon vous rejouez simplement le même échec avec plus d’assurance.

Comment Netplan fonctionne réellement (et pourquoi vos modifications disparaissent)

Netplan n’est pas votre gestionnaire de réseau. Netplan est une couche d’abstraction et un générateur de configuration :
vous déclarez l’intention en YAML sous /etc/netplan/, et Netplan génère la configuration pour un renderer backend — le plus souvent
systemd-networkd sur les serveurs, et NetworkManager sur les postes (et de plus en plus sur des installations « server-ish » où l’on veut des outils graphiques ou du Wi‑Fi).

Cette distinction compte parce qu’elle crée trois modes de défaillance courants :

1. Vous avez modifié le mauvais fichier (un fichier existe, mais ce n’est pas celui utilisé après priorité/ordre lexicographique).
2. Le renderer n’est pas celui que vous pensez (NetworkManager contrôle l’interface alors que vous écrivez une intention au format networkd).
3. Un autre système le réécrit (cloud-init est le suspect habituel, mais pas le seul).

Et oui : vous pouvez exécuter netplan apply et ne rien voir changer si le service backend rejette la config générée, si l’interface est non gérée, ou si le YAML a été ignoré.
Le travail de Netplan est en grande partie terminé une fois qu’il a écrit les fichiers générés et demandé au backend de recharger.

Les équipes fiabilité aiment la propriété claire. Les configurations Netplan échouent quand la propriété est floue :
NetworkManager contrôle certains périphériques, networkd d’autres, cloud-init écrit le YAML, et les admins « réparent » en éditant le fichier qui semble le plus évident.
C’est ainsi qu’on obtient un système où tout est configuré, et rien ne fonctionne.

Faits et contexte historique à utiliser dans vos arguments

Quelques points concrets à glisser dans une revue de conception ou un postmortem, parce que « on a l’impression que » n’est pas une cause racine.

1. Netplan a été introduit pour la première fois dans Ubuntu 17.10 comme tentative de Canonical d’unifier la configuration réseau entre installateurs et environnements.
2. Netplan est du YAML déclaratif, mais la machine exécute finalement la configuration native d’un renderer (unités networkd ou profils NetworkManager).
3. L’ordre des fichiers compte : Netplan lit les fichiers YAML par ordre lexical ; les fichiers ultérieurs peuvent écraser les précédents.
4. Les images cloud utilisent souvent cloud-init pour générer 50-cloud-init.yaml, et il peut le régénérer au démarrage selon la datasource et les paramètres.
5. NetworkManager peut gérer des NIC « serveur » aujourd’hui, surtout quand on veut des outils cohérents entre laptops et serveurs.
6. systemd-networkd n’est pas NetworkManager : il est plus léger, plus déterministe, et souvent préféré pour les serveurs headless — mais il ne touchera pas les interfaces qu’il ne gère pas.
7. Ubuntu a déplacé la gestion du DNS au fil des ans (resolvconf, puis systemd-resolved, plus les comportements propres à NM). Un DNS « qui ne s’applique pas » est souvent un empilement de résolveurs, pas Netplan.
8. « Appliquer » n’est pas toujours « persister » : un changement runtime peut survenir mais être écrasé au redémarrage par cloud-init, de l’automatisation, ou un renderer différent.

Symptômes typiques et ce qu’ils signifient généralement

Symptôme : netplan apply s’exécute sans erreur, mais l’IP ne change jamais

Généralement : l’interface n’est pas gérée par le renderer pour lequel vous générez, ou le YAML que vous avez édité n’est pas celui utilisé.
Occasionnellement : le backend a rejeté la configuration et est revenu en arrière sans bruit dans votre terminal.

Symptôme : ça marche jusqu’au redémarrage, puis ça revient en arrière

Généralement : cloud-init a réécrit le fichier au démarrage, ou un système de gestion de configuration (ou un script « first boot » de l’image) a ré-appliqué une ancienne config.
Moins souvent : vous avez édité un fichier qui perd la partie face à un autre fichier YAML par ordre lexical.

Symptôme : les routes sont incorrectes (on peut ping la passerelle mais pas l’extérieur)

Généralement : la route par défaut n’a pas été appliquée, une seconde interface gagne la route par défaut, ou du routage par politique est présent (les VPN et overlays adorent ça).

Symptôme : le DNS ne correspond pas à ce que vous avez mis dans le YAML

Généralement : systemd-resolved utilise un upstream différent, NetworkManager pousse le DNS, ou vous regardez /etc/resolv.conf sans vérifier s’il s’agit d’un stub ou d’un lien symbolique.

Une citation pour garder les mains calmes pendant la réaction à incident :
« L’espoir n’est pas une stratégie. » — James Cameron

Blague n°1 : Si votre configuration réseau « s’est appliquée » mais que rien n’a changé, félicitations — vous avez atteint l’ambiguïté de niveau entreprise.

Tâches pratiques : commandes, signification des sorties et décisions

Voici des vérifications réelles et exécutables. Chacune inclut : ce que vous lancez, ce que la sortie vous dit, et quelle décision prendre ensuite.
Faites-les dans l’ordre quand vous êtes de garde et que votre futur vous remercie.

Task 1: Lister les fichiers Netplan et voir ce qui peut écraser quoi

cr0x@server:~$ ls -l /etc/netplan/
total 8
-rw-r--r-- 1 root root  348 Nov  2 10:14 00-installer-config.yaml
-rw-r--r-- 1 root root  512 Nov  2 10:15 50-cloud-init.yaml

Signification : Netplan lit le YAML par ordre lexical. Si les deux définissent la même interface, le fichier le plus tardif (ici 50-cloud-init.yaml) peut l’emporter.
Décision : Si vous avez modifié 00-installer-config.yaml en pensant que ça resterait, vous avez probablement perdu la bataille d’override. Modifiez soit le fichier autoritatif, soit supprimez la source des overrides.

Task 2: Voir ce que Netplan pense être la config fusionnée

cr0x@server:~$ sudo netplan get
network:
  ethernets:
    eno1:
      dhcp4: false
      addresses:
      - 10.20.30.40/24
      routes:
      - to: default
        via: 10.20.30.1
      nameservers:
        addresses:
        - 10.20.0.53
        - 10.20.0.54
  version: 2
  renderer: networkd

Signification : C’est la configuration effective après le parsing et la fusion des fichiers.
Décision : Si netplan get n’affiche pas vos modifications, Netplan ne lit pas votre édition (mauvais fichier, erreur YAML, ou fichier écrasé). Corrigez cela avant de toucher aux backends.

Task 3: Valider la syntaxe (et attraper les pièges YAML invisibles)

cr0x@server:~$ sudo netplan --debug generate
DEBUG:command generate: running ['/usr/libexec/netplan/generate']
DEBUG:Parsing /etc/netplan/00-installer-config.yaml
DEBUG:Parsing /etc/netplan/50-cloud-init.yaml
DEBUG:eno1: setting default backend to 1
DEBUG:Configuration is valid

Signification : « Configuration is valid » est nécessaire, pas suffisante. Mais si ceci échoue, arrêtez-vous et corrigez le YAML.
Décision : Si la sortie debug parse un fichier différent de celui que vous avez édité, vous travaillez sur la mauvaise entrée.

Task 4: Inspecter la configuration backend générée (ce qui est réellement appliqué)

cr0x@server:~$ sudo ls -l /run/systemd/network/
total 4
-rw-r--r-- 1 root root 682 Nov  2 10:16 10-netplan-eno1.network

Signification : Netplan a généré une unité networkd à l’exécution.
Décision : Ouvrez-la. Si elle ne contient pas vos adresses/routes, Netplan ne génère pas ce que vous pensez. Si elle le fait, le problème vient de l’application par le backend ou d’un conflit de gestion d’interface.

Task 5: Lire le fichier généré pour confirmer l’intention exacte appliquée

cr0x@server:~$ sudo sed -n '1,120p' /run/systemd/network/10-netplan-eno1.network
[Match]
Name=eno1

[Network]
Address=10.20.30.40/24
DNS=10.20.0.53 10.20.0.54
Gateway=10.20.30.1

Signification : Si cela correspond, Netplan a fait son travail. Vous déboguez maintenant networkd (ou des conflits).
Décision : Si ce n’est pas cohérent, revenez au YAML Netplan et à l’ordre des fichiers ; ne « corrigez » pas networkd directement à moins de vouloir lutter contre Netplan à chaque reboot.

Task 6: Identifier quel service gère le lien

cr0x@server:~$ networkctl status eno1
● 2: eno1
                 Link File: /usr/lib/systemd/network/99-default.link
              Network File: /run/systemd/network/10-netplan-eno1.network
                      Type: ether
                     State: routable (configured)
              Online state: online
                   Address: 52:54:00:12:34:56

Signification : networkd gère eno1, et le considère configuré.
Décision : Si l’état est « unmanaged » ou « configuring », cherchez pourquoi networkd ne le prend pas (nom de match incorrect, mismatch de renderer, ou NM qui le prend).

Task 7: Vérifier si NetworkManager est aussi impliqué (et donc capable de vous annuler)

cr0x@server:~$ nmcli dev status
DEVICE  TYPE      STATE      CONNECTION
eno1    ethernet  unmanaged  --
lo      loopback  unmanaged  --

Signification : NM ne gère pas l’appareil. C’est bon si vous utilisez networkd.
Décision : Si NM affiche connected avec un profil sur l’interface, arrêtez-vous et décidez si NM ou networkd est le propriétaire voulu — puis faites correspondre le renderer Netplan.

Task 8: Vérifier l’IP et la route runtime réelles (ne faites pas confiance à un seul outil)

cr0x@server:~$ ip -br addr show eno1
eno1             UP             10.20.30.40/24

cr0x@server:~$ ip route show
default via 10.20.30.1 dev eno1 proto static
10.20.30.0/24 dev eno1 proto kernel scope link src 10.20.30.40

Signification : C’est la vérité terrain. Si c’est incorrect, le changement ne s’est pas appliqué, ou a été écrasé après application.
Décision : Si le runtime est correct mais la connectivité est cassée, passez au DNS/pare-feu/routage en amont. Si le runtime est incorrect, revenez au contrôle du renderer et aux configs générées.

Task 9: Vérifier les logs de systemd-networkd pour des rejets ou des flaps

cr0x@server:~$ sudo journalctl -u systemd-networkd -b --no-pager | tail -n 20
Nov 02 10:16:21 server systemd-networkd[812]: eno1: Configuring with /run/systemd/network/10-netplan-eno1.network.
Nov 02 10:16:21 server systemd-networkd[812]: eno1: Gained carrier
Nov 02 10:16:22 server systemd-networkd[812]: eno1: DHCPv4 client: disabled
Nov 02 10:16:22 server systemd-networkd[812]: eno1: Setting addresses
Nov 02 10:16:22 server systemd-networkd[812]: eno1: Setting routes
Nov 02 10:16:22 server systemd-networkd[812]: eno1: Configured

Signification : Vous pouvez voir si networkd a appliqué une config statique, tenté DHCP, échoué à définir des routes, etc.
Décision : Toutes erreurs ici contredisent vos hypothèses. Corrigez le problème journalisé plutôt que de réécrire le YAML au hasard.

Task 10: Vérifier si cloud-init contrôle le réseau sur cet hôte

cr0x@server:~$ sudo cloud-init status --long
status: done
boot_status_code: enabled-by-generator
detail:
  DataSource: DataSourceNoCloud [seed=/var/lib/cloud/seed/nocloud-net]
  errors: []

Signification : Cloud-init a exécuté et a une datasource ; il peut aussi gérer la configuration réseau selon sa config.
Décision : Si vous voyez cloud-init et un 50-cloud-init.yaml, supposez qu’il peut écraser votre travail au prochain boot. Décidez s’il faut désactiver la gestion réseau de cloud-init ou fournir la bonne config réseau à cloud-init.

Task 11: Voir si cloud-init a écrit des YAML Netplan récemment

cr0x@server:~$ sudo journalctl -u cloud-init -b --no-pager | grep -i netplan | tail -n 20
Nov 02 10:10:03 server cloud-init[601]: Generating network configuration from datasource
Nov 02 10:10:03 server cloud-init[601]: Writing to /etc/netplan/50-cloud-init.yaml
Nov 02 10:10:04 server cloud-init[601]: Running command ['netplan', 'generate']

Signification : C’est l’arme du crime. Si cloud-init écrit ce fichier, vos modifications manuelles peuvent être écrasées au démarrage.
Décision : Soit empêchez cloud-init de gérer le réseau, soit faites vos changements via la configuration réseau de cloud-init pour qu’il écrive l’état désiré.

Task 12: Confirmer permissions/ownership des fichiers (Netplan ignore les fichiers non sûrs)

cr0x@server:~$ sudo stat -c '%A %U:%G %n' /etc/netplan/*.yaml
-rw------- root:root /etc/netplan/00-installer-config.yaml
-rw-r--r-- root:root /etc/netplan/50-cloud-init.yaml

Signification : Netplan attend des configs possédées par root et non modifiables par groupe/tous. Des modes trop permissifs peuvent faire ignorer le fichier.
Décision : Si vous voyez group-writable ou world-writable, corrigez les perms et relancez generate/apply.

Task 13: Appliquer en toute sécurité avec rollback (compatible remote)

cr0x@server:~$ sudo netplan try
Do you want to keep these settings?

Press ENTER before the timeout to accept the new configuration

Changes will revert in 120 seconds

Signification : Netplan met en scène un changement et reviendra en arrière si vous perdez la connectivité ou si vous ne confirmez pas.
Décision : Utilisez ceci quand vous êtes en SSH et que vous tenez à votre temps. Si ça n’arrive pas à monter le lien, le revert se fera automatiquement — puis vous déboguez sans un long trajet jusqu’au datacenter.

Task 14: Si le DNS « ne s’applique pas », inspecter l’état résolu (pas seulement resolv.conf)

cr0x@server:~$ resolvectl status
Global
         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub
Current DNS Server: 10.20.0.53
       DNS Servers: 10.20.0.53 10.20.0.54

Signification : systemd-resolved est en charge et connaît vos serveurs DNS prévus.
Décision : Si Netplan affiche un DNS mais que resolvectl en affiche un autre, le renderer (ou NM) peut pousser le DNS différemment. Décidez qui possède le DNS et configurez correctement cette couche.

Task 15: Confirmer que le nom d’interface correspond vraiment à ce que vous avez configuré

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00
eno1             UP             52:54:00:12:34:56
enp6s0           DOWN           52:54:00:aa:bb:cc

Signification : Les noms d’interface prévisibles existent pour réduire l’ambiguïté, mais ça pique encore lors de changements de template VM ou de reorder de NIC.
Décision : Si vous avez configuré ens3 mais que le système a eno1, votre YAML est un beau poème que personne ne lit. Corrigez le nom de match.

Cloud-init : le réécrivain silencieux de configuration

Cloud-init existe pour rendre les images portables : démarrer partout, découvrir des metadata, configurer le réseau, injecter des clés SSH, et généralement faire les choses que vous ne voulez pas intégrer dans une image dorée.
Le problème, c’est qu’une fois qu’une machine n’est plus « éphémère », l’aide de cloud-init devient indiscernable du sabotage.

Sur les images cloud Ubuntu 24.04, il est courant de trouver /etc/netplan/50-cloud-init.yaml. Ce fichier n’est pas sacré.
Il est généré. Et selon votre configuration cloud-init et la datasource, il peut être régénéré au démarrage.
Si vous l’éditez manuellement, vous négociez avec un système automatisé qui ne dort jamais et ne lit pas vos commentaires de ticket.

Comment savoir si cloud-init va écraser le réseau

Le signe le plus rapide est des entrées de log montrant qu’il écrit 50-cloud-init.yaml.
Le second signe est que vos changements « fonctionnent jusqu’au redémarrage ».
Le troisième signe est que votre gestion de configuration « perd sans cesse », même si le fichier YAML sur disque semble correct immédiatement après l’exécution de votre automatisation.

Pour que ça tienne : choisissez une de ces stratégies

1. Désactiver la gestion réseau de cloud-init sur les hôtes longue durée.
   C’est courant dans les datacenters privés où les metadata d’instance ne sont pas la source de vérité.
2. Fournir à cloud-init la configuration réseau désirée afin qu’il génère le bon YAML Netplan.
   C’est préférable lorsque vous voulez réellement la portabilité cloud et un comportement premier-démarrage cohérent.
3. Changer l’ordre des fichiers Netplan pour que votre fichier gagne (par ex. 99-local.yaml), mais seulement si vous êtes sûr que cloud-init ne régénère pas d’autres clés dont vous dépendez.
   C’est une correction tactique. Ce n’est pas une architecture propre.

Blague n°2 : Cloud-init est comme un collègue bien intentionné qui a « corrigé » votre tableur en le triant — techniquement correct, opérationnellement catastrophique.

Désactiver la gestion réseau de cloud-init (avec précaution)

Si la machine n’est plus destinée à être configurée dynamiquement par des metadata, désactivez explicitement cette fonctionnalité de cloud-init.
Le mécanisme exact peut varier selon l’environnement, mais l’objectif est le même : cloud-init doit cesser de générer et d’appliquer la configuration réseau.

Après avoir modifié les paramètres de cloud-init, redémarrez ou relancez uniquement les étapes cloud-init pertinentes si vous comprenez l’impact. En production, privilégiez une fenêtre de redémarrage contrôlée et l’accès console.

Guerres de renderer : NetworkManager vs systemd-networkd

Netplan peut cibler plusieurs renderers. Les deux que vous rencontrerez en pratique sont systemd-networkd et NetworkManager.
Votre travail n’est pas de choisir le « meilleur » en abstrait. Votre travail est de vous assurer qu’exactement l’un d’eux possède chaque interface, de manière prévisible.

systemd-networkd : ennuyeux, déterministe, adapté aux serveurs

networkd est généralement préféré sur les serveurs sans interface graphique parce qu’il est simple, s’intègre avec systemd, et fait moins de choses « utiles ».
Quand vous déclarez des IP statiques, des routes et du DNS dans Netplan avec renderer: networkd, vous visez habituellement ce comportement.

NetworkManager : flexible, convivial, et parfois trop malin

NM brille sur les postes, le Wi‑Fi, les VPN et les environnements multi-réseaux dynamiques.
Il apparaît aussi sur des serveurs quand des équipes standardisent sur nmcli et veulent un comportement identique sur toute la flotte.
C’est bien — jusqu’à ce que quelqu’un édite Netplan en supposant networkd, alors que NM gère activement la NIC.

La règle qui évite 80% des incidents « Netplan ne s’est pas appliqué »

Choisissez un renderer par hôte (ou au moins par interface), et faites-le respecter.
Le mélange est possible, mais vous devez avoir une raison, une documentation et des tests. Sinon ce n’est que de l’entropie en YAML.

Pièges YAML, permissions, et pourquoi « valide » n’est pas suffisant

YAML est amical comme un couteau à beurre : il ne vous poignardera pas, mais il peut quand même vous gâcher la journée si vous le traitez comme une cuillère.
Avec Netplan, les pièges classiques sont subtils : mauvaise indentation, mauvaise clé placée, clés dépréciées, et fichiers que Netplan ignore silencieusement pour des raisons de sécurité.

Ordre lexical : le mécanisme d’override silencieux

Netplan lit /etc/netplan/*.yaml par ordre lexical. Si deux fichiers définissent la même interface, les fichiers ultérieurs peuvent écraser les déclarations précédentes.
C’est à la fois une fonctionnalité et une source de « je jure que je l’ai changé. »

L’approche pragmatique pour des overrides locaux (quand vous devez le faire) est un fichier de queue clairement nommé comme 99-local.yaml.
Mais si vous utilisez de l’automatisation, préférez un fichier unique autoritatif plutôt qu’une pile d’overrides dont personne ne se souvient.

Permissions : Netplan ne fera pas confiance à une config modifiable

Si quelqu’un a rendu les YAML Netplan modifiables par le groupe pour « aider l’équipe », il a accidentellement créé une faiblesse de sécurité.
Netplan atténue cela en ignorant les configs non sûres. Le résultat ressemble à : « apply n’a rien fait », avec un côté confusion.

Clés dépréciées et sémantiques changées

Netplan a évolué. Certaines clés qui marchaient dans d’anciens exemples peuvent être dépréciées ou déconseillées. Dans Netplan moderne, utiliser explicitement routes est souvent préféré aux anciens raccourcis passerelle dans des configurations complexes.
La solution n’est pas de mémoriser chaque changement — c’est d’utiliser netplan --debug generate et d’inspecter les configs générées.

Routes, DNS, et « ça s’est appliqué mais ça ne marche toujours pas »

La catégorie la plus frustrante est quand Netplan a réellement appliqué votre config — l’adresse IP est correcte, le lien est up — mais le système ne peut toujours pas accéder à ce dont il a besoin.
Ce n’est pas un échec de Netplan ; c’est que votre intention réseau est incomplète.

Conflits de route par défaut

Les serveurs multi-NIC sont courants maintenant : une interface pour la gestion, une pour le stockage, une pour le trafic frontal, parfois des overlays ou des VPN.
Si deux interfaces proposent une route par défaut (via DHCP ou routes statiques), Linux en choisira une selon les métriques et le timing.
Cela peut ressembler à une « connectivité aléatoire », surtout après des reboots.

La solution est d’être explicite : définissez quelle interface possède la route par défaut, et envisagez d’utiliser des métriques de route ou du routage par politique si votre conception nécessite plusieurs uplinks.

Problèmes d’empilement DNS

Les gens considèrent encore le DNS comme « un fichier à /etc/resolv.conf ». Sur Ubuntu 24.04, cette mentalité vous fait perdre une heure.
Souvent /etc/resolv.conf est un stub pointant vers systemd-resolved. NetworkManager peut aussi injecter du DNS.
Netplan peut définir des serveurs DNS, mais le comportement final dépend du renderer et de la pile de résolveur.

Diagnostiquez avec resolvectl. Puis décidez qui possède le DNS : networkd+resolved, NetworkManager, ou un résolveur dédié. Faites-en un chemin autoritatif.

Trois mini-histoires d’entreprise depuis le terrain

1) Incident causé par une mauvaise hypothèse : « Netplan est le gestionnaire réseau »

Une équipe a hérité d’une flotte de serveurs Ubuntu « utilisant Netplan ». Ils ont voulu déplacer un VLAN de service et ont décidé de mettre à jour un bloc IP statique.
La demande de changement était simple : éditer le YAML, exécuter netplan apply, vérifier. Ils ont fait exactement cela.

Sur la moitié des hôtes, rien n’a changé. Sur l’autre moitié, ça a changé puis a été revert après reboot lors d’une maintenance coordonnée.
L’équipe a supposé que « netplan apply est cassé en 24.04 », parce que c’est le seul outil visible qu’ils touchaient.

L’analyse post-incident était embarrassante de simplicité : les hôtes étaient un mélange d’installations.
Certains utilisaient renderer: networkd. D’autres avaient NetworkManager installé et gérant les NICs suite à un travail antérieur de « standardisation ».
Et les images dérivées du cloud avaient cloud-init générant 50-cloud-init.yaml.

La remédiation n’a pas été de l’ingénierie héroïque. Ce fut de la gouvernance : choisir un renderer par rôle d’hôte, retirer l’autre gestionnaire si approprié, désactiver la gestion réseau de cloud-init sur les nœuds longue durée, et ajouter un contrôle CI pour échouer si plusieurs fichiers netplan définissent la même interface.
La maintenance suivante s’est déroulée en silence. Ce qui est la meilleure des choses.

2) Optimisation qui a mal tourné : « Utilisons cloud-init pour accélérer le provisioning, pour toujours »

Une autre organisation a misé sur un provisioning rapide. Ils ont utilisé le réseau de cloud-init non seulement au premier démarrage, mais comme « source de vérité » permanente pour la config réseau.
Ça fonctionnait bien tant que chaque instance était éphémère. Puis ils ont commencé à garder certains nœuds plusieurs mois parce que la gravité des données existe.

Un changement réseau est survenu : rotation des serveurs DNS, routes modifiées, et un nouveau MTU requis pour un overlay. L’automatisation a mis à jour le YAML Netplan directement dans /etc/netplan.
Ça semblait correct sur disque, mais au redémarrage ça revenait en arrière. Parfois seules des parties revenaient — comme le DNS — créant un amusant split-brain où la connectivité fonctionnait à moitié.

L’« optimisation » voulait que cloud-init garde toujours le réseau aligné sur les metadata. En pratique, metadata et réalité ont divergé : certaines instances avaient des metadata obsolètes, d’autres n’en avaient pas, et certaines avaient une datasource personnalisée.
Cloud-init appliquait fidèlement des absurdités.

Ils l’ont corrigé en changeant la cible d’optimisation. Plutôt que « laisser cloud-init posséder le réseau toujours », ils ont fait du premier démarrage la frontière :
cloud-init configure le réseau une fois, puis la possession du réseau passe au système de gestion de configuration. Ils ont aussi ajouté une garde : si cloud-init tente de réécrire Netplan après le premier démarrage, il logge bruyamment et échoue le pipeline de déploiement.
Le provisioning est resté rapide, mais les opérations ont cessé d’être un jeu de suppositions.

3) Pratique ennuyeuse mais correcte qui a sauvé la mise : netplan try + accès console + déploiement par étapes

Une entreprise devait renuméroter une gestion IP sur un large environnement. Les changements étaient routiniers mais risqués : on ne peut pas réparer un serveur verrouillé par SSH.
Le SRE lead a insisté sur trois pratiques « ennuyeuses » : toujours utiliser netplan try pour les changements à distance, toujours avoir l’accès console hors bande testé au préalable, et déployer par petits paquets.

Le premier lot a révélé un décalage subtil : certaines NICs avaient été renommées suite à un refresh matériel, donc la config Netplan ciblait le mauvais nom d’interface.
Sur ces nœuds, netplan try a échoué à établir la connectivité et a rollbacké automatiquement.
Ce rollback a économisé du temps et empêché une pile de sessions console d’urgence.

Parce que le déploiement était par étapes, ils ont ajusté le mapping d’inventaire, régénéré le YAML avec les bons noms d’interface, et ont continué.
Pas d’incident majeur. Pas d’héroïsme. Juste le type de processus qui ne gagne jamais de prix mais garde les systèmes disponibles.

La leçon n’était pas « netplan try est sympa. » La leçon est que des mécanismes de rollback déterministes et des déploiements par étapes sont des fonctionnalités de fiabilité, pas une cérémonie optionnelle.

Erreurs courantes : symptômes → cause racine → correctif

1) « J’ai édité le YAML et rien n’est arrivé »

Symptôme : netplan apply renvoie sans erreurs ; l’IP reste inchangée.
Cause racine : Vous avez édité un fichier qui est écrasé par un autre YAML (ordre lexical), ou Netplan a ignoré le fichier à cause de permissions non sûres.
Correctif : Lancez sudo netplan get pour confirmer la config fusionnée ; assurez-vous de la propriété root et de permissions sûres ; consolidez en un fichier autoritatif ou déplacez votre override en 99-local.yaml.

2) « Ça marche jusqu’au reboot, puis ça revient en arrière »

Symptôme : Correct après apply ; incorrect après redémarrage.
Cause racine : cloud-init réécrit 50-cloud-init.yaml ou relance la génération réseau au boot.
Correctif : Empêchez cloud-init de gérer le réseau sur ce rôle d’hôte, ou intégrez l’intent réseau dans la configuration cloud-init pour qu’il génère le YAML correct à chaque boot (si c’est vraiment voulu).

3) « Netplan affiche networkd mais NM est réellement connecté »

Symptôme : YAML déclare renderer: networkd, mais nmcli dev status montre connected sur la NIC.
Cause racine : Mismatch de renderer ; NetworkManager gère l’interface et peut écraser adresses/DNS/routes.
Correctif : Décidez de la propriété. Soit basculez Netplan sur renderer: NetworkManager (et gérez via NM), soit configurez NM pour ne pas gérer ce périphérique et utilisez networkd de façon cohérente.

4) « IP appliquée mais pas d’internet / pas de route »

Symptôme : L’interface a la bonne adresse ; impossible de joindre au-delà du sous-réseau.
Cause racine : Route par défaut manquante, mauvaise passerelle, ou routes par défaut concurrentes sur une autre interface.
Correctif : Utilisez ip route show. Définissez la route par défaut explicitement sous routes:, ajustez les métriques, et assurez-vous qu’il n’y ait qu’une seule route par défaut voulue (sauf si vous faites du routage par politique volontairement).

5) « Le DNS ne change pas »

Symptôme : Le YAML liste des serveurs DNS ; /etc/resolv.conf montre autre chose.
Cause racine : Stub systemd-resolved, injection DNS par NM, ou empilement de résolveurs au-dessus de Netplan.
Correctif : Vérifiez resolvectl status et décidez du propriétaire DNS. Alignez le renderer Netplan avec ce propriétaire ; n’éditez pas manuellement /etc/resolv.conf en espérant que ça persiste.

6) « netplan apply casse mon SSH »

Symptôme : L’apply coupe la connexion ; le système peut ou non récupérer.
Cause racine : Changements distants appliqués sans rollback ; mauvais nom d’interface ; suppression accidentelle d’adresses/routes.
Correctif : Utilisez netplan try. Assurez l’accès console. Faites les changements de manière incrémentale : adresse d’abord, route ensuite, DNS en dernier.

Listes de vérification / plan pas-à-pas

Checklist A : Faire tenir les changements Netplan sur un serveur longue durée

1. Lister les fichiers YAML Netplan : identifier overrides et fichiers générés (ls -l /etc/netplan).
2. Confirmer l’intention fusionnée (sudo netplan get). Si ce n’est pas ce que vous attendez, arrêtez-vous.
3. Vérifier la propriété du renderer : networkctl status IFACE et nmcli dev status.
4. Vérifier la propriété cloud-init : cloud-init status --long, logs d’écriture Netplan YAML.
5. Décider du modèle d’autorité :
   • Cloud-init possède le premier démarrage, puis CM le gère ; ou
   • Cloud-init possède le réseau toujours (rarement sage pour les nœuds longue durée) ; ou
   • Pas de réseau cloud-init, jamais (commun sur bare metal).
6. Consolider le YAML en un fichier par rôle d’hôte quand c’est possible.
7. Fixer des permissions sûres : possédé par root, pas modifiable par groupe/others.
8. Lancer sudo netplan --debug generate et inspecter la config backend générée.
9. Appliquer avec sudo netplan try si vous êtes à distance.
10. Valider avec ip -br addr, ip route, et resolvectl.

Checklist B : Séquence de changement sûre pour une migration d’IP statique

1. Confirmer les noms d’interface et les MACs correspondent à votre inventaire (ip -br link).
2. Ajouter la nouvelle IP en secondaire (si votre environnement le permet) avant de retirer l’ancienne IP, pour éviter une coupure.
3. Mettre à jour les routes, vérifier la connectivité vers la passerelle et les réseaux suivants.
4. Mettre à jour le DNS en dernier, car une panne DNS est confuse et ressemble à un problème de routage.
5. Planifier un test de reboot pour vérifier la persistance une fois les changements stables.

Checklist C : Quand vous suspectez des conflits (NM vs networkd vs cloud-init)

1. Prouver qui possède l’interface (networkctl et nmcli).
2. Prouver qui écrit les YAML Netplan (logs cloud-init, logs CM, mtimes des fichiers).
3. Prouver ce que Netplan a généré (/run/systemd/network/ ou profils de connexion NM selon le renderer).
4. Retirer ou désactiver le côté perdant. La coexistence partielle est la cause des échecs intermittents.

FAQ

1) Pourquoi netplan apply réussit mais rien ne change ?

Parce que Netplan peut parser et générer des configs, mais le backend peut ne pas gérer cette interface, ou un autre YAML l’écrase.
Confirmez avec netplan get, puis vérifiez networkctl/nmcli, puis inspectez les fichiers générés.

2) Quel fichier modifier : 00-installer-config.yaml ou 50-cloud-init.yaml ?

Aucun par défaut. Éditez le fichier qui est autoritatif pour le modèle de propriété de votre hôte.
Si cloud-init écrit 50-cloud-init.yaml au boot, les modifications manuelles là-bas sont une illusion temporaire.
Préférez un fichier stable unique géré par votre système de configuration, ou fournissez à cloud-init la configuration réseau correcte.

3) Comment savoir quel renderer j’utilise ?

Ne vous fiez pas à la mémoire. Utilisez netplan get pour le renderer déclaré, et vérifiez le contrôle réel avec networkctl status IFACE et nmcli dev status.
Le propriétaire de l’interface est ce qui compte.

4) Puis-je mixer NetworkManager et systemd-networkd sur le même hôte ?

Vous pouvez, mais vous ne devriez probablement pas à moins d’avoir une raison claire et des tests.
La propriété mixte augmente les risques de confusion de route/DNS et de comportements « appliqué mais revert ».
Si vous mixez, assurez-vous que chaque interface est clairement gérée par un seul service.

5) Pourquoi le DNS dans Netplan ne correspond pas à /etc/resolv.conf ?

Parce que /etc/resolv.conf est souvent un stub ou un lien symbolique vers systemd-resolved, et NetworkManager peut injecter du DNS aussi.
Utilisez resolvectl status pour voir les résolveurs effectifs, puis alignez votre renderer et votre pile de résolveur.

6) netplan try est-il sûr à utiliser via SSH ?

Oui — c’est l’idée. Il applique les changements avec un rollback si vous ne confirmez pas dans le délai imparti.
Ce n’est pas magique, mais c’est la différence entre un changement contrôlé et un trajet non planifié vers l’accès console.

7) Pourquoi mes changements reviennent seulement parfois ?

Parce que plusieurs systèmes courent en concurrence : renouvellements DHCP, autoconnect de NetworkManager, étapes boot de cloud-init, ou automatisation qui réapplique.
Le comportement intermittent est la marque d’une propriété conflictuelle. Identifiez l’écrivain et supprimez le conflit.

8) Où Netplan écrit-il la configuration générée ?

Pour networkd, couramment sous /run/systemd/network/ en tant que 10-netplan-*.network.
Pour NetworkManager, il traduit en profils de connexion NM (gérés par NM). Les artefacts exacts dépendent du renderer, donc inspectez ce qui est présent et actif sur le système.

9) Quelle est la méthode la plus sûre pour assurer la persistance au redémarrage ?

Assurez une source unique de vérité : un fichier YAML Netplan géré par root et votre automatisation, un renderer unique possédant l’interface, et cloud-init réseau soit désactivé soit correctement configuré.
Ensuite redémarrez pendant une fenêtre de maintenance et vérifiez l’état runtime.

10) Dois-je éditer à la main les fichiers générés sous /run/systemd/network/ ?

Non, pas comme correctif. Ces fichiers sont éphémères et seront régénérés.
Éditez le YAML Netplan (ou l’entrée cloud-init) afin que la sortie générée soit correcte.
La seule fois où éditer les fichiers générés a un sens est comme expérimentation diagnostique temporaire quand vous comprenez que vous sortez du système.

Conclusion : prochaines étapes qui ne vous réveilleront pas la nuit

Quand les changements Netplan ne s’appliquent pas sur Ubuntu 24.04, le système fait généralement exactement ce qu’on lui a demandé — juste pas vous, et pas dans la couche que vous éditez.
La solution est rarement « réessayer ». La solution est d’établir la propriété et de rendre la chaîne de configuration ennuyeuse.

Faites ceci ensuite, dans l’ordre :

1. Exécutez sudo netplan get et confirmez que votre intention est bien dans la config fusionnée.
2. Confirmez la propriété de l’interface avec networkctl et nmcli ; choisissez un renderer et faites-le respecter.
3. Vérifiez si cloud-init réécrit et décidez si cloud-init doit posséder le réseau sur cet hôte.
4. Inspectez la config backend générée sous /run pour prouver ce qui sera appliqué.
5. Utilisez netplan try pour les changements à distance, puis validez avec ip/resolvectl.

Rendez-le déterministe. Rendez-le testable. Faites en sorte que la prochaine personne de garde n’ait pas à apprendre votre infrastructure en lisant des journaux à 03:00.