🖥️ Diagramme de déploiement CV-builder
|
Note
|
📺 Diagramme SVG de ce document
Documents liĂ©s : Architecture backend · Architecture frontend · Cas d’utilisation |
Track Technique 2TUP — Phase 3b : Modèle de déploiement
Le diagramme de dĂ©ploiement dĂ©crit la topologie physique : quels artefacts s’exĂ©cutent sur quels nĹ“uds,
et par quels liens réseau ils communiquent. Notation UML classique : nœuds en cubes 3D avec leurs
propriĂ©tĂ©s {os = …}, {number = …}, liens stĂ©rĂ©otypĂ©s «WAN» / «LAN».
Description des nœuds
| Nœud | Artefacts déployés | Caractéristiques |
|---|---|---|
PCs Candidats |
SPA CV-Builder (chargée dans le navigateur) |
Tout OS, nombre illimité ; accès via Internet en HTTPS |
PCs Admin |
SPA CV-Builder (console admin, gestion des templates) |
Tout OS, < 10 postes |
Firewall |
Règles de filtrage |
Seul le port 443 (HTTPS) est exposé ; le reste du réseau est privé |
Serveur Web Nginx |
Fichiers statiques de la SPA (build Vite), configuration reverse proxy |
Conteneur docker ; termine le TLS, route |
Serveur d’application Spring Boot |
|
Conteneur docker, scalable horizontalement (1 à 3 instances derrière Nginx) |
Serveur BD PostgreSQL |
Base |
Conteneur docker, version 16 (image pgvector) ; accès R2DBC port 5432 réservé au backend
(Liquibase JDBC au démarrage uniquement) ; migrations |
Serveur BD MongoDB |
Base |
Conteneur docker, version 8.0 ; port 27017 réservé au backend (Spring Data MongoDB) |
Cache Redis |
Cache uniquement : recherches jobs, quotas IA, rate-limiting, tickets SSE, prĂ©sence. Pas de sessions — l’authentification est stateless (JWT Keycloak) |
Conteneur docker, version 7 ; protocole RESP port 6379 ; 32 MB, éviction |
Stockage objet MinIO (S3) |
Bucket |
Conteneur docker ; API S3 port 9000 ; |
Keycloak (externe) |
Credentials et rĂ´les des utilisateurs (realm |
Service mutualisé hors du docker-compose CV-Builder ; accès HTTPS (OIDC / JWKS) |
Flux réseau
| Lien | Stéréotype | Détail |
|---|---|---|
Postes clients → Firewall |
«WAN» |
Internet, HTTPS uniquement (port 443) |
Firewall → Nginx |
— |
Trafic filtré (pointillés : passage du périmètre de sécurité) |
Nginx → Spring Boot |
«LAN» |
Réseau docker interne, HTTP |
Spring Boot → PostgreSQL |
«LAN» |
R2DBC, port 5432 (Liquibase JDBC au démarrage) |
Spring Boot → MongoDB |
«LAN» |
Wire protocol Mongo, port 27017 |
Spring Boot → Redis |
«LAN» |
RESP, port 6379 |
Spring Boot → MinIO |
«LAN» |
API S3, port 9000 (upload/download des fichiers) |
Spring Boot → Keycloak |
«WAN» |
HTTPS : validation JWT (JWKS), admin REST API |
Sync Gate — CohĂ©rence avec l’architecture
-
Chaque composant logique de l’architecture backend a un nĹ“ud d’exĂ©cution : controllers/services/repositories → Serveur d’application ; les tâches planifiĂ©es (agrĂ©gation d’offres) s’exĂ©cutent dans la mĂŞme JVM (pas de nĹ“ud dĂ©diĂ©).
-
La SPA de l’architecture frontend est un artefact statique servi par Nginx — aucun serveur Node en production. L’export PDF s’exĂ©cute dans le navigateur (jsPDF / impression) : aucun PDF gĂ©nĂ©rĂ© n’est stockĂ© cĂ´tĂ© serveur.
-
La scalabilitĂ© du backend (1..3 instances) est possible car les services sont sans Ă©tat : l’authentification est stateless (JWT Keycloak), les caches sont externalisĂ©s dans Redis, les fichiers dans MinIO (S3).
Verdict : le modèle de dĂ©ploiement supporte les 19 cas d’utilisation sans infrastructure non planifiĂ©e — validĂ©.