Ce que nous avons trouvé utile dans NixOS
Cette note technique d’implémentation porte sur l’architecture d’infrastructure et de récupération de Curling IO v3. Elle s’adresse aux ingénieurs logiciels et aux responsables de l’exploitation, et aborde NixOS, le provisionnement de serveurs physiques, les secrets, le déploiement, les sauvegardes et la validation de récupération plus en détail que nos articles habituels sur le produit.
Curling IO fonctionnait auparavant sur Debian configuré avec Ansible. Cette installation marchait. Elle installait les paquets, configurait Caddy et le pare-feu, créait les services systemd et préparait nos emplacements de déploiement bleu-vert.
Le problème venait du fait qu’un serveur fonctionnel et modifiable nous permettait de conserver une description incomplète. Ansible pouvait décrire le serveur, mais d’anciens fichiers restaient sous /etc. Des outils de compilation avaient été installés autrement. Les choix du fournisseur sur les disques et le RAID existaient en dehors du playbook. Un provisionnement pouvait réussir parce qu’une exécution antérieure avait déjà laissé le bon élément en place.
NixOS tolère beaucoup moins ces lacunes. Cette rigueur est parfois agaçante, mais constitue aussi son principal avantage. Elle nous oblige à décider qui est responsable d’un fichier, d’un service, d’un secret, d’un paquet ou d’un élément nécessaire à la récupération.
Le passage d’Ansible à NixOS nous a montré combien de validations et de nettoyages manquaient à l’ancienne approche. Il a exposé la différence entre un serveur qui continue de fonctionner et un serveur qu’on peut recréer à partir d’éléments déclarés.
Voici ce que nous avons trouvé utile en reconstruisant un serveur physique OVH à partir de disques vides, en restaurant son état et en rendant le processus assez sûr pour être répété.