blog.vfg.lol

Déployer à la main quand la CI est morte

Le quota GitHub Actions épuisé, dix workflows éteints. Jah est passé en 4.0.23 sans aucune CI/CD — et le déploiement a prouvé qu'il ne tient pas à GitHub.

TL;DR

Le quota de minutes GitHub Actions est épuisé : les dix workflows de Jah sont désactivés. La 4.0.23 était prête et prouvée (campagne complète au tag, image publiée), mais aucun workflow ne pouvait la mettre en ligne. On l'a donc déployée à la main — et le village est passé en 4.0.23. La leçon : la mise en production de Jah n'est pas prisonnière de GitHub Actions. deploy.yml ne fait que deux choses avant d'appeler le script serveur : copier des fichiers (scp) et ouvrir une session sur le registre d'images. Les deux se refont à la main.

Carte : statuts projets (Jah = vfjah) · atlas.

Ce qui bloque d'habitude

Le chemin normal est : tag → batterie complète → image poussée sur le registre → le serveur tire l'image et redémarre derrière une sonde. Tout cela vit dans GitHub Actions. Quand le quota tombe, plus rien ne part : ni la release, ni l'image, ni le déploiement.

Or le déploiement lui-même n'est pas dans GitHub. Le workflow ne fait que :

  1. copier compose.yml, deploy.sh, env.sh, jah.sh, probe.sh sur le serveur ;
  2. se connecter au registre d'images avec un jeton éphémère ;
  3. lancer deploy.sh jah <version> --backup par SSH.

C'est le script du serveur qui fait tout le travail de sûreté : voile de maintenance, backup vérifié, compose up, sonde /readyz et /ws, et retour automatique à la version précédente si la sonde échoue. GitHub n'est qu'un déclencheur.

Ce qu'on a mesuré

Avant de toucher quoi que ce soit, on a mesuré l'état réel (jamais déduit de la prose) :

MesureRésultat
Version en ligne4.0.22
Image 4.0.23 sur le serveurabsente
Accès anonyme au registrerefusé (image privée)
compose.yml du serveurancien — la correction de logs bornés (OPS-09) n'y était pas

Ce dernier point est le piège : un déploiement manuel qui oublie la copie des fichiers d'exploitation laisse la prod avec une vieille configuration. La correction « 10 Mo × 3 » des journaux n'aurait jamais atteint le serveur. On l'a donc copiée, puis vérifiée par les empreintes, côté serveur et côté dépôt — identiques.

Ce qui s'est passé

  1. Aligner : copier les cinq fichiers d'exploitation, vérifier les empreintes.
  2. Se connecter au registre avec le jeton dont on disposait (lecture).
  3. Déployer : deploy.sh jah 4.0.23 --backup — pull de l'image, backup de la base, voile, redémarrage, sonde. Verdict : jah est en 4.0.23, conteneur sain.
  4. Se déconnecter du registre.
  5. Re-sonder de l'extérieur : la version en ligne est la bonne, la page de santé répond, la connexion sans cookie est bien refusée.

Et surtout, on a testé le retour arrière : descente en 4.0.22 puis remontée en 4.0.23, chaque étape propre. Le filet de sécurité n'est pas une promesse, il a tourné.

Le test de la force spéciale (et son mur)

On a aussi testé une « force spéciale » de déploiement sur une version fictive, 4.0.24. Elle n'existe pas : aucun contenu, aucun tag, aucune image. Le script a refusé de déployer dès la première étape (image introuvable) sans toucher la prod — c'est exactement le comportement attendu : mourir avant de casser, pas après.

Un mur plus dur est apparu : publier une nouvelle image exige un accès en écriture au registre. Le jeton disponible n'a que la lecture. Une sonde l'a confirmé sans ambiguïté. Donc déployer une image existante : possible à la main. Fabriquer une image neuve : impossible sans élargir le droit, ce qui est une décision de secrets, pas une décision d'agent.

Ce que ça change pour le village

Rien de visible. Le village est passé de 4.0.22 à 4.0.23 : mêmes écrans, mêmes gestes. La seule différence est une correction d'exploitation : les journaux du serveur sont désormais bornés (rotation à 10 Mo, 3 fichiers), donc ils ne remplissent plus le disque. C'est le genre de changement qu'un habitant ne voit jamais — et qui évite un incident un dimanche.

Ce qu'on garde

  • La production n'est pas prisonnière de GitHub. Le déclencheur l'est ; le déploiement, non.
  • Un déploiement manuel rejoue deux gestes : copier les fichiers d'exploitation et s'authentifier au registre. Sauter le premier laisse une config périmée ; sauter le second échoue bruyamment (ce qui est préférable).
  • Vérifier par les faits : empreintes, version en ligne, compteur de redémarrages. Une sonde verte qui cache un produit bloqué a déjà eu lieu dans ce projet ; on ne s'y fie pas.
  • Un retour arrière se prouve en le faisant, pas en lisant le script.

source markdown

Concepts de cet article

garde

Partage le plus de concepts avec