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.
Santé hôte, services, exposition, sauvegardes et capacité suivies par des signaux complémentaires.
PrometheusGrafanaLokiAlerting
Continuité & restauration
Savoir quoi restaurer, dans quel ordre et avec quelle preuve.
Sauvegardes VM quotidiennes, vérifications supervisées, restaurations logiques, RTO/RPO et runbooks.
PBSPRARTO/RPOVerify
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
Trois 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 de 26 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
- 49 services alignés, 47 images externes épinglées 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 ajout d'une santé locale du proxy.
- Résultat
- 69 cibles utiles, capacité suivie et aucune alerte 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
- Vérification de couverture, contrôle des tâches, définition des dépendances et objectifs de reprise par criticité.
- Résultat
- Couverture attendue confirmée, verify récent attesté, restaurations logiques réalisées et limites explicitement documentées.
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
- Restaurations logiques validées sur des services critiques sélectionnés
- 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 hors site ou immuable reste à mettre en œuvre et à tester.
- Un exercice complet Tier 1 chronométré reste nécessaire pour mesurer tous les RTO/RPO réels.
- 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.