Gestion de nodos y despliegue operativo con Proxmox

La conversacion sobre automatizacion de infraestructura suele quedarse en la herramienta, pero la operacion real empieza mucho antes: capacidad de nodo, aislamiento, telemetria, seguridad de borde y una estrategia clara para publicar servicios sin exponer la red interna.

En un laboratorio serio, Proxmox resuelve la primera capa del problema porque permite combinar maquinas virtuales, contenedores LXC y redes definidas por software con un costo operativo razonable. No es solo virtualizacion. Es una forma de modelar el terreno donde despues viven los workers, los runners, los gateways y los planos de control.

Separar nodos por responsabilidad

Cuando se despliega automatizacion tecnica con varios servicios, conviene partir el sistema en tres dominios:

• Nodos de ejecucion para cargas operativas y procesos de automatizacion.
• Nodos de integracion para colas, webhooks y almacenamiento temporal.
• Nodos de observabilidad para logs, trazas y alertas.

Esa separacion evita que una carga con mucha superficie termine compartiendo credenciales o servicios administrativos sensibles. Tambien simplifica los planes de rollback cuando un experimento sale mal.

Proxmox como capa de orquestacion base

Mi enfoque habitual es usar Proxmox para definir plantillas base endurecidas:

qm clone 9001 210 --name ops-node-01 --full true
qm set 210 --memory 8192 --cores 4 --net0 virtio,bridge=vmbr10
qm start 210

Con una plantilla consistente se acelera la provision de nuevos nodos y se reduce la deriva de configuracion. Sobre esa base, Docker toma el relevo para empaquetar cada servicio, cada worker y cada dependencia de automatizacion.

Publicacion sin abrir la red: Cloudflare Tunnels

Uno de los errores mas comunes es exponer paneles, callbacks o interfaces internas con reglas NAT improvisadas. Para cargas operativas y servicios internos, Cloudflare Tunnels ofrece una salida mas limpia:

1. El nodo inicia el conector saliente.
2. Cloudflare publica el hostname.
3. El trafico entra sin abrir puertos en el perimetro local.

Eso no reemplaza la seguridad interna, pero reduce ruido en el borde y permite encapsular mejor servicios de control, paneles de auditoria o endpoints para aprobaciones humanas.

Un config.yml minimo suele bastar:

tunnel: infra-core
credentials-file: /etc/cloudflared/infra-core.json

ingress:
  - hostname: control.devosfernando.dev
    service: http://127.0.0.1:8080
  - hostname: hooks.devosfernando.dev
    service: http://127.0.0.1:9000
  - service: http_status:404

Automatizacion tecnica de verdad

La madurez llega cuando el sistema se puede reconstruir sin depender de memoria humana. Eso implica:

• Plantillas de Proxmox versionadas.
• Compose o manifests reproducibles.
• Secretos rotados y fuera del repositorio.
• Health checks y politicas de reinicio definidas.
• Un pipeline para promover cambios de laboratorio a produccion.

Si un servicio necesita acceso a repositorios, shells remotas o infra compartida, cada permiso debe existir por una razon concreta y quedar registrado. La operacion sin trazabilidad no escala; solo mueve el riesgo.

Cierre

La automatizacion no vive en el vacio. Necesita una base operacional que combine aislamiento, rapidez de despliegue y control. Proxmox, Docker y Cloudflare Tunnels encajan bien cuando el objetivo es iterar rapido sin sacrificar disciplina tecnica. La arquitectura correcta no es la mas vistosa: es la que permite crecer, fallar de forma contenida y reconstruir en horas, no en semanas.