Proxmox GitOps: 5 formas de automatizar tu clúster

GitOps en Proxmox funciona mejor cuando Git registra el estado previsto, la automatización aplica cambios predecibles y las personas siguen controlando las operaciones arriesgadas. En Proxmox VE 9.2, una pila GitOps práctica puede usar Terraform u OpenTofu para la infraestructura, Ansible para la configuración y pipelines de CI para la revisión y la ejecución.

Aquí lo que más importa es el alcance. GitOps es una forma de operar la infraestructura a partir de un estado deseado versionado, con cambios revisados y aplicados mediante automatización. Debería facilitar la recuperación y el control de cambios. Si convierte un clúster sencillo en cinco capas de YAML que nadie entiende, el diseño ha fracasado.

Esta guía se basa en la documentación de Proxmox VE 9.2 y en los proyectos de automatización actuales a fecha de 15 de agosto de 2026. Separo a propósito las capacidades documentadas de las cosas que un pipeline técnicamente podría hacer pero que probablemente no debería hacer sin supervisión.

¿Qué significa GitOps para Proxmox?

GitOps significa que la configuración que pretendes ejecutar se guarda en Git y que los cambios pasan por un flujo de trabajo controlado antes de que la automatización los aplique. El repositorio se convierte en un registro auditable de lo que debería existir y de por qué cambió.

No hace falta reconciliar cada ajuste de Proxmox cada minuto. Un homelab puede usar un flujo de Git ligero, mientras que una plataforma de producción puede añadir pull requests, validación, aprobaciones y promoción entre entornos. Para cada ajuste, pregúntate si la reconciliación automática lo haría más seguro.

Antes de añadir una capa GitOps, construye una base predecible con la guía de instalación de Proxmox y una estrategia de backup de Proxmox probada.

1. ¿Cómo puede GitOps aprovisionar VMs y LXC en Proxmox?

El primer patrón útil de GitOps es el aprovisionamiento declarativo de máquinas virtuales y contenedores. Terraform u OpenTofu pueden describir en código el nombre de la VM, la CPU, la memoria, los discos, las interfaces de red, las etiquetas y los ajustes de inicialización.

El proveedor de Proxmox de BPG expone recursos para VMs y contenedores LXC de Proxmox VE. Su guía de cloud-init muestra cómo adjuntar datos de inicialización a una VM en el momento de crearla.

Eso te da un flujo de trabajo limpio:

1. Un ingeniero cambia la definición de la infraestructura.
2. Una pull request muestra exactamente qué ha cambiado.
3. La validación se ejecuta antes de que nada toque el clúster.
4. Un pipeline aprobado aplica el cambio.
5. Git registra la configuración deseada y el historial de revisiones.

Este patrón es especialmente útil para entornos de desarrollo, entornos por rama, clústeres de laboratorio y roles de servidor estandarizados.

El principal peligro es la deriva de configuración. Si la gente sigue redimensionando a mano en la GUI de Proxmox VMs gestionadas por Terraform, el siguiente plan puede intentar revertir esos cambios. Deja claro quién manda en cada campo, de forma que lo controle o el código o una persona a mano.

2. ¿Cómo encaja Ansible en GitOps con Proxmox?

Ansible encaja de forma natural después del aprovisionamiento porque puede configurar tanto la infraestructura de Proxmox como los sistemas operativos que se ejecutan dentro. La colección actual community.proxmox contiene módulos para instancias, VMs KVM, clústeres, ACL, pools y objetos SDN.

Prefiero mantener las responsabilidades simples: Terraform crea la infraestructura, Ansible configura los sistemas, y Git y la CI controlan cuándo se ejecuta cada capa.

Por ejemplo, una pull request podría añadir una nueva VM de monitoreo. Terraform la crea a partir de una plantilla estándar, cloud-init le da identidad de red y una clave SSH, y Ansible instala el software de monitoreo, aplica la configuración y la registra en el resto del entorno. Esa secuencia es más fácil de depurar que una sola herramienta gigante que intenta gestionar todas las capas.

Ansible también puede crear clústeres de Proxmox y unir nodos a ellos con el módulo community.proxmox.proxmox_cluster. Aun así, yo pondría los cambios de pertenencia al clúster detrás de una aprobación explícita, porque Corosync y el quórum son malos sitios para una reconciliación continua a la ligera.

3. ¿Puede GitOps gestionar plataformas de aplicaciones sobre LXC?

Sí, y aquí es donde proyectos como Proxmox-GitOps se vuelven interesantes. El proyecto se describe como un entorno GitOps autónomo para aprovisionar y orquestar Linux Containers en Proxmox VE, y en sus requisitos figuran Proxmox VE 8.4 hasta 9.2.

Su modelo trata un monorrepositorio como el estado deseado y usa un pipeline de varias etapas para arrancar y desplegar la infraestructura de contenedores. También usa Ansible como parte del aprovisionamiento de contenedores. En conjunto, eso convierte el proyecto en un modelo operativo, más que en una colección de scripts.

La ventaja es la reproducibilidad: un contenedor debería poder sustituirse a partir del código en lugar de repararse a mano durante años.

El coste es la abstracción. Cuando el pipeline falla, necesitas entender Git, la CI, la autenticación de Proxmox, el comportamiento de LXC, la red y la herramienta de configuración que hay debajo. Si solo una persona entiende la pila, has automatizado el factor autobús.

Para despliegues de aplicaciones más sencillos, la guía de Proxmox Helper Scripts puede ser más adecuada. GitOps justifica su complejidad cuando la repetibilidad y el control de cambios importan más que la rapidez de la puesta en marcha.

4. ¿Deberían las actualizaciones partir de Git?

Git es un buen lugar para declarar la política de actualizaciones, pero las actualizaciones desatendidas en todo un clúster de Proxmox necesitan barreras de protección. Los cambios de versión pueden afectar al kernel, a QEMU, al comportamiento del almacenamiento, a los drivers y a los servicios del clúster.

Un patrón más seguro es guardar la política y el flujo de trabajo en Git y mantener la ejecución por etapas.

Por ejemplo, define qué repositorio usa un nodo, a qué grupo de mantenimiento pertenece, qué comprobaciones previas tiene que superar y si hay que migrar las cargas de trabajo antes de un reinicio. El pipeline puede preparar el cambio, ejecutar las comprobaciones y detenerse a esperar aprobación antes de tocar producción.

Proxmox VE 9.2 añade controles para armar y desarmar la HA durante el mantenimiento planificado. Son útiles en la operación, pero sigues necesitando entender qué cambia la actualización.

También evitaría convertir "latest" en el estado deseado sin más matices. La automatización de infraestructura debería apuntar a un conjunto de paquetes revisado o a una ventana de versiones aprobada, en lugar de perseguir cambios solo porque un repositorio los ha publicado.

5. ¿Cómo puede GitOps mejorar la recuperación ante desastres?

GitOps aporta más valor en la recuperación cuando el repositorio contiene suficiente información para reconstruir la infraestructura sin depender de que alguien recuerde cada ajuste. Las definiciones de VMs, la intención de red, las asignaciones de roles, la configuración de los invitados y los scripts de despliegue pueden reducir el tiempo de recuperación.

Aun así, Git no sustituye a una copia de seguridad de VM. Un repositorio no va a restaurar el disco de una base de datos, un volumen de sistema Windows ni un dataset de LXC. Mantén separadas las copias de seguridad de las cargas de trabajo y pruébalas. La guía de backup de Proxmox cubre la parte de la recuperación que el código de infraestructura no puede sustituir.

Me gusta pensar en la recuperación en dos capas: Git reconstruye el esqueleto y las copias de seguridad restauran los datos con estado. Esa visión también sugiere una prueba útil. Si tu host Proxmox desaparece, ¿puede un administrador nuevo leer el repositorio y entender cómo reconstruir el entorno? Si la respuesta es no, puede que tu código esté automatizado, pero tu proceso de recuperación no está documentado.

¿Qué no debería automatizar nunca a ciegas GitOps en Proxmox?

No empieces reconciliando de forma continua la destrucción de almacenamiento, la topología de Ceph, la pertenencia al quórum, el comportamiento de fencing de la HA, la política del firewall ni las credenciales privilegiadas. Esas áreas tienen un radio de impacto grande.

Pon las acciones destructivas detrás de una revisión y usa credenciales separadas para leer, planificar y aplicar cuando tus herramientas lo permitan. Protege los secretos fuera del repositorio y prueba los cambios en un entorno que no sea de producción.

El acceso a la API también es poder. Las herramientas de la comunidad pueden ser excelentes, pero cada token debería tener los permisos mínimos que exige su trabajo.

¿Qué pila GitOps para Proxmox montaría yo?

La mantendría pequeña. Git aloja el estado deseado y el historial de revisiones, Terraform u OpenTofu aprovisiona VMs y LXC, Ansible se encarga de la configuración y un runner de CI hace la validación y las aplicaciones aprobadas. Proxmox Backup Server u otra plataforma de backup probada protege las cargas de trabajo con estado.

La reconciliación automática de cada objeto del clúster puede esperar. Automatiza primero el trabajo aburrido y repetible: aprovisiona una VM de prueba, reconstrúyela desde cero, añade la configuración y demuestra que una segunda persona puede entender el pipeline. Cuando eso funcione, amplía el alcance.

Un equipo pequeño con diez VMs estables puede no necesitar GitOps en absoluto. La GUI de Proxmox, los procedimientos documentados y las copias de seguridad pueden ser un sistema mejor que una plataforma de automatización que nadie mantiene. GitOps empieza a aportar valor cuando la frecuencia de cambios, la escala o los requisitos de recuperación justifican la maquinaria adicional.