flochaiLa migration en échec depuis quatre mois
Toutes les heures, sur un GitLab auto-hébergé, la même migration de fond se réveillait, tentait d'insérer des lignes dans une table qu'une version plus récente devait supprimer, et échouait. Depuis avril. Personne ne regardait, parce que rien de visible n'était cassé. Pas encore.
Comment les instances pourrissent poliment
Les plateformes auto-hébergées échouent rarement bruyamment. Elles accumulent : une montée de version en attente faute d'agenda, une clé de configuration dépréciée renommée deux versions plus tôt, un job de fond qui échoue en boucle sans qu'aucun tableau de bord ne le montre. La nôtre avait les trois. L'instance devait fermer une CVE critique, sa configuration avait dérivé depuis la dernière mise à jour, et elle portait une migration de fond par lots qui échouait, en silence, depuis quatre mois.
Mettre à jour d'abord, la carte ouverte
Une montée de version GitLab est un chemin, pas un saut : nous avons mené l'instance à travers le correctif de CVE, puis jusqu'à l'arrêt obligatoire sur la route de la version courante, en vérifiant zéro migration de schéma en attente à chaque étape. Le paquet a aussi laissé deux petites mines que nous avons désamorcées sur place : des clés nginx dépréciées renommées en amont, et un processus Redis que la mise à jour avait laissé tourner à côté du nouveau.
Diagnostiquer avant de supprimer
La migration bloquée était la partie intéressante. Elle remplissait une table d'archive qu'une version ultérieure supprime entièrement : un travail dont la destination était promise à la démolition. Le geste tentant, c'est de forcer la finalisation et d'espérer. Nous l'avons plutôt tracée, avec le support GitLab, jusqu'à un bug upstream connu des migrations par lots à enregistrement unique, puis vérifié ce qui compte vraiment : restait-il du vrai travail de données ? Zéro ligne sans clé de sharding, les deux contraintes déjà validées. Alors seulement, finalisation depuis la console Rails, avec une seconde migration orpheline trouvée en chemin.
Puis écrire comment survivre
La même intervention a produit le document que l'instance méritait depuis toujours : des sauvegardes horaires donnant un point de reprise d'une heure, des snapshots machine sur une semaine, des copies expédiées hors de l'instance, et deux chemins de restauration répétables, l'un vers une instance de secours, l'autre depuis un snapshot après un dégât destructif. La reprise est passée du savoir tribal à une procédure écrite avec un chiffre dessus.
Ce que ça achète
L'instance est à jour et débloquée pour ses prochaines montées obligatoires, un échec vieux de quatre mois est réglé avec la preuve qu'aucune donnée n'a été perdue, et le prochain mauvais jour a un mode d'emploi. Rien de tout cela n'est glorieux. Tout cela fait la différence entre un incident et un désastre.
Les plateformes vieillissent. Quelqu'un devrait regarder.
Des mises à jour dans la fenêtre de sécurité, des jobs de fond que quelqu'un lit vraiment, et la reprise comme procédure écrite : c'est la moitié ingrate de l'abonnement. Si votre auto-hébergé n'a pas été regardé depuis des mois, c'est le signe.
Contactez-nous