P5 — Décommission de la VM 100 « Gardien »

Retirer la VM 100 Gardien (4 vCPU / 4 Go), ancien reverse-proxy Caddy devenu obsolète : le rôle de frontal web est désormais tenu par Coolify / Traefik (VM 101). Objectif : libérer les ressources et supprimer une VM qui n'est plus maintenue.

État — réalisé le 2026-07-17

VM 100 décommissionnée. À l'inspection, elle hébergeait un hôte Docker (10.9.73.5) avec Caddy (l'ancien reverse-proxy, remplacé par Coolify) et Portainer (un test) — plus aucun domaine ni redirection de port ne pointait dessus. Backup vzdump filet pris, VM arrêtée puis supprimée (qm destroy 100 --purge), références nettoyées (inventaire, pare-feu, ADR-003). Étant hors OpenTofu (absente du tfstate), sa suppression manuelle ne crée aucun écart côté tofu.

Durée : ~15 min d'action + quelques jours d'observation. Impact : nul si les pré-vérifications sont concluantes (la VM ne rend plus de service).

Étape 1 — Vérifier que plus rien ne dépend de Gardien

Le risque unique : couper un flux encore actif. À confirmer avant tout arrêt.

[ ] Reverse-proxy : aucun site/app n'est plus servi par le Caddy de Gardien — tout est passé par Coolify (cf. CI/CD et Ce site). Vérifier qu'aucune app Coolify ne pointe encore vers elle.
[ ] Redirections de port : ni la Livebox ni l'ER605 (Omada → Sécurité → Port Forwarding / NAT) ne redirigent 80/443 (ou autre) vers l'IP de Gardien. Aujourd'hui le public arrive sur Coolify (10.9.73.90).
[ ] DNS : aucun enregistrement (OVH *.leonheu.fr, ou DNS interne) ne résout vers l'IP de Gardien.
[ ] Trafic résiduel : sur la VM (console/SSH), vérifier qu'aucune connexion entrante utile n'arrive encore — p. ex. ss -tanp | grep -E ':80|:443' et les logs Caddy récents. Idéalement : rien.

Noter l'IP et la config avant de supprimer

Relever l'IP de Gardien et, si le Caddyfile contient encore quelque chose d'utile (un vhost oublié), l'exporter avant l'arrêt.

Étape 2 — Sauvegarde filet

[ ] Lancer un dernier vzdump de la VM 100 (PVE → VM 100 → Backup → Backup now, mode snapshot). Il servira de retour arrière si une dépendance oubliée apparaît. Noter la date : il sera purgé par la rétention habituelle (cf. Restaurer un backup).

Étape 3 — Arrêt observé (fenêtre de rollback)

[ ] Arrêter la VM sans la supprimer : PVE → VM 100 → Shutdown (ou qm shutdown 100).
[ ] La laisser éteinte quelques jours. Si un service oublié cassait, le symptôme apparaît — le rollback est alors trivial : redémarrer la VM (qm start 100).

Étape 4 — Suppression définitive

Une fois la période d'observation passée sans incident :

[ ] PVE → VM 100 → Remove (cocher Purge pour retirer les entrées de sauvegarde/replication associées), ou en CLI :
```
qm destroy 100 --purge --destroy-unreferenced-disks 1
```

Cela libère les 4 vCPU / 4 Go et le disque sur local-lvm.

Étape 5 — Nettoyer les références (doc + code)

Gardien est citée à plusieurs endroits — à retirer pour que la doc reste vraie :

[ ] docs/infra/architecture.md : supprimer la ligne 100 Gardien de l'inventaire.
[ ] docs/infra/reseau.md : retirer « VM 100 Gardien » du tableau pare-feu (ligne « hors périmètre »).
[ ] infra/opentofu/firewall.tf : retirer la mention de la VM 100 dans le commentaire « Volontairement SANS pare-feu par machine ».
[ ] docs/infra/adr/003-nac-sdn-firewall.md : la décision mentionne « VM 100 Gardien (décommission prévue en P5) » — laisser l'ADR comme trace historique, ou ajouter une note « P5 réalisé le AAAA-MM-JJ ».

Étape 6 — Vérification finale

[ ] make plan dans ~/projets/infra → aucun changement attendu : Gardien n'étant pas dans l'état OpenTofu, sa suppression manuelle ne crée aucun écart côté tofu.
[ ] L'inventaire Architecture ne liste plus la VM 100.