Pourquoi construire un Enterprise Homelab ?

L’idée est partie d’un constat : dans mon métier, on manipule des patterns complexes (GitOps, Zero Trust, Kubernetes à l’échelle) qu’on peut rarement tester librement une fois en production. Alors j’ai décidé de me construire un terrain de jeu qui reproduit ces contraintes, sans les enjeux.

Cet article est une RFC (Request For Comments) : je vous expose ma démarche, mes choix d’architecture, et j’ouvre le débat.

Pourquoi un Homelab “Enterprise Grade” ?

On construit souvent des homelabs pour héberger ses médias (Plex) ou bloquer les publicités (Pi-hole). C’est très bien, mais ce n’est pas mon objectif ici.

Mon but, c’est un terrain de jeu aussi proche que possible de la production. Je veux pouvoir injecter des pannes, tester des mises à jour destructives et valider des architectures state-of-the-art (comme Talos Linux) sans risquer de faire tomber la prod d’un client. C’est l’application directe de la philosophie “Build, Break, Learn”.

L’Évolution du Matériel : Du Bricolage à l’Infrastructure

Pour être honnête, je ne pars pas de zéro. J’ai commencé “modeste”, comme beaucoup : un NAS Synology, deux Raspberry Pi et une Freebox pour orchestrer le tout. C’était fonctionnel, mais limité pour simuler de la haute disponibilité réelle.

Aujourd’hui, je change d’échelle. Mon nouveau “banc d’essai” se compose de :

  • Un serveur principal : une machine costaud (128 Go de RAM, RTX 4090) qui sert à la fois de nœud Kubernetes spécialisé pour les workloads gourmands et d’hôte pour des VMs dédiées.
  • 12 Lenovo ThinkCentre M720q : de quoi créer de véritables clusters et simuler des nœuds de compute distincts.
  • Réseau Enterprise : matériel gérant les VLANs pour une segmentation stricte (IoT, Guest, Lab, Prod).
  • La Fibre : indispensable pour l’hybrid-cloud.
  • La Stack : Talos OS tournant sur Proxmox VE.
  • Et quelques Raspberry Pi qui traînent, égarés entre deux switchs manageables, en attendant leur heure. Ou un article dédié.

Pourquoi autant de machines ? Parce que dans le Cloud, le node pool est une abstraction. Ici, je veux toucher du doigt les contraintes physiques : la gestion du quorum etcd, la répartition de charge et les échecs matériels.

La philosophie : GitOps, automatisation

“Tout doit être code” : parce que j’ai pas de mémoire, alors je compte sur le repo pour tout retenir.

  • Terraform pour provisionner les ressources.
  • Ansible pour configurer les machines sans y toucher.
  • Kubernetes pour déployer les apps.
  • ArgoCD pour le GitOps : tout est versionné, tout est reproductible.
  • SOPS + Age pour chiffrer les secrets et récupérer les données sensibles via un gestionnaire de mots de passe distant du repo.

Pourquoi cet attirail ? Parce que :

  1. Reproductibilité : un git pull, un make deploy et hop, le labo se reconstruit.
  2. Apprentissage : rien de tel que de casser son cluster K8s à 2h du mat’ pour comprendre vraiment comment ça marche.
  3. Partage : le repo peut être partagé avec d’autres passionnés.

Ce que cette série va couvrir

Cette série ne sera pas une suite de tutoriels “Hello World”. Elle suivra ma montée en compétences publique (Learning in Public) sur des sujets pointus. Le backlog au démarrage :

  1. Kubernetes “Hardened” : déploiement de Talos Omni sur du bare metal ou via Proxmox, en mode “Secure by Design” (chiffrement, TLS partout).
  2. GitOps à la maison : pourquoi j’utilise ArgoCD pour piloter mon infrastructure domestique comme une usine logicielle.
  3. Sécurité & Identité : pas de compte “admin/admin”. Intégration de SSO (OIDC) et gestion des secrets, car la sécurité ne doit pas être une option, même à la maison.
  4. Observabilité : monitoring via Prometheus/Grafana pour comprendre ce qui se passe vraiment sous le capot.
  5. IA dans le labo : Ollama, RAG, et mes tentatives de bricoler un “DevOps Copilot” local. Ce sera du POC, du peut-être. Je m’engage sur rien, mais ça promet d’être intéressant.