Runbook VPS production

Ce runbook décrit l'ordre général pour intervenir sur la production Rilindra hébergée sur le VPS.

Il sert de garde-fou pour éviter les actions dangereuses faites dans le mauvais ordre.

Environnements

Environnement	Branche	Domaines	Usage
Staging	dev	dev-staff.rilindra.fr, dev-commu.rilindra.fr	Validation avant prod
Production	main	staff.rilindra.fr, commu.rilindra.fr	Services officiels

Services critiques

Service	Production
Staff Manager	staff-rilindra-prod
Commu Rilindra	commu-rilindra-prod
Bot Discord	bot-rilindra-prod
Base PostgreSQL	rilindra-db-prod
Stockage images	MinIO partagé, API cdn.redious.fr
Secrets	Infisical
Orchestration	Coolify
DNS	Cloudflare
Monitoring	Uptime Kuma

Avant toute action prod

1. Confirmer le service touché.
2. Confirmer que staging est sain si la même action a été testée en staging.
3. Lire les logs récents.
4. Identifier le dernier commit déployé.
5. Vérifier qu'un backup existe si l'action touche la DB.
6. Prévenir le staff si une indisponibilité est prévue.

Déployer une application prod

1. Merger dev vers main après validation.
2. Attendre le workflow GitHub.
3. Vérifier Coolify.
4. Vérifier que l'image prod contient le SHA attendu.
5. Vérifier le domaine prod.
6. Lire les logs 10 minutes.
7. Tester le parcours métier minimal.

Migration DB prod

La DB staging n'est pas copiée vers la prod.

Principe :

Staging valide le schema et le code.
Prod reçoit les mêmes migrations SQL, après backup.

Ordre strict :

1. code prod déployé ;
2. image prod vérifiée ;
3. backup DB prod ;
4. backup des fonctions SQL si elles sont touchées ;
5. migration SQL ;
6. db:migrate no-op ;
7. test SQL ciblé ;
8. test UI prod ;
9. surveillance logs.

Backup DB prod

Avant une migration ou une action destructive :

docker exec <db-prod-container> pg_dump -U postgres -d rilindra_db -Fc \
  > ~/backups/rilindra_db_prod_$(date -u +%Y%m%dT%H%M%SZ).dump

Vérifier la lisibilité :

pg_restore -l ~/backups/<dump>.dump | head -n 20

Test UI prod minimal

Après une migration Staff Manager :

1. se connecter sur https://staff.rilindra.fr ;
2. ouvrir /tasks ;
3. valider puis dévalider une tâche non critique ;
4. ouvrir /users ;
5. ouvrir /encheres ;
6. ouvrir /vip ;
7. ouvrir /admin/bot ;
8. vérifier les logs.

Rollback

Un rollback dépend du type d'action.

Action	Rollback possible
Déploiement app	Revenir à l'ancien commit ou redéployer l'image précédente
Migration DB	Restaurer le dump, après décision explicite
Variable Infisical	Restaurer l'ancienne valeur connue
DNS Cloudflare	Revenir à l'ancien record
Bot Discord	Redémarrer l'ancien conteneur ou corriger la variable fautive

Ne jamais restaurer une DB prod sans confirmer l'impact sur les écritures réalisées après le backup.

Validation finale

Une intervention prod est terminée seulement si :

• service healthy ;
• domaine accessible ;
• parcours métier minimal OK ;
• logs propres ;
• monitoring OK ;
• staff prévenu si nécessaire ;
• documentation mise à jour si la procédure a changé.