Tuxvador's Blog
Présentation de WorkItOut — Trouve ton partenaire de sport Rapports quotidiens automatisés CrowdSec par e-mail Gestion programmatique du DNS avec l'API IONOS Premiers pas avec Proxmox VE pour votre laboratoire maison Mon Homelab Proxmox VE : Aperçu de l'infrastructure
EN

Mon Homelab Proxmox VE : Aperçu de l'infrastructure


Je construis et sécurise ma propre infrastructure depuis des années — en commençant avec un simple Raspberry Pi et en évoluant vers un cluster Proxmox VE complet. Ce qui a commencé comme un projet de bricolage est devenu un laboratoire domestique de qualité production qui héberge ce blog, des environnements de développement, des services multimédia, une surveillance de sécurité et un point d’accès VPN.

Cet article est la vue d’ensemble de haut niveau. Les articles suivants plongeront dans les composants individuels.

Le Matériel

Un nœud Proxmox VE unique tournant sur Debian 13 (Trixie) avec le noyau Proxmox VE. L’hôte se trouve sur mon réseau domestique avec une IP statique sur une interface bridge dédiée.

CPU:   x86-64
RAM:   Suffisante pour une douzaine de conteneurs LXC
Disque: Stockage LVM local pour les volumes des conteneurs
Réseau: Gigabit Ethernet, bridgé

J’ai opté pour les conteneurs LXC plutôt que les VM pour mes charges de travail d’infrastructure. LXC est plus léger, partage le noyau hôte et démarre en quelques secondes. Chaque conteneur a son propre système de fichiers, espace réseau et espace de processus — un isolement suffisant pour un homelab où vous faites confiance aux conteneurs que vous construisez.

La Topologie Réseau

Tous les conteneurs vivent sur un sous-réseau /24 privé derrière un bridge Proxmox. La passerelle est l’hôte Proxmox lui-même, qui gère le routage inter-conteneurs et fournit l’accès Internet en amont via le routeur domestique.

                  ┌──────────────┐
                  │ Routeur FAI  │
                  │  10.x.x.1    │
                  └───────┬───────┘
                         │
                  ┌──────┴───────┐
                  │ Hôte Proxmox │
                  │  Bridge/NAT  │
                  └──────┬───────┘
                         │
              ┌──────────┼──────────┐
              │          │          │
         ┌夀───┴───┐ ┌───┴────┐ ┌───┴────┐
         │ dhcp   │ │ web    │ │ dev    │
         │ serveur│ │ proxy  │ │ serveur│
         └────────┘ └────────┘ └────────┘

Un serveur ISC DHCP dédié (couvert dans un article séparé) gère l’allocation des IP. Les conteneurs d’infrastructure obtiennent des réservations statiques, tandis qu’un pool dynamique couvre les conteneurs de test éphémères.

Rôles des Conteneurs

dhcp-srv (10.99.99.2)

Le serveur DHCP pour tout le réseau du laboratoire. Exécute ISC DHCP Server sur Debian 13. Tous les autres conteneurs obtiennent leurs IP depuis ici via des réservations statiques. ~3 Mo de RAM.

web-proxy (10.99.99.11)

Proxy inverse et terminaison TLS. Achemine le trafic externe vers les services internes en fonction des noms de domaine, gère la provision des certificats Let’s Encrypt via certbot. C’est le seul conteneur exposé (via du port forwarding) au monde extérieur.

dev-srv (10.99.99.20)

Environnement de développement exécutant des applications Node.js via PM2. Héberge ce blog, des applications web et divers projets annexes. Utilise nvm pour la gestion des versions de Node.

mon-srv (10.99.99.10)

Surveillance de sécurité et observabilité. Exécute une pile d’agrégation de journaux avec Loki et Promtail, une instance CrowdSec pour la détection d’intrusion, et Grafana pour les tableaux de bord. Gère également les emails via Postfix.

media-srv (10.99.99.13)

Services multimédia et streaming de fichiers.

file-srv (10.99.99.14)

Stockage de fichiers réseau.

vpn-srv (10.99.99.25)

Point d’accès VPN pour un accès distant sécurisé au réseau du laboratoire.

Pourquoi LXC plutôt que des VM ?

On me demande souvent pourquoi j’ai choisi les conteneurs LXC plutôt que des VM complètes pour cette configuration. Voici mon raisonnement :

  • Temps de démarrage : Les conteneurs démarrent en moins d’une seconde. Les VM complètes prennent 30 à 60 secondes.
  • Surcharge mémoire : Chaque conteneur ajoute ~50 Mo de surcharge RAM. Les VM ont besoin d’un OS complet — facilement 512 Mo minimum.
  • Gestion : Les commandes pct sont plus simples que la gestion des VM pour des charges de travail mono-service.
  • Sauvegarde : Les sauvegardes de conteneurs sont petites, rapides et peu coûteuses en disque.

La contrepartie est un isolement plus faible par rapport à une VM KVM. Dans un environnement homelab où je suis l’unique opérateur et où tout est sur un réseau de confiance, c’est un risque acceptable. Pour des scénarios multi-locataires ou de production, les VM (ou Kubernetes) seraient le bon choix.

Mode d’Accès SSH

Je n’utilise l’authentification par mot de passe nulle part. Les clés SSH sont injectées à la création du conteneur via le paramètre --ssh-public-keys de Proxmox, qui écrit la clé lors de l’extraction du modèle. Cela signifie :

  • Chque conteneur recçot ma clé SSH dC¨s le premier jour
  • Pas d’invite de mot de passe, pas de credentials temporaires à faire tourner
  • Si un conteneur doit «tre reconstruit, c’est pct destroy && pct create et je suis de retour en quelques secondes

Documentation

Chaque conteneur, son IP, son adresse MAC, son objectif et uotes les particularités sont documentés dans le dépôt d’infrastructure du laboratoire sur GitHub. C’est crucial à mesure que le laboratoire grandit — j’ai perdu le compte du nombre de fois où J’ai dó m’y référer après ne pas avoir touché à un conteneur pendant six mois.

Les IDs de conteneurs dans Proxmox n’ont aucun rapport avec les adresses IP. J’utilise un document de correspondance qui ressemble à :

ID  │ Hostname    │ IP             │ Rôle
────┼─────────────┼────────────────┼──────────────
200 │ dhcp-srv    │ 10.99.99.2     │ Serveur DHCP
201 │ mon-srv     │ 10.99.99.10    │ Surveillance
202 │ web-proxy   │ 10.99.99.11    │ Proxy inverse
...

Prochaines Étapes

Ce laboratoire est un travail en constant progrès. Les projets à venir incluent :

  • Mettre en place des règles de pare-feu appropriées pour le trafic inter-conteneurs
  • Automatiser le provisionnement des conteneurs avec Ansible
  • Ajouter un deuxième nœud Proxmox pour la haute disponibilité
  • Documenter chaque service en détail (en commençant par l’article sur le DHCP)

Restez à l’ã©coute pour des plongées approfondies dans chaque composant.