EN
AperçuMatérielDéploiementServicesDonnées
← Mon Homelab

Mon homelab - Déploiement

Pour mon premier hyperviseur (en 2022 ou 2023), je m'étais dirigé vers ESXi. Malgré le rachat de VMware par Broadcom et le durcissement des licences, j'étais enthousiaste à l'idée de m'attaquer à un hyperviseur standard, largement déployé en entreprise.

Je l'ai donc installé sur ce qui était à l'époque mon unique noeud, et j'ai commencé à installer mes VMs, à partir d'un ISO Ubuntu 20.04. J'en ai créée une dédiée à mes services Docker, une autre avec GPU Passthrough pour entrainer des modèles de ML, une autre sur Windows pour jouer à des jeux vidéos...

C'était très long tout ça. Je devais configurer toutes les IPs à la main, gérer des bugs sombres de ESXi (et appliquer des solutions comme celle-là), gérer l'installation de drivers Nvidia en environnement virtualisés... Il m'a fallu des heures à éplucher des forums avant de comprendre qu'il fallait que j'installe la version kernel-open des drivers pour que ça fonctionne proprement avec GPU passthrough.

Une fois l'environnement en place, je me suis dit, "Ah, je vais ENFIN pouvoir me mettre à bosser sur mes projets". Et c'était vrai, j'ai pu avancer sur DealTracker. Et puis le temps passe.

  • Mon for intérieur: "T'es toujours sur Ubuntu 20.04, c'est toujours à jour et supporté ça ?"

  • Moi: Eh bien non.

  • Mon for intérieur: "Et peut être que tu aurais besoin de mettre à jour le driver Nvidia ?"

  • Moi: Hors de question ! J'ai déjà passé une éternité à le faire fonctionner la première fois, entre ça et Cuda, ça marchera pas out of the box, et puis j'ai autre chose de prévu cet aprem"

  • Mon for intérieur: "Et le partage de fichiers entre les VMs alors, il est bien efficace ? Samba c'était clairement pas une bonne idée, NFS ça a l'air plus adapté."

  • Moi: ...

Bienvenue dans un environnement logiciel paralysé par son état. Il se déprécie petit à petit face à l'évolution de la technique, et la clairvoyance de son auteur qui découvre de nouvelles méthodes. Cela constitue une dette technique chronophage, qui ralentit les projets et diminue la productivité. Il était temps de mettre un grand coup de balai et passer à autre chose.

Le switch vers Proxmox

Proxmox, ce petit paradis qui finit toujours par apparaître sur le chemin des homelabbers.

Quand j'ai acheté du nouveau hardware début 2026, j'ai regardé les licences ESXi plus en détail. La version gratuite a une API limitée et une limite à 8 vCPU par VM ? Vous vous moquez de moi ? C'est mon matériel, mon temps et il est hors de question que la pérennité de mon travail repose sur le bon vouloir d'une organisation motivée à me faire payer autant que possible.

Et c'est parti pour Proxmox.

Incroyable: ça marche. L'interface ? Intuitive. Le CLI propriétaire a disparu, tout repose sur Debian. Si tu as besoin de quelque chose, la communauté est riche et peut t'aider. Et bien sûr, s'il y a un truc que t'aimes pas, tu peux modifier le code par toi-même.

C'est une joie que de voir un écosystème open-source aussi riche et complet. Et avec ce nouveau départ, il était temps de mettre en place une solution bien plus robuste pour répondre à la paralysie logicielle que j'avais rencontrée sur ESXi. Tâchons d'apprendre des erreurs du passé.

Infrastructure as Code, déploiement Ansible, et stacks compose

Pour limiter le coût de mise en place de ces VMs et de la gestion de leur environnement, la clé se trouve dans l'automatisation.

En l'occurrence, trois automatisations distinctes:

1. La création des VMs, réalisée avec Terraform

J'utilise l'excellent provider bpg proxmox pour automatiser la création des VMs, en définissant leurs ressources hardware (incluant passthrough) et leur configuration réseau.

Désormais, si une VM a besoin d'un chipset I440FX au lieu de q35, ce n'est plus une note obscure écrite dans un coin puis oubliée, c'est une valeur déclarée et commentée dans le code.

2. Le provisioning des VMs, réalisé avec Ansible

Une fois les VMs provisionnées avec Terraform, il faut les configurer, c'est le rôle de Ansible. Il y a de nombreux rôles sur Ansible Galaxy qui permettent d'automatiser l'installation des composants, et ça, il faut absolument en profiter.

"Tiens tu vois ton installation de Nvidia en kernel open qui t'avais fait galérer ? Tu lances le rôle nvidia.nvidia_driver et BOUM tout est clean. Bon par contre, il faut coder toi-même le rôle qui ajoute l'undervolt à 450W, le rôle développé par Nvidia a pas forcément été pensé pour les homelabbers soucieux de leur matériel..."

Toute la configuration des VMs y passe. Les installation de docker, de certificats SSL, la configuration DNS, la gestion des disques...

3. Le déploiement des services avec Docker compose

Maintenant que les VMs sont installées avec toutes les dépendances, il n'y a plus qu'à déployer les services. Cela se fait naturellement avec Docker compose, il faut juste configurer les montages de volumes et la gestion du réseau.

Et voilà ! Une fois que ces éléments sont en place, la satisfaction est réelle. Alors on détruit l'environnement et on voit Proxmox nous montrer que toutes les VMs ont été supprimées. Puis on relance, et tout se fait tout seul. La création des VMs, les installations de drivers, gestions de certificat... et pouf. Ça marche. PiHole est disponible, Gitlab aussi. On peut regarder un film avec Jellyfin.

La grande victoire, c'est que ce déploiement est obtenu par l'application d'un process déclaratif et réplicable qui est versionné:

  • En cas d'erreur lors de l'ajustement de l'état, il est possible de stabiliser l'environnement en déployant une ancienne version
  • Une mise à jour se résume à changer une valeur dans le code.
  • Créer de nouvelles VMs, c'est ajouter quelques lignes de codes