chore(release): v0.961 — Playbook (runbooks déploiement, rollback, incident)
This commit is contained in:
parent
65375a61aa
commit
f692ebfd26
5 changed files with 189 additions and 0 deletions
50
docs/runbooks/DEPLOYMENT.md
Normal file
50
docs/runbooks/DEPLOYMENT.md
Normal file
|
|
@ -0,0 +1,50 @@
|
|||
# Runbook — Déploiement
|
||||
|
||||
## Prérequis
|
||||
|
||||
- Accès au registry Docker
|
||||
- Variables d'environnement configurées (voir `.env.example`)
|
||||
- Base de données migrée
|
||||
|
||||
## Étapes
|
||||
|
||||
### 1. Build images
|
||||
|
||||
```bash
|
||||
docker build -t veza/backend-api:${VERSION} -f veza-backend-api/Dockerfile .
|
||||
docker build -t veza/stream-server:${VERSION} -f veza-stream-server/Dockerfile .
|
||||
docker build -t veza/web:${VERSION} -f apps/web/Dockerfile .
|
||||
```
|
||||
|
||||
### 2. Push images
|
||||
|
||||
```bash
|
||||
docker push veza/backend-api:${VERSION}
|
||||
docker push veza/stream-server:${VERSION}
|
||||
docker push veza/web:${VERSION}
|
||||
```
|
||||
|
||||
### 3. Migrations
|
||||
|
||||
```bash
|
||||
cd veza-backend-api
|
||||
DATABASE_URL=postgres://... make migrate
|
||||
```
|
||||
|
||||
### 4. Deploy
|
||||
|
||||
Suivant l'orchestrateur (Kubernetes, Docker Compose, etc.) :
|
||||
|
||||
- Mettre à jour les images dans les manifests
|
||||
- Appliquer : `kubectl apply -f k8s/` ou `docker-compose up -d`
|
||||
|
||||
### 5. Vérification
|
||||
|
||||
```bash
|
||||
curl -s https://api.example.com/health | jq
|
||||
curl -s https://api.example.com/health/deep | jq
|
||||
```
|
||||
|
||||
### 6. Rollback
|
||||
|
||||
En cas de problème : voir [ROLLBACK.md](ROLLBACK.md).
|
||||
27
docs/runbooks/GRACEFUL_DEGRADATION.md
Normal file
27
docs/runbooks/GRACEFUL_DEGRADATION.md
Normal file
|
|
@ -0,0 +1,27 @@
|
|||
# Runbook — Graceful Degradation
|
||||
|
||||
## Comportement quand Redis est down
|
||||
|
||||
| Fonctionnalité | Comportement |
|
||||
|---------------------|---------------------------------------|
|
||||
| Rate limiting | Fallback in-memory (par instance) |
|
||||
| CSRF | Désactivé ou 503 si strict |
|
||||
| Sessions | Échec login / refresh |
|
||||
| Cache | Cache miss systématique |
|
||||
|
||||
L’API reste opérationnelle pour les requêtes qui ne dépendent pas de Redis. Les routes protégées peuvent échouer si les sessions sont en Redis.
|
||||
|
||||
## Comportement quand RabbitMQ est down
|
||||
|
||||
- Les jobs asynchrones (transcode, notifications, etc.) ne sont pas traités
|
||||
- Les requêtes synchrones restent fonctionnelles
|
||||
|
||||
## Comportement quand S3/MinIO est down
|
||||
|
||||
- Upload de fichiers : échec
|
||||
- Lecture de fichiers stockés : échec
|
||||
- Le reste de l’API fonctionne
|
||||
|
||||
## Health /health/deep
|
||||
|
||||
Le endpoint `/health/deep` indique l’état de chaque dépendance (DB, Redis, RabbitMQ, S3, disk). Utiliser ce diagnostic pour identifier la dégradation.
|
||||
39
docs/runbooks/INCIDENT_RESPONSE.md
Normal file
39
docs/runbooks/INCIDENT_RESPONSE.md
Normal file
|
|
@ -0,0 +1,39 @@
|
|||
# Runbook — Incident Response
|
||||
|
||||
## API down
|
||||
|
||||
1. Vérifier `GET /health` et `GET /health/deep`
|
||||
2. Consulter les logs : `kubectl logs -l app=veza-backend-api --tail=200`
|
||||
3. Vérifier DB, Redis, RabbitMQ (voir health/deep)
|
||||
4. Redémarrer les pods si crash loop : `kubectl rollout restart deployment/veza-backend-api`
|
||||
5. Rollback image si régression récente : [ROLLBACK.md](ROLLBACK.md)
|
||||
|
||||
## Redis down
|
||||
|
||||
- L’API peut fonctionner en mode dégradé (voir [GRACEFUL_DEGRADATION.md](GRACEFUL_DEGRADATION.md))
|
||||
- Vérifier : `redis-cli ping`
|
||||
- Redémarrer le service Redis ou le pod
|
||||
- Vérifier la persistance (AOF/RDB) si perte de données
|
||||
|
||||
## DB down
|
||||
|
||||
- **Critique** : l’API renvoie 503
|
||||
1. Vérifier la connexion PostgreSQL
|
||||
2. Consulter les logs Postgres
|
||||
3. Vérifier l’espace disque
|
||||
4. Redémarrer Postgres si nécessaire
|
||||
5. Pas de rollback migration automatique sans procédure validée
|
||||
|
||||
## Webhook failed
|
||||
|
||||
1. Consulter les logs du service appelant (ex. Stream server callbacks)
|
||||
2. Vérifier `X-Internal-API-Key` et `STREAM_SERVER_INTERNAL_API_KEY`
|
||||
3. Vérifier que l’URL du webhook est correcte
|
||||
4. Réessayer manuellement si idempotent
|
||||
|
||||
## DDoS / trafic anormal
|
||||
|
||||
1. Activer le rate limiting (Redis requis pour distribué)
|
||||
2. Vérifier les règles WAF / Cloudflare si applicable
|
||||
3. Scaler horizontalement si charge légitime
|
||||
4. Bloquer les IP abusives au niveau load balancer / firewall
|
||||
35
docs/runbooks/ROLLBACK.md
Normal file
35
docs/runbooks/ROLLBACK.md
Normal file
|
|
@ -0,0 +1,35 @@
|
|||
# Runbook — Rollback
|
||||
|
||||
## Rollback image
|
||||
|
||||
### Kubernetes
|
||||
|
||||
```bash
|
||||
kubectl rollout undo deployment/veza-backend-api
|
||||
kubectl rollout undo deployment/veza-stream-server
|
||||
kubectl rollout undo deployment/veza-web
|
||||
```
|
||||
|
||||
### Docker Compose
|
||||
|
||||
```bash
|
||||
docker-compose down
|
||||
# Éditer docker-compose.yml : utiliser l'image de la version précédente
|
||||
docker-compose up -d
|
||||
```
|
||||
|
||||
## Rollback base de données
|
||||
|
||||
**Attention** : Les migrations down ne sont pas systématiques. Voir `docs/MIGRATION_CONSOLIDATION.md`.
|
||||
|
||||
Pour une migration récente, si un fichier `*_down.sql` existe :
|
||||
|
||||
```bash
|
||||
psql $DATABASE_URL -f veza-backend-api/migrations/XXX_migration_down.sql
|
||||
# Retirer la ligne correspondante de schema_migrations
|
||||
psql $DATABASE_URL -c "DELETE FROM schema_migrations WHERE version = 'XXX_migration.sql';"
|
||||
```
|
||||
|
||||
## Switch de trafic
|
||||
|
||||
Avec load balancer / ingress : pointer vers la version précédente des pods/containers avant rollback complet.
|
||||
38
docs/runbooks/SECRET_ROTATION.md
Normal file
38
docs/runbooks/SECRET_ROTATION.md
Normal file
|
|
@ -0,0 +1,38 @@
|
|||
# Runbook — Rotation des secrets
|
||||
|
||||
## JWT_SECRET
|
||||
|
||||
1. Générer un nouveau secret : `openssl rand -base64 32`
|
||||
2. Déployer avec l’ancien et le nouveau (dual-secret) si l’app le supporte
|
||||
3. Sinon : maintenance window
|
||||
- Mettre à jour `JWT_SECRET` dans le déploiement
|
||||
- Redémarrer l’API
|
||||
- Tous les tokens existants sont invalidés (re-login requis)
|
||||
|
||||
## CHAT_JWT_SECRET
|
||||
|
||||
Même procédure que JWT_SECRET. Doit être synchronisé entre backend et chat/stream si partagé.
|
||||
|
||||
## OAUTH_ENCRYPTION_KEY
|
||||
|
||||
Utilisé pour chiffrer les tokens OAuth en DB. Rotation complexe :
|
||||
|
||||
1. Ne pas supprimer l’ancienne clé tant que des tokens chiffrés existent
|
||||
2. Ajouter la nouvelle clé dans la config
|
||||
3. Les nouveaux tokens utilisent la nouvelle clé
|
||||
4. Après expiration des anciens tokens, retirer l’ancienne clé
|
||||
|
||||
## STREAM_SERVER_INTERNAL_API_KEY / INTERNAL_API_KEY
|
||||
|
||||
Doivent correspondre entre backend et stream server.
|
||||
|
||||
1. Générer : `openssl rand -hex 32`
|
||||
2. Mettre à jour les deux côtés quasi-simultanément
|
||||
3. Redémarrer backend et stream server
|
||||
|
||||
## DATABASE_URL
|
||||
|
||||
1. Créer un nouvel utilisateur avec un nouveau mot de passe en DB
|
||||
2. Mettre à jour `DATABASE_URL` dans le déploiement
|
||||
3. Redémarrer l’API
|
||||
4. Révoquer l’ancien utilisateur après validation
|
||||
Loading…
Reference in a new issue