Tout un parc de VMs versionné, avec un pipeline qui vérifie des signatures et se redéploie tout seul toutes les 30 minutes. Et puis deux ou trois machines, en dehors de ce système, dont l'état ne vit que sur elles-mêmes. Ce post parle d'un cas que j'observe régulièrement, et rarement documenté honnêtement : la dette technique qui s'accumule sur les exceptions au système qu'on a soi-même construit.
Un parc d'une dizaine de VMs qui se déploient elles-mêmes via ansible-pull toutes les 30 minutes. De temps en temps, l'une d'elles arrête de converger, bloquée sur une erreur gpg: waiting for lock ou SQL library used incorrectly. La cause : une tâche qui importait une clé GPG dont plus rien ne se servait, quelque part dans un rôle partagé exécuté par toutes les VMs.
Déployer un parc de VMs sans serveur central qui pousse la configuration, sans coffre-fort de secrets exposé en permanence, et avec une question simple posée à chaque cycle : "est-ce que ce que je m'apprête à exécuter a été signé par quelqu'un d'autorisé ?" Ce post décrit l'architecture GitOps pull-based que j'ai mise en place autour de cette question, et pourquoi elle réduit mécaniquement la surface d'attaque comparée à un modèle push classique.
