Étude de cas 02 / 05
Infrastructure gangnant.fr
29 services décrits comme du code
En production
- services versionnés
- 29
- interruption à la mise à jour
- 0
- commande de déploiement
- 1
- Étape du pipeline
- Retour arrière
- Service drainé
Étude de cas détaillée
01 — Contexte
La situation de départ
Un serveur héberge DNS, messagerie, sites web, proxy et supervision — et rien n’était documenté ailleurs que dans ma tête.
02 — Problème
Ce qui coinçait
Reconstruire un service demandait de connaître par cœur son histoire : dépendances, variables, ordre de démarrage, plan de reprise. Cette knowledge était uniquement dans ma tête, donc elle disparaissait avec moi. Les mises à jour manuelles provoquaient des interruptions de service imprévisibles.
03 — Solution
Ce que j’ai mis en place
- Chaque service vit dans son propre dossier versionné, avec son fichier docker-compose.
- Déploiement scripté : reconstruction d’image, bascule blue/green, rechargement de Nginx.
- Reverse proxy Nginx partagé, certificats ACME renouvelés automatiquement.
- Pipelines GitLab CI et scripts de déploiement idempotents.
- Documentation d'accueil destinée aux humains comme aux agents d'IA.
04 — Résultat
Ce que ça change
- Rejouer un déploiement ne casse rien : les scripts sont idempotents par conception.
- Le code source du serveur est lisible par quelqu’un qui n’a jamais touché à la machine.
- Les interruptions de service liées aux mises à jour ont disparu.
Stack technique
- Docker
- Docker Compose
- Nginx
- GitLab CI
- Bash
- ACME