P&P Project & Deployment Guide v2.0

Étape 09 — Construire la production

Préparer l’infrastructure réelle sans encore basculer les clubs.

Semaine 112 VPS production
Pour comprendre avant d’exécuter

Pourquoi séparer APP et DATA ?

La production contient les vraies données. On sépare le serveur qui reçoit le trafic Internet du serveur qui contient PostgreSQL/Redis afin de réduire ce qu’un attaquant pourrait atteindre si l’application était compromise.

Règle de travail

Lire la section complète, copier une commande à la fois, vérifier le résultat attendu, puis seulement continuer.

Vocabulaire utile
  • PROD-APP : frontend/API/workers exposés via Caddy.
  • PROD-DATA : base et sessions sur réseau privé.
  • Blast radius : étendue maximale d’un incident.

1. Créer les deux VPS production

Créer P&P-PROD-APP et P&P-PROD-DATA sur un réseau privé fournisseur si disponible. N’exposez jamais PostgreSQL ou Redis à Internet.

2. Répéter le socle durci

Reprendre les commandes de l’étape 02 pour Ubuntu, compte pnpadmin, SSH et Docker, mais via votre procédure automatisée/documentée. Ne recopiez pas manuellement les configurations depuis la sandbox.

Revoir le socle NONPROD

3. Politique réseau

Internet → PROD-APP : 80/443 Admin → PROD-APP : SSH depuis réseau/IP autorisé PROD-APP → PROD-DATA : 5432 PostgreSQL, 6379 Redis Internet → PROD-DATA : DENY
Docker + firewall.Un port publié par Docker peut contourner UFW. Préférer des réseaux internes et, quand nécessaire, filtrer via DOCKER-USER. Ne jamais publier 5432/6379 sur 0.0.0.0.

4. Vérifier les ports

sudo ss -lntup
sudo docker ps --format "table {{.Names}}\t{{.Ports}}"
Résultat attenduSur PROD-DATA, aucun `0.0.0.0:5432` ni `0.0.0.0:6379`. Sur PROD-APP, seuls les services explicitement prévus sont exposés.

5. Sauvegardes avant utilisateurs

Configurer le dump PostgreSQL, le chiffrement, la copie hors VPS et l’alerte d’échec avant toute donnée réelle.

Ouvrir le runbook sauvegardes

6. Gate de sortie