Un OS immuable qui se met à jour tout seul

Le problème des hôtes sur lesquels on peut se connecter

La plupart des appliances commencent leur vie propres et pourrissent lentement. Quelqu’un se connecte en SSH pour corriger un problème en production, installe un outil de débogage, édite un fichier de config, et oublie de le noter. Multipliez cela sur un parc et chaque machine devient un flocon de neige : subtilement différente, impossible à reproduire, terrifiante à mettre à niveau.

Les mises à jour d’OS en place aggravent les choses. Une mise à niveau de paquet touche des centaines de fichiers à travers le système en cours d’exécution. Si elle échoue à mi-chemin — un conflit de dépendances, un disque plein, une coupure de courant — vous vous retrouvez dans un état qui n’est ni l’ancienne version ni la nouvelle, et plus personne ne peut dire exactement ce qu’il y a sur la machine. « Ça marche sur ma machine » n’est en réalité que « ma machine a dérivé quelque part d’utile, une fois ».

L’immuable est la solution

Les conceptions d’OS modernes immuables et orientées conteneur adoptent une posture différente : le système de fichiers racine est une image unique, en lecture seule, versionnée. Vous ne la corrigez jamais en place. Pour changer quoi que ce soit, vous construisez une toute nouvelle image et vous y basculez la machine. Le système en cours d’exécution est exactement l’artefact que vous avez construit et signé — ni plus, ni moins.

Cela vous donne trois propriétés gratuitement :

• Reproductible — l’image est une sortie de build. Les mêmes entrées produisent la même racine, octet pour octet.
• Auditable — vous savez précisément ce qui tourne, parce que c’est un artefact versionné plutôt qu’un historique accumulé d’exécutions d’apt.
• Atomique — soit vous démarrez la nouvelle image, soit vous ne la démarrez pas. Il n’y a pas d’état à moitié appliqué.

Comment SiHA s’y prend

SiHA est livré sous la forme d’une seule image racine squashfs en lecture seule, démarrant sous SecureBoot UEFI imposé : un UKI signé (unified kernel image) lancé par un sd-boot signé. La chaîne de démarrage est vérifiée avant même que le noyau ne s’exécute.

Sur l’appliance, il n’y a ni SSH, ni systemd, ni cloud-init. Un minuscule superviseur tourne en tant que PID 1 : il fait l’initialisation de la plateforme — montages, gestion des signaux, seeding — puis lance et supervise le dataplane VPP et les daemons du plan de contrôle. Abandonner l’intergiciel habituel n’est pas qu’une question de propreté ; c’est une surface d’attaque plus réduite. Il n’y a aucun shell à compromettre, aucun gestionnaire de services à mal configurer, et le système de fichiers racine est en lecture seule, si bien qu’il n’y a nulle part où persister un binaire falsifié.

Surface d’attaque réduite, chaîne de démarrage signée, racine en lecture seule. Pour être précis sur la portée : il s’agit d’une chaîne de démarrage signée plus une racine en lecture seule, pas du chiffrement de disque et pas d’un verified-boot complet du contenu de la racine. Ceux-là sont hors périmètre ici — nous ne les revendiquons pas.

Les slots A/B et l’essai à coup unique

L’image réside dans l’un de deux slots, A et B. À tout moment, un slot est actif et en cours d’exécution ; l’autre est inactif.

Une mise à niveau est délibérément ennuyeuse :

1. Écrire la nouvelle image dans le slot inactif. Le système en cours d’exécution n’est jamais touché.
2. Basculer l’entrée du bootloader vers le nouveau slot en tant qu’« essai » à coup unique, avec un compteur de repli armé.
3. Redémarrer.

C’est tout le mécanisme. Si l’étape 3 tourne mal, vous n’avez rien perdu : l’ancien slot, bon connu, est toujours là, intact.

Contrôlé par la santé, avec rollback automatique

L’essai à coup unique est là où SiHA justifie son intérêt. Après que la machine a démarré le nouveau slot, elle exécute ses contrôles de santé. Seul un démarrage sain — un démarrage qui se met en service et se confirme lui-même — est validé comme nouveau défaut.

Si les contrôles échouent, ou que le système ne se confirme jamais du tout (il se fige, panique, ou boucle), le compteur de repli du bootloader expire tout simplement. Au démarrage suivant, le chargeur revient automatiquement au slot bon connu précédent. Aucun opérateur n’a à s’en apercevoir, à se réveiller, ou à intervenir.

Cela inverse le profil de risque habituel d’une mise à jour d’OS. Au lieu de « croisez les doigts et espérez que le correctif s’est appliqué proprement », le pire cas est : la nouvelle version se comporte mal, la machine redémarre une fois, et vous revenez sur la version exacte que vous faisiez tourner auparavant — intouchée, non corrigée, sans surprise.

Les mises à niveau deviennent un non-événement. Au mieux, vous êtes sur le nouveau build. Au pire, vous êtes sur l’ancien, un redémarrage plus tard, sans rien à nettoyer.

Pourquoi cela compte pour une machine dataplane

Un firewall/routeur/répartiteur de charge se trouve sur le chemin de tout. C’est le dernier endroit où vous voulez un hôte flocon de neige ou une mise à jour à moitié appliquée. Pousser le débit de ligne 10 GbE — 14,88 Mpps pour des trames de 64 octets — à travers VPP est déjà assez difficile sans en plus se demander si l’OS en dessous est bien celui que vous avez testé. Une racine immuable plus des mises à niveau A/B contrôlées par la santé signifie que la plateforme sous le dataplane est aussi déclarative et prévisible que la config qui tourne par-dessus.

Vous voulez la vision complète de la manière dont le superviseur, le dataplane et le plan de contrôle s’assemblent ? Consultez la vue d’ensemble de l’architecture.