Home Lab • Infrastructure • Sécurité
Une infrastructure conçue pour être exploitée, pas seulement démontrée.
Mon Home Lab est une plateforme Proxmox à nœud unique, segmentée, supervisée et sauvegardée. Je l'utilise pour travailler la conception, l'exploitation, la sécurité et la reprise dans des conditions proches du réel.
L'objectif n'est pas d'accumuler des services. Chaque composant doit répondre à un besoin, produire un signal utile, disposer d'une source de vérité et pouvoir être restauré ou retiré proprement.
Architecture
Des frontières lisibles, des dépendances assumées
Cette vue reste volontairement fonctionnelle : aucun adressage, port interne, identifiant ou règle exploitable n'est publié.
Séparer les usages
Les flux d'administration, les services, l'exposition publique et l'IoT restent dans des zones fonctionnelles distinctes.
Observer avant d'agir
Métriques, logs, sondes et alertes donnent un état contradictoire avant et après chaque changement.
Préparer la reprise
Sauvegarde, hash, rollback et ordre de restauration sont définis avant les opérations à risque.
Modèle d'exploitation
Quatre capacités, reliées à des preuves
Les technologies sont des moyens ; l'objectif est de maintenir un service compréhensible et réversible.
Architecture & segmentation
Limiter les dépendances implicites et la surface exposée.
Publication centralisée, accès d'administration séparé et filtrage aux frontières fonctionnelles.
VLANVPNDNSReverse proxy
Observabilité utile
Détecter une panne réelle sans fabriquer de faux vert.
66 targets, 27 sondes, logs centralisés, alertes Grafana et notifications ntfy validées.
PrometheusGrafanaLokiAlerting
Continuité & restauration
Savoir quoi restaurer, dans quel ordre et avec quelle preuve.
PBS, copie USB hors ligne, vérifications SHA-256, restore validator, RTO/RPO et runbooks.
PBSUSB offsitePRARTO/RPO
Reproductibilité & sécurité
Réduire les changements manuels et conserver un retour arrière lisible.
Compose canoniques, images épinglées, validation locale, journaux, checksums et changements minimaux.
DockerGitHardeningRollback
Problème → méthode → résultat
Quatre améliorations menées de bout en bout
Chaque changement conserve son état initial, son retour arrière, ses validations et sa dette résiduelle.
Rendre Docker reconstructible
- Problème
- Les paramètres des projets devaient être comparés à l'état réellement exécuté.
- Méthode
- Inventaire, comparaison déclaratif/runtime, normalisation des Compose puis validation sans recréation globale.
- Résultat
- 44 services actifs, 42 images de registre et deux builds locaux identifiés.
Améliorer le signal de supervision
- Problème
- Des sondes redondantes ou mal positionnées pouvaient masquer les causes d'une indisponibilité.
- Méthode
- Suppression des doublons, contrôle des états Error/NoData et tests firing/resolved vers ntfy.
- Résultat
- 66/66 targets et 27/27 sondes, sans alerte active ni règle masquée pour obtenir artificiellement du vert.
Passer du backup au PRA
- Problème
- La présence de sauvegardes ne suffisait pas à démontrer une capacité de reprise.
- Méthode
- Couverture PBS, copie USB hors ligne, manifestes SHA-256, protections anti-collision et validation isolée.
- Résultat
- Couverture attendue confirmée, verify attesté, restore validator installé et rollback contrôlé.
Rétablir la continuité électrique
- Problème
- La télémétrie UPS existait via le NAS, mais une coupure ne produisait ni notification fiable ni action PVE.
- Méthode
- Chaîne SNMP vers Prometheus, garde persistant, SSH strict, helper limité et tests batterie/secteur simulés.
- Résultat
- Notifications critique/résolution reçues, préflight PVE valide et orchestration active sans déclencher d'arrêt réel.
PRA & limites
La crédibilité passe aussi par ce qui reste à faire
La sauvegarde est supervisée, mais elle n'est pas confondue avec une haute disponibilité ou un PRA entièrement éprouvé.
Ce qui est en place
- Sauvegardes quotidiennes des charges éligibles et contrôle de leur couverture
- Vérification PBS supervisée et échecs rendus visibles
- Copie USB hors ligne avec manifestes SHA-256 et support monté en lecture seule pour validation
- Restore validator isolé avec protections anti-collision et nettoyage contrôlé
- Ordre de reprise documenté avec dépendances réseau, DNS et publication
- Rollback applicatif et infrastructure préparé avant chaque changement
Limites publiquement assumées
- La plateforme repose sur un seul nœud Proxmox : elle n'est pas présentée comme hautement disponible.
- La copie USB hors ligne réduit le risque, mais sa rotation physique reste une discipline opérationnelle.
- L'arrêt électrique automatique réel n'est pas revendiqué : seuls les scénarios batterie/secteur sans shutdown ont été validés.
- La redondance DNS reste dépendante du même domaine matériel.
Plateforme physique
Une infrastructure réelle, documentée sans la surexposer
Pour aller plus loin
Voir les projets et les résultats détaillés
Les études de cas détaillent le contexte, la méthode, le résultat et les compétences démontrées, sans publier de données d'exploitation sensibles.