🌐 También en: English · Deutsch · Français
😌 Aviso previo: esta entrega es la calma antes de la tormenta. GitLab y la VM Seed resultaron ser refrescantemente fáciles: infraestructura aburrida, montada de forma aburrida, a propósito. Lo menciono expresamente porque el próximo artículo es territorio Kubernetes –FluxCD, bucles de reconciliación de GitOps y todas las formas en que un clúster puede parecer perfectamente sano justo hasta el momento en que deja de estarlo– y esa fue una pelea bastante más dura. Considera este artículo la bocanada de aire antes de la inmersión. 🤿 🦊 Todo homelab llega a un punto en el que «entro un momento por SSH y ejecuto el comando a mano» deja de tener gracia y empieza a ser un riesgo. Este artículo trata del momento en que este lab cruzó esa línea: montar GitLab como única fuente de verdad y construir una VM Seed dedicada, para que «las herramientas para gestionar la infraestructura» dejen de vivir en el portátil que tenga a mano en ese momento. 💻➡️🗄️ Ponte al día con el episodio anterior aquí (en inglés): Homelab Rebuild 2026: Building the Proxmox Cluster and Provisioning it with Terraform.🦊 GitLab: de una máquina bare metal a una VM como es debido
En realidad, GitLab lleva ya un tiempo funcionando en este homelab, solo que no correctamente. La instancia original vivía directamente sobre el bare metal de HP3 (Debian, sin hipervisor debajo, sin snapshots, sin copias de seguridad dignas de ese nombre). Funcionaba, pero era justo el tipo de montaje «provisional» que, sin hacer ruido, se convierte en infraestructura permanente de la que todo el mundo depende. 😅 La solución: instalar GitLab como es debido en una VM (HP1-gitlab01, 192.168.10.x, 12 GB de RAM, 120 GB de disco) mediante el paquete Omnibus estándar: el repositorio apt oficial de GitLab, un único paquete que incluye GitLab junto con PostgreSQL, Redis y NGINX integrados, todo configurado a través de un único /etc/gitlab/gitlab.rb. Es a propósito el camino de instalación aburrido y trillado: es infraestructura en la que quiero no pensar, no un experimento de laboratorio. Internamente usa HTTP a secas, todavía sin TLS delante; vale para una instancia solo de LAN, aunque más tarde me pasó factura cuando el bootstrap de FluxCD se negó a enviar credenciales por HTTP sin cifrar (una historia para otro artículo 👀). Lo realmente interesante no fue la instalación nueva, sino traer los datos de la instancia antigua sin perder el historial. De eso se encargaron las propias herramientas de copia de seguridad y restauración de GitLab: un gitlab-backup create completo en la vieja máquina bare metal, el archivo resultante más el fichero de secretos de la instancia (gitlab-secrets.json) copiados, y luego gitlab-backup restore en la nueva VM con la misma versión de GitLab. Proyectos, issues y –lo más importante– todas las ramas de todos los repositorios llegaron intactos, incluida la rama internal de este proyecto (la que contiene las credenciales reales y nunca se sube al mirror público de GitHub). Le pedí a Claude que recorriera toda la secuencia exportación → transferencia → importación → verificación y confirmara que la instancia migrada coincidía de verdad con la antigua antes de borrar HP3. 🔍✅ Una vez verificado, la instalación Debian bare metal de HP3 se borró por completo y se reconstruyó como tercer nodo de Proxmox VE. Es decir, GitLab ya no solo está en una VM: está en una VM dentro del mismo clúster de Proxmox que todo lo demás, con snapshots y copias de seguridad en PBS como cualquier otra carga de trabajo. Se acabó el rollo de «ojalá no se muera la máquina bare metal». 🙏🌱 Entra en escena la VM Seed
Con GitLab guardando la auténtica fuente de verdad de Terraform y Ansible, el siguiente hueco era evidente: ¿desde dónde se ejecutan realmenteterraform apply y ansible-playbook? «Desde la máquina que ese día tenga las herramientas instaladas» no es una respuesta, es un riesgo con gabardina. Así que: HP1-seed01 (192.168.10.x), una VM Ubuntu pequeña y aburrida de 4 GB / 60 GB cuyo único trabajo es ser el único sitio desde el que se hacen cambios en la infraestructura. Construida íntegramente por un playbook de Ansible (02_ansible/playbooks/seed01.yml), así que se puede reconstruir desde cero en minutos, y no «como recuerde haberla configurado la última vez». 🌱 Lo que se instala en ella:- 🔧 git: sin versión fijada, no hay motivo para ponerse quisquilloso
- 🏗️ Terraform, fijado a una versión exacta (
1.15.8) desde el repositorio apt oficial de HashiCorp: un cambio de infraestructura nunca debería pillar en silencio una nueva versión de Terraform a mitad de un apply - 📜 Ansible en sí, para que la VM Seed pueda ejecutar con el tiempo playbooks contra el resto de la flota, ella incluida
- ☸️ kubectl, fijado a la versión menor del clúster RKE2 (ahora mismo
v1.36) desde el repositorio apt oficial de Kubernetes - ⎈ Helm, fijado a una versión exacta, descargado directamente de
get.helm.sh
kubectl pelado y darlo por terminado: obtiene el kubeconfig actual directamente del primer nodo control-plane del clúster, sustituye la dirección de loopback por la IP real de ese nodo y lo instala para las cuentas ubuntu y user3. kubectl get nodes funciona en el mismo segundo en que termina el playbook, sin andar copiando y pegando un kubeconfig a mano. Segundo: cada cuenta recibe un alias k para kubectl con autocompletado completo de bash, así que k get pods se completa con el tabulador exactamente igual que kubectl get pods. Es una tontería, pero ahorra pulsaciones para siempre. ⌨️ Las versiones en sí están en un único sitio (group_vars/all.yml): subes un número, vuelves a ejecutar el playbook y todas las herramientas se actualizan a la vez, al ritmo de lo que el clúster necesita de verdad. Se acabaron los momentos de «a ver, ¿qué versión menor de kubectl estoy usando?».
