Registre public de diplômes — Runbook (Site down)¶

Procédure d'urgence

Ce document décrit les étapes à suivre quand diplome.epitech.africa est inaccessible, ou quand la page se charge mais la vérification de diplôme échoue systématiquement. Suivre les étapes dans l'ordre.

Étape 1 : Identifier le problème¶

ssh root@VPS_IP

# Le conteneur tourne ?
docker ps | grep public_diploma_verify
# Si aucun résultat → conteneur arrêté → Étape 2

# Le port répond en local ?
curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1:7015
# Timeout/erreur → Étape 2 ou 3
# 502/504 → Étape 4 (reverse-proxy)
# 200 → Étape 5 (DNS/TLS externe) ou Étape 6 (vérification qui échoue)

Pas de healthcheck Docker

Ce projet n'a pas de healthcheck défini (voir diagnostics.md) — ne pas chercher un statut unhealthy, se fier au STATUS de docker ps (Up / Restarting / Exited).

Étape 2 : Conteneur arrêté — redémarrer¶

cd /root/projects/public-diploma-verify

docker logs public_diploma_verify --tail 50

docker compose up -d

Étape 3 : Conteneur qui redémarre en boucle — diagnostiquer¶

docker logs public_diploma_verify --tail 100

# Causes possibles :
# 1. Port déjà utilisé
lsof -i :7015

# 2. Mémoire insuffisante
free -h
docker stats --no-stream

# Si rien ne fonctionne, recréer le conteneur
docker compose down
docker compose up -d

Ce conteneur est un simple nginx statique (nginx:1.27-alpine) — un crash-loop ici est rare et pointe presque toujours vers un problème d'infra (port, mémoire, disque) plutôt qu'un bug applicatif, puisqu'il n'y a aucune logique serveur à faire planter.

Étape 4 : Problème reverse-proxy (502/504)¶

docker ps | grep nginx-proxy
docker exec nginx-proxy nginx -t
docker exec nginx-proxy tail -20 /var/log/nginx/error.log

# Le conteneur applicatif répond en direct (sans passer par le reverse-proxy) ?
curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1:7015
# 200 → le frontend fonctionne, c'est le reverse-proxy qui ne route pas correctement

docker exec nginx-proxy nginx -s reload

Étape 5 : Frontend OK en local mais site inaccessible depuis l'extérieur¶

dig diplome.epitech.africa
# Doit pointer vers l'IP du VPS de production

curl -vI https://diplome.epitech.africa 2>&1 | grep -i "ssl\|certificate\|expire"

ufw status | grep "80\|443"

Si le domaine ne résout pas ou pointe vers une mauvaise IP, voir continuite-acces-externes.md — le registrar de epitech.africa est Gandi, un domaine distinct de epitools.bj (utilisé par EPIDOCS).

Étape 6 : Le site se charge mais la vérification de diplôme échoue¶

Symptôme : la page d'accueil et la page /EPA-.../ se chargent (nginx répond bien), mais toute recherche affiche « Le service de vérification ne répond pas pour le moment » ou reste bloquée sur l'écran de chargement.

C'est un site 100% statique : il n'y a aucune requête serveur-à-serveur dans ce conteneur. Le problème vient soit de l'API EPIDOCS, soit de l'URL bakée dans le build.

# 1. Vérifier quelle URL backend est réellement bakée dans le build actuel
docker exec public_diploma_verify sh -c \
  "grep -ohE 'https?://[a-zA-Z0-9.-]+(:[0-9]+)?' /usr/share/nginx/html/assets/*.js | sort -u"

# 2. Tester cette URL directement
curl -s -o /dev/null -w "%{http_code}" "https://<backend-trouve>/api/diplomas/verify/EPA-BJ-XX-2025-0001/"
# 404 = l'API répond (matricule inexistant, normal pour un test) → le backend n'est pas le problème
# timeout/000 = l'API EPIDOCS est injoignable → voir son propre runbook

# 3. Si l'API EPIDOCS est down, c'est son incident à traiter (pas celui-ci) :
#    voir epidocs-api/runbook.md

Si l'URL bakée est incorrecte (mauvais environnement, ancien domaine backend, etc.), ce n'est pas quelque chose qui se corrige à chaud sur le VPS — voir overview.md — gotcha build-time : corriger le secret GitHub Actions VITE_API_BASE_URL puis redéployer (push sur main ou relance manuelle du workflow), ce qui reconstruit l'image avec la bonne valeur.

Étape 7 : Rollback si un déploiement a cassé le site¶

cd /root/projects/public-diploma-verify

# Lister les images disponibles
docker images ghcr.io/epitechafrik/public-diploma-verify --format "table {{.Tag}}\t{{.CreatedAt}}"

# Éditer docker-compose.yml (généré par la CI depuis docker-compose.prod.yml) :
# remplacer l'image par un tag antérieur, ex. ghcr.io/epitechafrik/public-diploma-verify:main-<sha>
nano docker-compose.yml

docker compose pull
docker compose up -d

# Vérifier
docker ps | grep public_diploma_verify
curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1:7015

Après le rollback¶

Investiguer la cause sur main.
Corriger et pousser un correctif — le pipeline redéploiera automatiquement (voir overview.md — Pipeline CI/CD).
Avant de retoucher src/App.tsx/src/types.ts, lire troubleshooting.md — Le flux en deux temps est la version voulue : ne pas revenir à un flux en une seule étape sans revalider le risque de scraping que le flux actuel limite.

Résumé des ports et chemins¶

Élément	Valeur
Port hôte (défaut)	`127.0.0.1:7015`
Port conteneur	`80`
Conteneur	`public_diploma_verify`
Chemin VPS	`/root/projects/public-diploma-verify`
Image GHCR	`ghcr.io/epitechafrik/public-diploma-verify`
URL prod	`https://diplome.epitech.africa`
Backend appelé	API EPIDOCS — voir epidocs-api/runbook.md si le backend lui-même est en panne

Contacts¶

Rôle	Contact
Développeur & Mainteneur	YemalinModeste — yemalin1.agbangla@epitech.eu