portfolio

homelab

Home lab

Infrastructure personnelle conçue, déployée et documentée de bout en bout : virtualisation résiliente, sécurité réseau, accès distant chiffré et versioning des configurations.

Architecture réseau

Architecture réseau du home labSchéma de l'infrastructure : double NAT, cluster Proxmox à deux nœuds avec témoin de quorum, services conteneurisés et accès distant par VPN mesh.InternetBox opérateurNAT 1 · IP publiqueRouteur personnelNAT 2 · DHCP · pare-feuSwitchLAN 192.168.1.0/24Cluster Proxmox VE — 3 votes de quorumpve1Proxmox VE · x86_64Raspberry PiQDevice · 3ᵉ votepve2Proxmox VE · x86_64corosyncMachines virtuelles et conteneurs LXC / DockerPi-holeLXC · pve1CaddyLXC · pve1ZabbixLXC · pve1GiteaDocker · pve2FossFLOWDocker · pve2Bot DiscordDocker · pve2Poste ou mobileAccès distantTailscaleWireGuard meshTraverse les deux NATaucune redirection de portMatériel physiqueVM / conteneurFlux réseau filaireTunnel chiffré WireGuard
Topologie du home lab : cluster Proxmox à deux nœuds renforcé par un témoin de quorum, services conteneurisés, et accès distant par VPN mesh.
Description textuelle du schéma :
  1. Internet arrive sur la box de l’opérateur, qui réalise une première traduction d’adresses (NAT 1) et porte l’adresse IP publique.
  2. La box alimente un routeur personnel, qui réalise une seconde traduction d’adresses (NAT 2) et assure le DHCP et le pare-feu du réseau interne. Cette superposition constitue le double NAT.
  3. Le routeur est relié à un switch, qui distribue le réseau local 192.168.1.0/24.
  4. Le switch dessert trois machines : deux serveurs Proxmox VE x86_64 nommés pve1 et pve2, et un Raspberry Pi.
  5. Les trois machines forment un cluster Proxmox à trois votes de quorum : pve1 et pve2 apportent un vote chacun, le Raspberry Pi apporte le troisième en tant que QDevice Corosync. Le Pi n’héberge aucune machine virtuelle.
  6. pve1 héberge les conteneurs LXC Pi-hole (DNS et filtrage), Caddy (reverse proxy) et Zabbix (supervision).
  7. pve2 héberge les conteneurs Docker Gitea (forge Git), FossFLOW (schémas d’infrastructure) et le bot Discord.
  8. Un poste ou un mobile distant se connecte via Tailscale, un VPN mesh fondé sur WireGuard. Le tunnel chiffré rejoint directement les services hébergés sans traverser les deux NAT, ce qui évite toute redirection de port.

Services déployés

Services déployés
ServiceRôleHébergementStatut
Cluster Proxmox VESocle de virtualisation haute disponibilitéDeux nœuds x86_64 + Raspberry PiEn production
Pi-holeDNS local et blocage publicitaire réseauConteneur LXC sur ProxmoxEn production
CaddyReverse proxy et terminaison HTTPSConteneur LXC dédié sur ProxmoxEn production
TailscaleVPN mesh pour l’accès distantAgent sur les hôtes et conteneursEn production
GiteaForge Git auto-hébergéeConteneur DockerEn production
FossFLOWDocumentation visuelle de l’infrastructureConteneur DockerEn production
Bot DiscordAutomatisation et notificationsDocker (comparé à LXC, VM et machine physique)En production

Méthode appliquée à chaque projet

Chaque brique suit la même démarche, ce qui garantit la traçabilité des décisions techniques et rend chaque déploiement reproductible.

  1. 01

    Contexte et objectif

    Identifier le besoin réel — sécurité, disponibilité, productivité — avant de choisir un outil. L’outil découle du besoin, jamais l’inverse.

  2. 02

    Étude des prérequis

    Dimensionner processeur, mémoire, stockage et réseau, puis choisir l’environnement d’hébergement (LXC, Docker, VM ou physique) en fonction de la charge attendue.

  3. 03

    Installation documentée

    Rédiger les procédures au fur et à mesure du déploiement — scripts, docker-compose, commandes — de sorte qu’elles soient reproductibles à l’identique.

  4. 04

    Configuration et sécurisation

    Appliquer systématiquement les mêmes règles : adresse IP fixe, pare-feu, mots de passe forts, double authentification, HTTPS, moindre privilège.

  5. 05

    Vérification et tests

    Éprouver la résilience par des scénarios explicites : panne d’un nœud, perte d’un service, coupure DNS, accès distant depuis l’extérieur.

  6. 06

    Documentation et archivage

    Consigner chaque projet dans une fiche structurée — contexte, prérequis, installation, configuration, bonnes pratiques, dépannage, checklist — centralisée dans une base de connaissances unique.

  7. 07

    Maintenance continue

    Mises à jour, supervision, sauvegardes et améliorations sont consignées dans la même fiche : l’historique des décisions reste au même endroit que la procédure.

~/methode — principe

« Documenter en construisant » : la fiche technique est rédigée pendant le déploiement, pas après. Une fois le service stabilisé, elle est archivée et reste consultable comme référence.

Cluster Proxmox VE

Deux nœuds x86_64 + Raspberry Pi

Objectif — Obtenir un quorum stable à trois votes sans acheter un troisième serveur complet : deux nœuds x86_64 (pve1, pve2) sont complétés par un Raspberry Pi jouant le rôle de témoin de quorum Corosync. Sans ce troisième vote, l'arrêt d'un seul nœud suffirait à faire perdre le quorum au cluster.

Tests réalisés

  • Arrêt volontaire d'un nœud : vérification du maintien du quorum et de la bascule des services.
  • Perte du QDevice seul : le cluster conserve deux votes sur trois et reste opérationnel.
  • Scénario combiné (nœud + QDevice) : validation du comportement attendu en perte de quorum.

Bonnes pratiques

  • Adresses IP fixes sur les trois machines.
  • Raspberry Pi raccordé en Ethernet et non en Wi-Fi : le témoin de quorum ne doit pas dépendre du sans-fil.
  • Onduleur sur le cluster.
  • Supervision via Zabbix.
  • Sauvegarde du répertoire /etc/pve/, qui porte toute la configuration du cluster.

Limites identifiées

  • Le Raspberry Pi ne porte aucune machine virtuelle : ce n'est pas un troisième nœud, seulement un arbitre.
  • Évolution prévue vers un cluster à trois nœuds réels.

Pile technique

  • Proxmox VE
  • Corosync
  • corosync-qnetd
  • corosync-qdevice
  • Raspberry Pi

Pi-hole

Conteneur LXC sur Proxmox

Objectif — Filtrer la publicité et le pistage au niveau du réseau plutôt que sur chaque appareil. Pi-hole agit comme trou noir DNS : tout équipement du réseau est protégé sans installation locale, y compris ceux sur lesquels on ne peut rien installer (téléviseurs, objets connectés).

Sécurisation

  • Adresse IP statique obligatoire : un serveur DNS qui change d’adresse coupe tout le réseau.
  • Pare-feu (UFW) restreint aux seuls ports DNS et administration web.
  • Mot de passe administrateur changé dès l’installation.
  • Niveau de confidentialité des journaux ajusté selon le contexte (usage personnel ou conformité RGPD).

Bonnes pratiques

  • Choix du LXC plutôt que d’une VM : démarrage quasi instantané et empreinte mémoire de 300 à 400 Mo.
  • Dimensionnement de 512 Mo (petit réseau) à 4 Go de RAM selon le volume de requêtes DNS.

Pile technique

  • Pi-hole
  • LXC
  • Debian
  • UFW
  • DNS

Caddy

Conteneur LXC dédié sur Proxmox

Objectif — Accéder aux services internes par des noms de domaine lisibles (fossflow.memel.lab) plutôt que par des couples adresse IP / port. Le confort d'usage n'est pas le seul gain : un nom stable survit à un changement d'adresse ou de port du service sous-jacent.

Sécurisation

  • HTTPS local par `tls internal`, ou certificats via DNS Challenge Cloudflare.
  • Aucun port exposé sur Internet : l’accès distant passe par Tailscale, jamais par une redirection de port.

Bonnes pratiques

  • Séparation stricte des rôles : un LXC pour le DNS (Pi-hole), un LXC pour le proxy (Caddy).
  • Sous-domaines préférés aux sous-chemins : plus lisible, et évite les réécritures d’URL fragiles.
  • Sauvegarde régulière du Caddyfile, journaux suivis via journalctl.

Pile technique

  • Caddy
  • LXC
  • HTTPS
  • Cloudflare DNS
  • Let’s Encrypt

Tailscale

Agent sur les hôtes et conteneurs

Objectif — Atteindre l'ensemble du home lab à distance alors que l'installation est en double NAT — box opérateur puis routeur personnel. Dans cette configuration, la redirection de port est soit impossible, soit à demander à l'opérateur ; un VPN mesh basé sur WireGuard contourne le problème en établissant les connexions depuis l'intérieur du réseau.

Sécurisation

  • Double authentification activée sur le compte Tailscale : ce compte est la clé de toute l’infrastructure.
  • Listes de contrôle d’accès (ACL) restreignant les échanges entre appareils.

Bonnes pratiques

  • MagicDNS : accès aux machines par nom plutôt que par adresse.
  • Subnet Router : tout le réseau 192.168.1.0/24 est joignable depuis un unique point d’entrée, sans installer l’agent partout.

Pile technique

  • Tailscale
  • WireGuard
  • MagicDNS
  • Subnet Router

Gitea

Conteneur Docker

Objectif — Conserver la maîtrise du code, des scripts et de la documentation technique du home lab, sans dépendre d'un service tiers. Écrit en Go, Gitea tourne confortablement là où GitLab demanderait plusieurs gigaoctets de mémoire.

Sécurisation

  • Inscription publique désactivée : sans cela, une instance exposée se remplit de comptes automatisés.
  • Double authentification sur le compte administrateur.
  • Sauvegardes régulières du dossier de données.

Bonnes pratiques

  • Conteneur unique avec base SQLite embarquée et volumes persistants.
  • Dépôts organisés par domaine : homelab-configs, scripts-sysadmin, ad-setup, zabbix-templates, cours-bts.

Pile technique

  • Gitea
  • Docker
  • SQLite
  • Git

FossFLOW

Conteneur Docker

Objectif — Produire des schémas isométriques de la topologie réseau, du cluster Proxmox et de l'architecture Active Directory. Un schéma à jour rend une infrastructure explicable à un tiers — condition d'un vrai transfert de connaissances.

Bonnes pratiques

  • Diagrammes stockés en JSON sur le serveur, sauvegardés automatiquement.
  • Complémentarité assumée : FossFLOW pour l’isométrie 3D, Excalidraw pour les croquis 2D rapides.

Pile technique

  • FossFLOW
  • Docker
  • PWA
  • JSON

Bot Discord

Docker (comparé à LXC, VM et machine physique)

Objectif — Automatiser des notifications tout en servant de banc d'essai pour comparer concrètement les environnements de déploiement légers : Docker, LXC, machine virtuelle et machine physique, avec le dimensionnement processeur, mémoire et stockage de chacun.

Sécurisation

  • Secrets (jeton du bot) isolés dans un fichier .env, jamais versionné.

Bonnes pratiques

  • Architecture modulaire par Cogs : chaque fonctionnalité est un module rechargeable indépendamment.
  • Redémarrage automatique via `--restart always` ou une unité systemd.

Pile technique

  • Python
  • discord.py
  • Docker
  • systemd