HomeLab — Infrastructure
- Loïs Dutour
Table of Contents
Contexte
Il y a un an et demi, j’ai récupéré trois PC Tiny Lenovo et un Raspberry Pi 3+ pour monter un lab personnel. L’objectif n’était pas d’avoir un serveur qui tourne, c’était d’avoir un environnement où je peux tester, casser et recommencer sans impact.
Le matériel de départ n’était pas en état de marche. Flash BIOS sur le M710q (firmware daté de 2016), réparation des alimentations, remplacement de composants. Ça a commencé avant même d’installer le premier OS.
Matériel
| Machine | Modèle | CPU | RAM | Rôle |
|---|---|---|---|---|
| Node 1 | Lenovo M715q | AMD PRO | 16 Go | Nœud Proxmox VE |
| Node 2 | Lenovo M715q | AMD PRO | 16 Go | Nœud Proxmox VE |
| Services | Lenovo M710q | Intel | 16 Go | Services personnels (Docker) |
| QDevice | Raspberry Pi 3+ | ARM | 1 Go | Quorum + VPN + Supervision |
Architecture
Cluster Proxmox VE - Haute disponibilité à 2 nœuds
Les deux M715q forment un cluster Proxmox VE. Le problème classique d’un cluster à deux nœuds : le split-brain. Si les deux nœuds perdent la communication entre eux, chacun se croit seul survivant et tente de prendre le contrôle, résultat : corruption de données ou arrêt complet.
Solution retenue : le Raspberry Pi 3+ configuré en QDevice (Corosync Quorum Device). Il sert de tiers arbitre sans héberger de VMs, il ne fait que voter en cas de désaccord entre les deux nœuds. Ça permet d’avoir un quorum fonctionnel sans déployer un troisième serveur.
Ce setup est un PoC direct de ce qu’on retrouve dans les environnements de production pour les PCA/PRA, comprendre pourquoi le quorum existe et comment le configurer m’a plus appris beaucoup.
Pourquoi Proxmox et pas ESXi ?
J’avais commencé avec ESXi, qui reste plus user-friendly dans son interface, cependant deux raisons m’ont poussée à changer :
- La version disponible était bloquée en 6.7 dû à une carte réseau non compatible avec des versions plus récentes.
- Le rachat de VMware par Broadcom a changé la donne sur le prix des licences ainsi que les exigences hardwares. ESXi ne sera probablement plus le seul standard de l’industrie à moyen terme, d’autres prendront le relais (Nutanix, Hyper-V, Proxmox,…). Autant apprendre Proxmox maintenant.
La migration a demandé plus de bidouillage côté carte réseau que je ne l’anticipais. Proxmox est moins tolérant qu’ESXi sur la configuration réseau de sous réseaux.
Services personnels - M710q + Docker
Le troisième Tiny tourne en standalone avec Docker. Les services actuellement déployés :
- Vaultwarden: gestionnaire de mots de passe (compatible Bitwarden)
- Miniflux: lecteur RSS léger
- OpenProject: gestion de projets
- KitchenOwl: gestion des repas et courses
- Nextcloud: stockage et sync de fichiers (en cours de remise en route)
- Self-runner GitHub
Anciennement déployés (tests) : n8n, WordPress, Ollama + Open WebUI.
Stratégie de backup
Les points de montage Docker sont sauvegardés automatiquement chaque soir :
- Sur un disque dur externe branché localement
- Sur un VPS Oracle (Always Free) pour avoir une copie hors site
Règle 3-2-1 appliquée : 3 copies, 2 supports différents, 1 hors site. En cas de panne du M710q, les services sont redéployables rapidement depuis les sauvegardes.
Accès distant - WireGuard
Le Raspberry Pi héberge un serveur WireGuard. Tous les accès distants au lab passent par ce tunnel VPN. Aucun service n’est exposé directement sur internet.
Observabilité - Stack Grafana
La supervision centralisée tourne sur le Raspberry Pi :
- Grafana: dashboards et visualisation
- Loki: agrégation des logs
- Promtail: collecte et envoi des logs vers Loki
- VictoriaMetrics: stockage des métriques (alternative à Prometheus, moins gourmand en ressources sur le Pi)
Ce n’est pas uniquement pour avoir des dashboards, c’est une base concrète pour comprendre l’analyse de logs et la corrélation d’événements, ce qui est le socle de tout travail SOC ou SIEM.
Infrastructure as Code — Terraform + Ansible
Le déploiement et la configuration du lab sont progressivement migrés vers du code :
- Terraform (provider bpg/proxmox): provisioning des VMs sur le cluster
- Ansible: configuration des services et gestion de l’état des machines
Les playbooks et configurations sont versionnés sur GitHub : 👉 GitHub. 👉 Blog
Ce qui est en cours
Segmentation réseau — Le switch L3 n’est pas encore configuré. L’objectif est de segmenter le réseau en VLANs stricts :
| VLAN | Usage |
|---|---|
| Management | Accès administration Proxmox, SSH |
| Services | Services Docker exposés en interne |
| Lab | VMs de test isolées |
| DMZ | Services potentiellement exposés |
Le routage inter-VLAN sera assuré par VyOS. Ce chantier est le prérequis au déploiement du projet Wazuh SIEM sur une VM dédiée dans le VLAN Security.
Ce que ce projet m’a appris
Au-delà de la technique, ce lab m’a forcée à prendre des décisions : choisir entre deux solutions qui ont chacune des compromis, gérer une panne sans backup propre la première fois, comprendre pourquoi un service refuse de démarrer plutôt que juste relancer le conteneur.
C’est aussi un environnement qui évolue, il n’est jamais “terminé”, et c’est précisément ce qui le rend utile.
De plus, la segmentation entre services personnels et VMs de test m’évite de casser l’usage quotidien à chaque expérimentation, ce que j’aurais dû mettre en place bien plus tôt.