🌐 Aussi en: English · Deutsch · Español
😌 Petit avertissement : cet épisode, c’est le calme avant la tempête. GitLab et la VM Seed se sont révélés étonnamment simples – de l’infrastructure ennuyeuse, montée de façon ennuyeuse, et c’est voulu. Je le précise parce que le prochain article se passe en territoire Kubernetes – FluxCD, boucles de réconciliation GitOps et toutes les manières dont un cluster peut avoir l’air en pleine forme jusqu’au moment où il ne l’est plus du tout – et que celui-là a été un combat nettement plus rude. Voyez celui-ci comme la grande inspiration avant la plongée. 🤿 🦊 Tout homelab finit par atteindre le point où « je me connecte vite fait en SSH et je tape la commande à la main » cesse d’être charmant pour devenir un risque. Cet article raconte le moment où ce lab a franchi cette ligne : mettre en place GitLab comme source unique de vérité et construire une VM Seed dédiée, pour que « les outils de gestion de l’infrastructure » cessent de vivre sur le portable que j’ai sous la main ce jour-là. 💻➡️🗄️ Pour rattraper l’épisode précédent (en anglais) : Homelab Rebuild 2026: Building the Proxmox Cluster and Provisioning it with Terraform.🦊 GitLab : d’une machine bare metal à une vraie VM
GitLab tourne en fait dans ce homelab depuis un bon moment – simplement pas correctement. L’instance d’origine vivait directement sur le bare metal de HP3 (Debian, aucun hyperviseur dessous, pas de snapshots, pas de sauvegardes dignes de ce nom). Ça fonctionnait, mais c’était exactement le genre d’installation « provisoire » qui devient discrètement une infrastructure permanente dont tout le monde dépend. 😅 La solution : installer GitLab proprement dans une VM (HP1-gitlab01, 192.168.10.x, 12 Go de RAM, 120 Go de disque) via le paquet Omnibus standard – le dépôt apt officiel de GitLab, un seul paquet contenant GitLab lui-même avec PostgreSQL, Redis et NGINX intégrés, le tout configuré via un unique /etc/gitlab/gitlab.rb. C’est volontairement la voie d’installation ennuyeuse et bien balisée : c’est de l’infrastructure à laquelle je veux ne pas penser, pas une expérience de laboratoire. En interne, c’est du HTTP tout simple, sans TLS devant pour l’instant – acceptable pour une instance limitée au LAN, même si ça m’est revenu en pleine figure plus tard, quand le bootstrap de FluxCD a refusé d’envoyer des identifiants sur du HTTP non chiffré (une histoire pour un autre article 👀). La partie vraiment intéressante n’était pas l’installation neuve, mais le transfert des données de l’ancienne instance sans perdre l’historique. Les outils de sauvegarde/restauration de GitLab s’en sont chargés : un gitlab-backup create complet sur l’ancienne machine bare metal, l’archive obtenue plus le fichier de secrets de l’instance (gitlab-secrets.json) copiés, puis gitlab-backup restore sur la nouvelle VM avec une version de GitLab identique. Projets, issues et – point crucial – chaque branche de chaque dépôt sont arrivés intacts, y compris la branche internal de ce projet (celle qui contient les vrais identifiants et n’est jamais poussée sur le miroir GitHub public). J’ai fait dérouler à Claude toute la séquence export → transfert → import → vérification et confirmer que l’instance migrée correspondait réellement à l’ancienne avant que HP3 ne soit effacé. 🔍✅ Une fois la vérification faite, l’installation Debian bare metal de HP3 a été entièrement effacée et reconstruite en troisième nœud Proxmox VE – GitLab n’est donc pas seulement dans une VM, mais dans une VM du même cluster Proxmox que tout le reste, avec snapshots et sauvegardes PBS comme n’importe quelle autre charge de travail. Fini l’ambiance « pourvu que la machine bare metal ne lâche pas ». 🙏🌱 Entrée en scène de la VM Seed
GitLab détenant désormais la véritable source de vérité pour Terraform et Ansible, la lacune suivante sautait aux yeux : d’où lance-t-on réellementterraform apply et ansible-playbook ? « Depuis la machine qui a les outils installés ce jour-là » n’est pas une réponse, c’est un risque déguisé en imperméable. Donc : HP1-seed01 (192.168.10.x) – une petite VM Ubuntu ennuyeuse de 4 Go / 60 Go dont l’unique mission est d’être le seul endroit d’où partent les modifications de l’infrastructure. Entièrement construite par un playbook Ansible (02_ansible/playbooks/seed01.yml), donc reconstructible de zéro en quelques minutes, et non « de la façon dont je me souviens l’avoir configurée la dernière fois ». 🌱 Ce qu’on y trouve :- 🔧 git – sans version figée, aucune raison d’être pointilleux là-dessus
- 🏗️ Terraform, figé sur une version exacte (
1.15.8) via le dépôt apt officiel de HashiCorp – une modification d’infrastructure ne devrait jamais embarquer en douce une nouvelle version de Terraform en plein apply - 📜 Ansible lui-même, pour que la VM Seed puisse à terme exécuter des playbooks sur le reste de la flotte, elle-même comprise
- ☸️ kubectl, figé sur la version mineure du cluster RKE2 (actuellement
v1.36) via le dépôt apt officiel de Kubernetes - ⎈ Helm, figé sur une version exacte, récupéré directement depuis
get.helm.sh
kubectl nu et de s’arrêter là : il récupère le kubeconfig actuel directement sur le premier nœud control-plane du cluster, remplace l’adresse de loopback par l’IP réelle de ce nœud et l’installe pour les comptes ubuntu et user3. kubectl get nodes fonctionne dès la seconde où le playbook se termine, sans copier-coller de kubeconfig à la main. Ensuite, chaque compte reçoit un alias k pour kubectl avec l’autocomplétion bash complète – k get pods se complète donc avec Tab exactement comme kubectl get pods. Petit détail, mais des frappes économisées pour toujours. ⌨️ Les versions elles-mêmes sont centralisées à un seul endroit (group_vars/all.yml) : on augmente un numéro, on relance le playbook, et tous les outils se mettent à jour en même temps, selon ce dont le cluster a réellement besoin. Fini les moments « attendez, quelle version mineure de kubectl j’utilise, au juste ? ».
