Skip to content

Architecture de Déploiement

Cette architecture sépare explicitement trois niveaux :
1. Zone publique : accessible aux utilisateurs.
2. Zone DMZ : zone tampon contrôlée par un reverse proxy / Ingress.
3. Zone privée : cœur applicatif et services sensibles.

Cet agencement crée un tunnel d’accès strictement contrôlé entre l’extérieur et les microservices internes, améliorant la sécurité, l’observabilité et la gouvernance réseau.

Elle s’appuie sur un modèle microservices + namespaces segmentés + socle centralisé, entièrement piloté via CI/CD et Infrastructure as Code.

Architecture globale de Zorni

Architecture globale de Zorni

1. 🌐 Zone Publique — Espace visible par les utilisateurs

La zone publique expose uniquement les ressources nécessaires à la navigation des utilisateurs finaux.
Aucun service métier n’est accessible à ce niveau.

Namespace : apps

Contient le front-end principal de la plateforme.

zorni-portal

  • Application front accessible depuis Internet.
  • Distribuée via Ingress (port 80/443).
  • Communication descendante : front → reverse proxy dans la DMZ.

Caractéristiques DevOps :

  • TLS géré par Cert-Manager.
  • Règles d’Ingress minimalistes (seulement / API du BFF ou endpoints front).
  • Pas de communication directe avec la zone privée.

La DMZ est la pièce maîtresse du filtrage réseau.
Elle introduit un espace tampon entre le front public et l’écosystème privé, évitant toute exposition directe des API.

Namespace : dmz

Ce namespace héberge l'Ingress Controller.

Reverse Proxy / Ingress

  • Point d’entrée unique pour toutes les requêtes HTTP venant du front.
  • Redirection interne vers les services privés via règles d’Ingress.
  • Possibilité de WAF, rate limiting, filtrage IP, sécurité L7.

Objectifs DevOps :

  • Sécuriser et auditer le trafic via logs Ingress.
  • Appliquer des politiques comme TLS enforcement, rewrites, timeouts, throttling.
  • Préparer une future API Gateway si besoin (Kong, Ambassador, Traefik Enterprise).

Rôle structurant :

Le Ingress agit comme un gardien : - Public → DMZ → Private
- Aucun pod de la zone privée n’est exposé directement.

3. 🔒 Zone Privée — Noyau applicatif et services critiques

La zone privée regroupe tout ce qui ne doit jamais être exposé en externe : microservices, bases de données, socle technique.

3.1 Namespace : apis

Contient l’ensemble des microservices de la plateforme.

zorni-controller

Module transverse orchestrant certaines logiques internes.

Microservices métiers disponibles

Chaque API est isolée dans le namespace et peut scaler indépendamment : - partnersApi
- personsApi
- uploadApi
- communicationApi
- taskApi
- travelsApi
- transactionsApi
- notificationsApi

Propriétés DevOps :

  • Exposition interne uniquement via ClusterIP.
  • Observabilité (metrics Prometheus, logs centralisés).
  • Secrets injectés via Vault.
  • Accès réseau contrôlé via NetworkPolicies (DMZ → APIs uniquement).

3.2 Namespace : data-base

Uniquement pour l'environnement de recette, Namespace dédié aux données persistantes.
POur la prod en utilisera des bases de données managés. Chaque microservice possède sa base dédiée (pattern database-per-service).

Bases applicatives

  • partnersDb
  • personsDb
  • uploadDb
  • commDb
  • taskDb
  • travelsDb
  • transactionsDb
  • notificationDb

Bases techniques

  • KeycloakDb
  • vaultDb

Enjeux DevOps :

  • Stockage persistant via PVC + StorageClass.
  • Backups automatisés (Velero ou équivalent).
  • Séparation stricte : chaque service ne parle qu'à sa propre base.

3.3 Namespace : socle

Namespace regroupant les briques transverses indispensables à l’écosystème du cluster.

Keycloak

Gestion fédérée des utilisateurs, rôles et permissions.
Alimenté par KeycloakDb.

Kafka

Système de messagerie asynchrone.
Facilite le découplage entre services, traitement parallèle, notifications, pipelines d’événements.

Vault

Gestionnaire centralisé de secrets.
Stocke les credentials DB, tokens d’API, clés d’encryption.

Propriétés DevOps :

  • Déploiement via Helm ou Operators (Strimzi pour Kafka, Vault Operator…).
  • Monitoring via Prometheus + Grafana.
  • Politique de sécurité stricte (RBAC, ACL Vault, TLS).

4. 🧩 Vision globale du flux réseau

Le schéma reflète un flux contrôlé à trois étages :

1. Utilisateur → Zone Publique

Requête HTTP vers le portail zorni-portal.

2. Zone Publique → Zone DMZ

Le front communique exclusivement avec le reverse proxy dans dmz.

3. Zone DMZ → Zone Privée

Le reverse proxy redirige les requêtes vers : - les APIs internes (namespace apis), - éventuellement des services du socle si exposés derrière l’Ingress (rare), - jamais directement vers les bases de données.

Ce modèle renforce : - la sécurité,
- la gouvernance du trafic,
- la visibilité via logs Ingress,
- la capacité à ajouter un WAF ou une gateway sans impacter le reste.

5. 🎯 Conclusion DevOps

L’ajout du namespace dmz transforme ton architecture en un modèle plus mature et professionnel :

  • Surface d’exposition réduite au strict minimum.
  • Couche tampon (DMZ) permettant un contrôle total du trafic.
  • Séparation nette front / proxy / services internes.
  • Sécurité et observabilité accrues.
  • Alignement avec les bonnes pratiques Kubernetes modernes (Zero Trust, cluster segmentation, Ingress centralisé).

Cette évolution renforce la résilience, la sécurité et la maintenabilité du système tout en préparant l’architecture pour une montée en charge ou des intégrations futures.

© 2022 ZORNI. Tous droits réservés.