Portada de la guía con el flujo: administrador, nodo PVE, proveedor de Terraform, VM o contenedor y validación
Flujo de trabajo

Portada editorial

Problema que resuelve. Declarar VMs como codigo usando autenticacion limitada y planes revisables.

Introduccion

Declarar VMs como codigo usando autenticacion limitada y planes revisables. Esta guia propone una implementacion incremental: primero registra el estado actual, despues introduce una configuracion minima, valida cada cambio y conserva una via de vuelta. El objetivo es que el procedimiento pueda adaptarse a un Cloud Server sin confundir una demostracion con una puesta en produccion.

Al terminar, la persona lectora podra reproducir el flujo, reconocer los puntos de control y decidir que pruebas adicionales necesita su carga real. Los nombres de dominio, usuarios, tokens, rutas y direcciones incluidos son ejemplos y deben reemplazarse.

Que se va a construir

La solucion conecta Administrador, Nodo PVE, Terraform provider, VM/CT y finalmente Validacion. Cada frontera se trata como un punto de seguridad y observabilidad: autenticacion minima, cifrado cuando corresponde, comprobacion de salud y registros suficientes para diagnosticar

Flujo de componentes: el administrador usa el proveedor de Terraform contra el nodo PVE para crear la VM y validarla
Flujo de componentes

Arquitectura de la solucion

Cuando conviene usarlo

  • Cuando varias personas o procesos necesitan repetir el mismo cambio con un resultado auditable.
  • Cuando el servicio deja de ser una prueba local y necesita recuperacion, monitoreo y control de acceso.
  • Cuando una falla parcial debe poder detectarse antes de afectar al usuario final.

Requisitos previos

  • Cloud Server Ubuntu 24.04 LTS o una distribucion compatible, actualizado y con acceso SSH mediante clave.
  • Usuario con sudo; sesion alternativa o consola del proveedor para cambios de red y servicios.
  • DNS y puertos preparados cuando la solucion expone HTTP, HTTPS, VPN o un protocolo de datos.
  • Backup o snapshot previo de configuraciones y datos; espacio suficiente para conservarlo fuera del host.
  • Ventana de mantenimiento y un criterio observable para decidir continuar o revertir.

Advertencia. Proxmox administra red, discos, identidades y cargas criticas. Ejecutar primero en laboratorio, mantener consola IPMI/KVM, backup verificado y un rollback escrito. No copiar comandos con IDs, IPs o discos de ejemplo sin reemplazarlos.

Paso 1: Relevar nodo, version y dependencias

Este paso establece una linea base verificable. Registrar la salida permite distinguir un problema previo de una regresion introducida por la guia.

pveversion -v
hostnamectl
pvesh get /nodes

Paso 1: relevar el nodo con pveversion -v, hostnamectl y pvesh get /nodes antes de tocar nada
relevamiento de nodos

Paso 1: Relevar nodo, version y dependencias

Como comprobarlo

Confirma que la orden termina sin error, que los archivos creados pertenecen al usuario esperado y que el componente Administrador aparece saludable. Revisa el journal o log de la herramienta antes de avanzar. Si la salida difiere de la documentacion citada, detente y valida la version instalada.

Paso 2: Respaldar configuracion y registrar estado

La configuracion se crea de forma explicita y con el menor alcance util. Sustituye los valores de ejemplo y conserva los permisos restrictivos.

stamp=$(date -u +%Y%m%dT%H%M%SZ)
mkdir -p /root/prechange-$stamp
cp -a /etc/network/interfaces /root/prechange-$stamp/ 2>/dev/null || true
pvesh get /cluster/resources --output-format json > /root/prechange-$stamp/resources.json

Paso 2: respaldar la configuración en /root/prechange con marca de tiempo y guardar el estado del clúster en JSON
Respaldo de configuracion

Paso 2: Respaldar configuracion y registrar estado

Como comprobarlo

Confirma que la orden termina sin error, que los archivos creados pertenecen al usuario esperado y que el componente Nodo PVE aparece saludable. Revisa el journal o log de la herramienta antes de avanzar. Si la salida difiere de la documentacion citada, detente y valida la version instalada.

Paso 3: Aplicar el cambio en alcance controlado

Antes de activar el cambio, revisa sintaxis, rutas, propietarios y dependencias. Una validacion local evita que un error de escritura llegue al servicio.

pveum user add terraform@pve
pveum role add TerraformRole -privs "VM.Allocate VM.Clone VM.Config.CDROM VM.Config.CPU VM.Config.Cloudinit VM.Config.Disk VM.Config.Memory VM.Config.Network VM.PowerMgmt Datastore.AllocateSpace Datastore.Audit"
pveum aclmod / -user terraform@pve -role TerraformRole
pveum user token add terraform@pve automation --privsep 1

Paso 3: crear el usuario terraform@pve, un rol con privilegios acotados y un API token con separación de privilegios
aplicar los cambios de alcance controlados.

Paso 3: Aplicar el cambio en alcance controlado

Como comprobarlo

Confirma que la orden termina sin error, que los archivos creados pertenecen al usuario esperado y que el componente Terraform provider aparece saludable. Revisa el journal o log de la herramienta antes de avanzar. Si la salida difiere de la documentacion citada, detente y valida la version instalada.

Control de seguridad. No pegues secretos reales en el historial de shell ni en capturas. Usa archivos con modo 0600, variables efimeras o el gestor de secretos de tu plataforma.

Paso 4: Validar sintaxis y estado

La activacion se hace con un cambio acotado. Observa inmediatamente estado, logs y consumo para detectar incompatibilidades.

terraform fmt -check
terraform validate
terraform plan -out=tfplan

Paso 4: validar con terraform fmt -check y terraform validate, y guardar el plan con terraform plan -out=tfplan
sintaxis y estado

Paso 4: Validar sintaxis y estado

Como comprobarlo

Confirma que la orden termina sin error, que los archivos creados pertenecen al usuario esperado y que el componente VM/CT aparece saludable. Revisa el journal o log de la herramienta antes de avanzar. Si la salida difiere de la documentacion citada, detente y valida la version instalada.

Paso 5: Probar la funcion y revisar logs

La prueba funcional debe recorrer el mismo camino que usara la aplicacion. Un proceso activo no garantiza que el servicio responda correctamente.

journalctl -p warning --since "15 min ago" --no-pager
pvesh get /cluster/tasks --limit 20
# Ejecutar una prueba funcional desde un cliente o VM de laboratorio.

Paso 5: revisar los avisos recientes con journalctl y las últimas tareas del clúster con pvesh get /cluster/tasks
probando el funcionamiento de los logs

Paso 5: Probar la funcion y revisar logs

Como comprobarlo

Confirma que la orden termina sin error, que los archivos creados pertenecen al usuario esperado y que el componente Validacion aparece saludable. Revisa el journal o log de la herramienta antes de avanzar. Si la salida difiere de la documentacion citada, detente y valida la version instalada.

Control de seguridad. No pegues secretos reales en el historial de shell ni en capturas. Usa archivos con modo 0600, variables efimeras o el gestor de secretos de tu plataforma.

Paso 6: Revertir o incorporar al mantenimiento

Cierra el ciclo con evidencia, rollback y mantenimiento. Documenta la version desplegada, la fecha y quien aprobo el resultado.

terraform plan -destroy
# Aprobar destroy solo sobre recursos gestionados y con backup.

Paso 6: planificar la reversión con terraform plan -destroy y aprobarla solo sobre recursos gestionados y con backup
revertir si no funciona, con terraform destroy

Paso 6: Revertir o incorporar al mantenimiento

Como comprobarlo

Confirma que la orden termina sin error, que los archivos creados pertenecen al usuario esperado y que el componente Validacion aparece saludable. Revisa el journal o log de la herramienta antes de avanzar. Si la salida difiere de la documentacion citada, detente y valida la version instalada.

Prueba de funcionamiento

Ejecuta la validacion desde un cliente distinto cuando haya red de por medio, fuerza un fallo controlado y comprueba que la senal aparece en logs o metricas. Luego restaura el componente y repite la operacion nominal. Conserva hora UTC, comando, resultado y version como evidencia de aceptacion.

Puerta de validación: configuración válida, servicio saludable, acceso mínimo, logs revisados y rollback disponible
validacion final

Puerta de validacion final

Problemas frecuentes

La configuracion valida pero el servicio no responde

Revisa binding, DNS, firewall, red de contenedores y permisos de lectura. Prueba primero desde localhost y luego desde el cliente real.

Permiso denegado o archivo inaccesible

Comprueba usuario efectivo, propietario, modo, contexto de servicio y rutas absolutas. No soluciones el problema con chmod 777.

El cambio funciona hasta reiniciar

Verifica enable, volumenes persistentes, orden de dependencias, variables disponibles para systemd y montaje de secretos.

La observabilidad no muestra datos

Confirma reloj, endpoint, etiquetas, credenciales y que el productor realmente genero trafico despues del despliegue.

Buenas practicas para produccion

  • Fijar versiones o digests y revisar notas de version antes de actualizar.
  • Aplicar minimo privilegio a usuarios, tokens, sockets, roles y rutas de escritura.
  • Separar configuracion, secretos y datos; respaldar cada capa con retencion definida.
  • Supervisar disponibilidad, latencia, errores y capacidad con alertas vinculadas a un runbook.
  • Ensayar restauracion y rollback periodicamente en un entorno aislado.
  • Documentar excepciones con responsable y fecha de vencimiento.

Servidores Dedicados con Proxmox VE by Donweb

Ya sabes crear las VMs por código. Ahora te falta el hierro donde ponerlas.
Virtualización en serio, con recursos 100% dedicados a tu cluster.

  • KVM + LXC con panel web integrado
  • Acceso root completo y control total del host
  • Sin vecinos ruidosos: CPU, RAM y discos exclusivos
  • Clustering, snapshots y alta disponibilidad
  • Datacenters propios en LATAM y facturación local

Monta tu nodo Proxmox dedicado