Ce Home Lab reproduit une infrastructure Cloud Native moderne, basée sur un cluster Kubernetes privé auto-hébergé sur un serveur Dell PowerEdge, virtualisé via VMware ESXi. L'objectif est de disposer d'une plateforme complète pour l'apprentissage, l'expérimentation de services microservices, les tests DevSecOps, ainsi que la validation de chaînes CI/CD réalistes.

1. Environnement d'exécution

graph TD
    ESXi["VMware ESXi (hyperviseur)"]
    VMInfra["VM vminfra
(DNS, Mail, Ansible)"]
    VMDevOps["VM vmdevops
(GitLab, Jenkins, Nexus)"]
    K8s["Cluster Kubernetes
(6 nœuds)"]
    NAS["NAS QNAP (NFS)"]
    UDM["UDM Pro (Firewall & VLAN)"]
    VPN["VPN (Wireguard / OpenVPN)"]

    ESXi --> VMInfra
    ESXi --> VMDevOps
    ESXi --> K8s
    K8s --> NAS
    UDM --> VPN
    VPN --> VMInfra
    VPN --> K8s

L'environnement d'exécution est la couche fondamentale. Elle définit la base matérielle et logicielle sur laquelle repose l'ensemble des services.

  • Hyperviseur : VMware ESXi permet de créer des VMs isolées pour séparer les différents composants (control-plane, workers, monitoring, etc.).

  • Orchestration : Kubernetes permet de gérer dynamiquement les conteneurs et leur déploiement sur l'ensemble du cluster.

  • Load Balancing :

    • HAProxy répartit les appels vers les control planes Kubernetes pour garantir la haute disponibilité.
    • NGINX Ingress Controller expose les services aux clients finaux (APIs, frontends).

  • Stockage : un NAS QNAP connecté via NFS est monté dynamiquement via des StorageClass Kubernetes pour persister les données (DB, logs, fichiers partagés).

  • Réseau et gestion : un routeur/firewall UDM Pro et un accès distant via Wireguard/OpenVPN permettent un accès sécurisé et un cloisonnement du trafic.

  • Infrastructure as Code : tous les services liés à l'infrastructure (DNS, Mail, monitoring, utilisateurs) sont provisionnés via Ansible, facilitant la reproductibilité et la standardisation.

  • Machines virtuelles spécialisées :

    • vminfra : héberge les services fondamentaux liés à l'infrastructure (DNS, Mail, Ansible, reverse proxy).
    • vmdevops : dédiée aux outils DevOps comme GitLab auto-hébergé, Jenkins, Nexus, et Helm, utilisés pour le cycle CI/CD complet.

2. Stack Backend (Microservices)

graph TD
    Keycloak["Keycloak IAM"]
    Zuul["Zuul Gateway"]
    Eureka["Eureka Registry"]
    Redis["Redis Cache"]
    Kafka["Kafka Broker"]
    RabbitMQ["RabbitMQ Broker"]
    PostgreSQL["PostgreSQL DB"]
    MariaDB["MariaDB DB (Ghost)"]

    Keycloak --> Zuul
    Zuul --> Service1["Spring Boot Service A"]
    Zuul --> Service2["Spring Boot Service B"]
    Service1 --> Eureka
    Service2 --> Eureka
    Service1 --> PostgreSQL
    Service2 --> Redis
    Service1 --> Kafka
    Service2 --> RabbitMQ

Le backend est basé sur des microservices développés en Java Spring Boot 3, déployés de manière isolée et interconnectés.

Chaque microservice respecte les principes suivants :

  • Communication via API REST ou messaging
  • Stateless avec stockage externe (DB, cache)
  • Configuration injectée dynamiquement via Spring Config Server

Composants principaux :

  • Spring Boot / Spring Cloud : coeur des microservices (endpoints REST, logique métier, résilience)
  • Eureka : registre de services (auto-découverte)
  • Zuul : API Gateway pour diriger les requêtes entrantes vers le bon service
  • Spring Security + OAuth2 (Keycloak) : gestion des identités, rôles, tokens JWT
  • Javers : audit et versionning des entités (historisation)
  • MapStruct : génération automatique de mappers entre DTOs et entités
  • PostgreSQL : base relationnelle principale
  • MariaDB : utilisé pour des outils tiers comme Ghost, qui attendent une compatibilité MySQL
  • Redis : cache haute performance pour session, antispam, counters
  • Kafka : broker haute disponibilité pour les flux asynchrones métier
  • RabbitMQ : bus pour les échanges plus légers ou moins critiques

3. Stack Frontend

graph TD
    User["Utilisateur Web ou Mobile"]
    Ingress["NGINX Ingress Controller"]
    NextJS["Next.js (SSR Frontend)"]
    React["React / React Native"]
    Angular["Angular Legacy"]
    API["API Kubernetes"]

    User --> Ingress
    Ingress --> NextJS
    Ingress --> React
    Ingress --> Angular
    NextJS --> API
    React --> API
    Angular --> API

Les frontends couvrent plusieurs cas d'usage : application principale, outils internes, interfaces mobiles.

  • Next.js : pour le portail principal SSR/CSR, avec performance et SEO
  • React / React Native : pour des interfaces réactives et mobiles (POC ou apps)
  • Angular : pour des interfaces existantes ou internes
  • Python / JS / Node : pour des outils techniques, scripts ou automatisations

Tous les frontends sont conteneurisés et accédés via Ingress Kubernetes.

4. CI/CD Pipeline

graph TD
    Dev["Développeur"]
    GitLab["GitLab Repository"]
    Jenkins["Jenkins Pipeline"]
    SonarQube["SonarQube"]
    Nexus["Nexus Docker Repo"]
    Helm["Helm Charts"]
    HAProxy["HAProxy (API Access)"]
    Kubernetes["Cluster Kubernetes"]

    Dev --> GitLab
    GitLab --> Jenkins
    Jenkins --> SonarQube
    Jenkins --> Nexus
    Jenkins --> Helm
    Jenkins --> HAProxy
    HAProxy --> Kubernetes

La chaîne CI/CD est essentielle pour maintenir une intégration et un déploiement continus, sans intervention manuelle. Elle repose sur un flux de travail bien défini adapté à la taille des projets :

Flux Git

  • Pour les projets complexes : utilisation du GitFlow feature/* develop release/* main hotfix/*

  • Pour les projets simples : modèle à 2 branches :

    develop (développement continu)
    main (branche stable déployée en production)

Étapes du cycle de vie projet

sequenceDiagram
    participant Dev as Développeur
    participant GitLab as GitLab
    participant Jenkins as Jenkins
    participant Sonar as SonarQube
    participant Nexus as Nexus (Docker Repo)
    participant Helm as Helm Repo
    participant HAProxy as HAProxy
    participant K8s as Cluster Kubernetes

    Dev->>GitLab: Push du code (dev / feature)
    GitLab->>Jenkins: Webhook / Détection CI
    Jenkins->>Sonar: Analyse de code
    Jenkins->>Nexus: Push image Docker
    Jenkins->>Helm: Push chart Helm
    Jenkins->>HAProxy: API Kubernetes via Ingress
    HAProxy->>K8s: helm upgrade/install

  1. Création du projet dans GitLab avec intégration LDAP

  2. Clonage local et configuration initiale du projet

  3. Commits réguliers vers develop ou feature/*

  4. Ajout de la structure CI Jenkinsfile et chart/helm dans le dépôt

  5. Détection automatique par Jenkins via job multibranch ou webhook GitLab

  6. Scan du projet (lint, build, tests, SonarQube)

  7. Construction d'image Docker personnalisée (mirror de base image local)

  8. Push vers Nexus (repository Docker privé)

  9. Packaging Helm et push vers repository privé Helm

  10. Déploiement via Jenkins :

    helm upgrade ou helm install
    sur cluster Kubernetes à travers HAProxy (accès API control-plane)

L'ensemble du processus est traçable, sécurisé, et reproductible via les outils hébergés dans la VM vmdevops.

La chaîne CI/CD est essentielle pour maintenir une intégration et un déploiement continus, sans intervention manuelle.

  • GitLab : SCM principal, intégration LDAP, gestion des projets et merge requests (hébergé sur vmdevops)
  • Jenkins : build Java (Maven/Gradle), création des images Docker, push vers Nexus, déploiement Helm (hébergé sur vmdevops)
  • Nexus : registre d'artefacts Docker/Maven (hébergé sur vmdevops)
  • Helm : chartes Helm versionnées pour chaque service (déploiement reproductible)

Les pipelines Jenkins sont triggerés automatiquement par push Git ou planification.

5. Observabilité et Monitoring

L'ensemble des composants est monitoré et observable via une stack open source.

  • Prometheus : collecte des métriques via des exporteurs (Node, Java, custom)
  • Grafana : dashboards personnalisables (CPU, RAM, erreurs, flux, etc.)
  • Kafka UI : pour surveiller les topics Kafka
  • Kibana : via ECK (Elastic Operator), pour les logs centralisés
  • Uptime Kuma : supervision basique (HTTP, ports, latence)

6. Sécurité & Authentification

L’accès aux services est protégé et unifié via SSO et authentification centralisée.

  • Keycloak : serveur IAM (OAuth2, OIDC), connecté aux frontends et aux APIs
  • LDAP interne : source d'identités centralisée pour l'ensemble des services (GitLab, Jenkins, Keycloak, Gitea, Nexus, Grafana). Il est hébergé sur la VM vminfra, provisionné via Ansible, et permet une gestion cohérente des utilisateurs et des groupes à travers tout le lab.
  • Mail interne : véritable serveur SMTP local en LAN, reposant sur Postfix pour l’envoi, Dovecot pour la réception et Rainloop comme client webmail. Il permet de tester les flux d'inscription, de notification, et de recevoir les alertes automatiques telles que les notifications de build Jenkins, les push GitLab ou les erreurs d'intégration. Accessible uniquement sur le réseau interne via authentification sécurisée.

7. Déploiement Kubernetes

Chaque microservice est :

  • Contenurisé (Docker)
  • Packagé en chart Helm
  • Déployé dans un namespace dédié
  • Exposé via Ingress
  • Configuré dynamiquement avec Spring Config

La séparation des environnements (infra, dev, monitoring) est assurée par des namespaces Kubernetes.

8. Exemple de services déployés

Voici quelques services actifs dans le cluster DEV :

  • valife-financial, valife-report, valife-profil : services métiers
  • auth-server, resource-server : infrastructure de sécurité OAuth2
  • eureka-server, zuul-server : régistration et gateway
  • valife-nextjs-front : UI SSR principal
  • kafka-ui, n8n, kubana : visualisation, automatisation, logs

9. Outils de développement

Type Outil principal Pourquoi ?
IDE Java Eclipse → IntelliJ Support avancé de Spring et Git
Frontend / Python Visual Studio Code Rapidité, extensions riches
Mots de passe Keepass → Passbolt Accès web, gestion équipe, compatible Mac

10. Base de données et messaging : choix techniques

  • PostgreSQL : choix par défaut, robuste, riche, SQL standard
  • MariaDB : pour compatibilité avec Ghost, WordPress, etc.
  • Redis : cache rapide pour sessions, état temporaire
  • Kafka : événements de forte volumétrie (logs, actions utilisateur)
  • RabbitMQ : communication rapide point à point ou fanout simple

11. Vision d'ensemble

Ce lab est pensé comme une réplication fidèle d'un système en production, tout en gardant une souplesse expérimentale. Il combine éducation, tests techniques, bonnes pratiques DevOps, et mise en œuvre concrète des outils open source actuels.

Il est également utilisé comme terrain de préparation à la certification Kubernetes, à l'intégration continue, et à la modernisation d'architectures legacy.