Phases de déploiement
Ce document décrit l'ordre de construction du homelab, de l'installation de Proxmox jusqu'aux pipelines DevSecOps. Chaque phase dépend de la précédente.
Phase 1 — Proxmox
Objectif : cluster Proxmox VE 9.2 fonctionnel sur les 3 Nab6-Lite.
| Étape | Description |
|---|---|
| 1.1 | Installer Proxmox VE 9.2 sur chaque nœud (NVMe : OS, SSD 1 To : stockage VMs) |
| 1.2 | Créer le cluster Proxmox depuis pve01, rejoindre pve02 et pve03 |
| 1.3 | Configurer le datastore local sur le SSD 1 To de chaque nœud |
| 1.4 | Créer un template Debian 13 cloud-init (via Packer ou manuellement) |
| 1.5 | Activer le firewall Proxmox (datacenter + chaque nœud) |
| 1.6 | Configurer les notifications (email ou Webhook) pour les alertes cluster |
Livrable : 3 nœuds en cluster, template Debian 13 prêt, firewall actif.
Phase 2 — Provisionnement des VMs (OpenTofu)
Objectif : créer les 10 VMs via OpenTofu (provider telmate/proxmox).
Ordre de création
Les VMs sont créées dans un ordre qui respecte les dépendances réseau et logicielles :
| Ordre | ID | VM | Pourquoi cet ordre |
|---|---|---|---|
| 1 | 103 | vault |
Premier service nécessaire — tous les autres auront besoin de secrets |
| 2 | 101 | traefik |
Point d'entrée unique — nécessaire pour exposer les services |
| 3 | 203 | keycloak |
SSO central — les services doivent pouvoir s'y connecter dès leur déploiement |
| 4 | 102 | gitlab |
Code, CI/CD, runners |
| 5 | 201 | harbor |
Registry — nécessaire après GitLab pour les images Docker |
| 6 | 202 | monitoring |
Observabilité — doit scraper dès que les services tournent |
| 7 | 204 | defectdojo |
Gestion des vulnérabilités |
| 8 | 301-303 | k3s-master, workers |
Kubernetes — dernière couche d'infrastructure |
Étapes OpenTofu
# Structure du projet OpenTofu
homelab-proxmox/
├── providers.tf # Provider telmate/proxmox
├── variables.tf # IPs, IDs, credentials Proxmox
├── main.tf # Définition des 10 VMs
├── cloud-init/
│ └── debian-13.yml # Configuration cloud-init commune
└── outputs.tf # IPs, IDs des VMs créées
Chaque VM est créée avec : - Template Debian 13 - IP statique configurée via cloud-init - Clé SSH publique injectée - UFW activé avec règles de base (port SSH 2222 uniquement) - Hostname et DNS (/etc/hosts)
CI/CD — Pipeline GitLab.com
# .gitlab-ci.yml déclenché sur la branche main
stages:
- plan
- apply
opentofu-plan:
stage: plan
script: tofu plan -out=tfplan
opentofu-apply:
stage: apply
script: tofu apply tfplan
Livrable : 10 VMs créées, accessibles en SSH (port 2222), UFW actif.
Phase 3 — Hardening de base (Ansible)
Objectif : sécuriser toutes les VMs avant d'installer des services.
Étapes
# playbooks/00-hardening.yml
- hosts: all
tasks:
- name: Configurer SSH (port 2222, clé uniquement)
- name: UFW — default deny incoming, allow 2222
- name: Installer et configurer Fail2Ban (jail SSH)
- name: Désactiver le swap
- name: Installer les paquets communs (curl, htop, git, ...)
- name: Configurer /etc/hosts
Inventaire Ansible
[homelab]
traefik ansible_host=192.168.1.20
gitlab ansible_host=192.168.1.21
vault ansible_host=192.168.1.22
harbor ansible_host=192.168.1.30
monitoring ansible_host=192.168.1.31
keycloak ansible_host=192.168.1.32
defectdojo ansible_host=192.168.1.33
k3s-master ansible_host=192.168.1.40
k3s-worker01 ansible_host=192.168.1.41
k3s-worker02 ansible_host=192.168.1.42
[all:vars]
ansible_user=mounik
ansible_port=2222
Livrable : Toutes les VMs durcies (SSH, UFW, Fail2Ban), prêtes à recevoir les services.
Phase 4 — Services (Ansible)
Objectif : installer et configurer chaque service, toujours dans le respect des dépendances.
4.1 — Vault (103)
| Étape | Description |
|---|---|
| Installer Vault | Binaire unique, service systemd |
| Configurer HA | Désactivé (single instance — pas de HA) |
| Backend storage | Fichier (pas Raft — assez pour un homelab) |
| Initialiser | Générer les clés de déverrouillage (stocker hors ligne) |
| Déverrouiller | Unseal avec 3 des 5 clés |
| Configurer | Activer KV v2, créer les chemins de secrets (gitlab, harbor, k3s) |
| PKI interne | Configurer et signer le certificat CA interne |
Avant de continuer : Vault doit être opérationnel et déverrouillé automatiquement au démarrage.
4.2 — Traefik (101)
| Étape | Description |
|---|---|
| Installer Traefik | Binaire, service systemd |
| Configurer | Fichier YAML dynamique ou TOML statique |
| Let's Encrypt | Challenge DNS OVH — wildcard *.mounik.ovh |
| CrowdSec | Installer le bouncer Traefik |
| Dashboard | Activer avec authentification (basique ou OIDC via Keycloak) |
Avant de continuer : Traefik doit servir un certificat valide pour *.mounik.ovh.
4.3 — Keycloak (203)
| Étape | Description |
|---|---|
| Installer Keycloak | Distribution standalone, PostgreSQL embarqué ou dédié |
| Configurer | Premier admin, créer le realm homelab |
| Clients OIDC | Créer un client pour chaque service (GitLab, Harbor, Grafana, ArgoCD, DefectDojo) |
| Utilisateurs | Créer le compte administrateur et des comptes de test |
Avant de continuer : Keycloak doit pouvoir authentifier un utilisateur de test.
4.4 — GitLab (102)
| Étape | Description |
|---|---|
| Installer GitLab CE | Package Debian, Omnibus |
| Configurer | URL externe (gitlab.mounik.ovh), TLS via Traefik |
| Intégrer Keycloak | OIDC — les utilisateurs se connectent avec leur compte Keycloak |
| Intégrer Vault | CI/CD — injecter les secrets depuis Vault |
| Runner | Installer un runner shell ou Docker sur la VM GitLab |
Avant de continuer : Un pipeline de test doit pouvoir s'exécuter.
4.5 — Harbor (201)
| Étape | Description |
|---|---|
| Installer Harbor | Offline installer, Docker Compose |
| Configurer | URL (harbor.mounik.ovh), TLS via Traefik |
| Intégrer Keycloak | OIDC pour la connexion |
| Intégrer Vault | Stockage des credentials registry |
| Projets | Créer un projet par application (fastapi, streamlit, flask) |
4.6 — Monitoring (202)
| Étape | Description |
|---|---|
| Installer Prometheus | Binaire, service systemd |
| Configurer targets | Node exporter sur chaque VM (port 9100) |
| Installer Grafana | Binaire, dashboards |
| Intégrer Keycloak | OIDC pour la connexion |
| Installer Loki + Promtail | Logs système, rétention 2 jours |
| Alerting | Règles de base (node down, disk full, high CPU) |
4.7 — DefectDojo (204)
| Étape | Description |
|---|---|
| Installer DefectDojo | Docker Compose (Django + Celery + PostgreSQL + Redis) |
| Configurer | URL (defectdojo.mounik.ovh), TLS via Traefik |
| Intégrer Keycloak | OIDC pour la connexion |
| API tokens | Générer un token pour les pipelines CI/CD |
Livrable : Tous les services installés, accessibles via leurs sous-domaines respectifs, authentifiés par Keycloak.
Phase 5 — Kubernetes (301-303)
Objectif : Cluster k3s avec GitOps.
5.1 — Installation k3s
| Étape | Description |
|---|---|
| Master | Installer k3s sur 301 (sans etcd — SQLite) |
| Taint | kubectl taint node k3s-master node-role.kubernetes.io/control-plane=:NoSchedule |
| Worker01 | Installer k3s agent, join le master |
| Worker02 | Installer k3s agent, join le master |
| Vérifier | kubectl get nodes — 3 nodes Ready |
5.2 — Traefik Ingress dans k3s
Le Traefik principal (VM 101) route le trafic vers le cluster k3s via l'Ingress :
# traefik reverse proxy → k3s-master:443 (Ingress Controller)
# Flèche : traefik.mounik.ovh → 192.168.1.40:443
Dans k3s, utiliser Traefik comme Ingress Controller (intégré par défaut dans k3s).
5.3 — ArgoCD
| Étape | Description |
|---|---|
| Installer ArgoCD | Manifeste Kubernetes dans k3s |
| Configurer | URL (argocd.mounik.ovh), TLS via Traefik |
| Intégrer Keycloak | OIDC — les utilisateurs se connectent avec Keycloak |
| Dépôt Git | Connecter au dépôt GitLab des manifests Kubernetes |
5.4 — GitLab Runner sur k3s
| Étape | Description |
|---|---|
| Installer | Helm chart du GitLab Runner dans k3s (worker01) |
| Configurer | Token du projet GitLab, executor Kubernetes |
| Tester | Lancer un pipeline simple (echo) |
Livrable : Cluster k3s avec ArgoCD, synchronisé avec GitLab. Un pipeline CI/CD peut déployer sur le cluster.
Phase 6 — Applications Python
Objectif : Déployer 3 applications Python via GitOps.
| Application | Stack | Déploiement |
|---|---|---|
| FastAPI | API REST, Prometheus client | ArgoCD → k3s-worker01/02 |
| Streamlit | Dashboard data | ArgoCD → k3s-worker01/02 |
| Flask | Application web simple | ArgoCD → k3s-worker01/02 |
Chaque application dispose de : - Un repo GitLab dédié - Un Dockerfile - Une CI/CD (test → build → scan → push → déploiement) - Un manifest Kubernetes (Deployment + Service + Ingress) - Des métriques Prometheus
Livrable : 3 applications déployées et accessibles via app-*.mounik.ovh.
Phase 7 — Pipeline DevSecOps complet
Objectif : Pipeline CI/CD avec validation de sécurité, visible dans DefectDojo.
Commit GitLab
│
├── [Test] pytest + lint
├── [SAST] Semgrep + Bandit → DefectDojo
├── [Build] Docker build
├── [SCAN] Trivy → DefectDojo
├── [Push] Harbor (harbor.mounik.ovh)
├── [DAST] OWASP ZAP → DefectDojo
└── [Deploy] ArgoCD sync → k3s
Livrable : Pipeline complet avec rapports de vulnérabilités dans DefectDojo.
Schéma récapitulatif
Phase 1 ── Proxmox (3 nœuds cluster)
│
Phase 2 ── OpenTofu (10 VMs créées)
│
Phase 3 ── Ansible Hardening (SSH, UFW, Fail2Ban)
│
Phase 4 ── Ansible Services
│
├── 4.1 Vault
├── 4.2 Traefik + CrowdSec + Let's Encrypt
├── 4.3 Keycloak
├── 4.4 GitLab
├── 4.5 Harbor
├── 4.6 Monitoring (Prometheus/Grafana/Loki)
└── 4.7 DefectDojo
│
Phase 5 ── Kubernetes (k3s + ArgoCD + Runner)
│
Phase 6 ── Applications Python (FastAPI, Streamlit, Flask)
│
Phase 7 ── Pipeline DevSecOps (SAST/DAST/Trivy → DefectDojo)
Chaque phase est conditionnée par la réussite de la précédente. Le fichier phases.md sert de checklist de progression pour le projet.