Arquitectura Multi-Servidor para Automatización y Deploy Continuo

Arquitectura Multi-Servidor para Automatización y Deploy Continuo

Arquitectura Multi-Servidor para Automatización y Deploy Continuo

Introducción

Cuando un proyecto de automatización crece más allá de un simple servidor, surge la necesidad de distribuir servicios estratégicamente: automatizaciones en un servidor, APIs de deploy en otro, herramientas de gestión en un tercero. Esta arquitectura distribuida no solo mejora la disponibilidad y el rendimiento, sino que permite escalar cada componente de forma independiente.

En este artículo exploramos una infraestructura real de cuatro nodos —dos VPS en la nube, un servidor local expuesto vía túnel Cloudflare y una máquina de desarrollo— que orquesta automatizaciones n8n, APIs de deploy, gestión de proyectos y desarrollo continuo.

Diseño de la Infraestructura

Diagrama de Red

La arquitectura se compone de tres capas:

  1. Capa Internet: Dos VPS públicos (VPS1 y VPS2) más un túnel Cloudflare que expone servicios locales
  2. Capa LAN: Servidor local (myLinuxServer) y laptop de desarrollo (myLab)
  3. Capa de Acceso: SSH configurado con aliases y túneles seguros
    4. INTERNET → [VPS1: OpenProject/Metabase] [VPS2: n8n] [Cloudflare Tunnel]
↓
[myLinuxServer: Deploy API]
↓
[myLab: Desarrollo]

Distribución de Servicios

VPS1 (86.38.204.129): Herramientas de gestión
  • OpenProject para Scrum boards y gestión de proyectos
  • Metabase para analytics y dashboards
  • EvoAPI para integraciones específicas
  • Puerto SSH 22 actualmente inaccesible (pendiente corrección)
VPS2 (86.38.204.88): Motor de automatizaciones
  • n8n production en n8n.varelainsights.com
  • Traefik como reverse proxy con SSL automático
  • PostgreSQL para persistencia de workflows
  • Redis para colas y cache
  • Puertos 22, 80 y 443 operativos
myLinuxServer (192.168.1.77): Deploy y sandboxes
  • API de deploy en api.varelainsights.cloud
  • Acceso SSH via ssh.varelainsights.cloud
  • Apps deployadas en deploy.varelainsights.cloud
  • Sandboxes aislados (av0004, er0002, gr0002) para clientes
  • Expuesto a internet vía Cloudflare Tunnel (sin abrir puertos en router)
myLab (192.168.1.8): Desarrollo local
  • Claude Code para desarrollo asistido por IA
  • n8n local para testing de workflows
  • Scripts de automatización y backup

Acceso Unificado con SSH Config

Una de las claves de esta arquitectura es la configuración centralizada de SSH en `~/.ssh/config`, que permite acceso directo con aliases simples:

Acceso directo a n8n production

ssh n8n

Acceso a servidor local via Cloudflare

ssh mylinuxserver-remote

VPS1 (actualmente fuera de línea)

ssh vps1

Esto elimina la necesidad de recordar IPs, usuarios o configuraciones de túneles. Cada comando SSH usa la configuración preestablecida de puertos, llaves privadas y opciones de conexión.

Gestión de Credenciales

La infraestructura distribuida requiere un sistema robusto de gestión de credenciales. En lugar de duplicar archivos `.env` en cada servidor, se centraliza la información:

Ubicaciones clave:

  • `scripts/.env`: Credenciales de Telegram, OpenAI, OpenRouter, Shopify
  • `config/apis/.apis_config`: APIs adicionales y tokens de servicios
  • `config/google/google-service-account.json`: Acceso a Google APIs
  • `~/.ssh/config`: Configuración de acceso SSH

Esta centralización permite que scripts de sincronización (`sync_claude_credentials.sh`) actualicen automáticamente las credenciales en todos los nodos cada 6 horas.

Monitoreo y Continuidad

Detección de Cambios de IP

Cuando se trabaja con VPS que pueden cambiar de IP (VPS económicos o tras mantenimiento), un script `ip-monitor.sh` verifica cada 5 minutos si la IP pública ha cambiado. Si detecta un cambio:

  1. Actualiza registros DNS vía API de Cloudflare
  2. Envía notificación a Telegram
  3. Actualiza archivos de configuración locales

Sincronización de Credenciales

El script `sync_claude_credentials.sh` ejecutado vía cron cada 6 horas:

  1. Lee credenciales desde ubicación central
  2. Genera archivos de configuración para Claude Code
  3. Actualiza variables de entorno en sandboxes activos
  4. Verifica conectividad con APIs críticas

Backups Estratificados

| Equipo | Método | Frecuencia | Destino |

|--------|--------|------------|----------|

| VPS2 | Pendiente implementación | - | - |

| myLinuxServer | backup_daily.sh | Diario | Disco externo + GDrive |

| myLab | rclone sync | Manual | Google Drive |

Casos de Uso Prácticos

Deploy de Cliente Nuevo

  1. Crear sandbox aislado en myLinuxServer: `create_sandbox.sh client_code`
  2. Configurar workflow en n8n (VPS2) para escuchar webhooks del cliente
  3. Deploy de API específica del cliente via api.varelainsights.cloud
  4. Registrar subdomain en Cloudflare apuntando al tunnel
  5. Actualizar OpenProject (VPS1) con nueva tarea de soporte

Testing de Workflow n8n

  1. Desarrollar workflow en n8n local (myLab)
  2. Exportar JSON del workflow
  3. Importar en n8n production (VPS2) via `import_n8n_workflow.py`
  4. Verificar conectividad con APIs desde VPS2
  5. Activar webhook y probar desde cliente

Monitoreo de Métricas

  1. n8n (VPS2) ejecuta workflows de scraping periódicos
  2. Datos se almacenan en PostgreSQL local del VPS2
  3. Metabase (VPS1) conecta a PostgreSQL de VPS2 via SSH tunnel
  4. Dashboards muestran métricas en tiempo real

Ventajas de la Arquitectura Distribuida

Aislamiento de fallos: Si VPS1 cae, n8n sigue ejecutando workflows y las APIs de deploy siguen operativas. Escalabilidad granular: Se puede escalar RAM/CPU de VPS2 (n8n) sin afectar VPS1 (OpenProject/Metabase). Costos optimizados: Servidor local (myLinuxServer) maneja deploys y sandboxes sin costo mensual de VPS adicional. Solo se paga el túnel Cloudflare (plan gratuito en este caso). Desarrollo ágil: myLab permite testing local de workflows y scripts antes de subirlos a production, sin afectar servicios en vivo. Seguridad en capas: SSH con llaves públicas, túneles Cloudflare cifrados, sandboxes aislados por cliente, credenciales nunca en repositorios git.

Conclusión

Esta arquitectura multi-servidor demuestra que no es necesario consolidar todo en un único VPS costoso. Distribuyendo estratégicamente —automatizaciones en un VPS, gestión en otro, deploy local vía túnel— se logra alta disponibilidad, costos controlados y flexibilidad para escalar cada componente según demanda.

Los tres elementos clave son: (1) SSH config unificado para acceso simple, (2) sincronización automatizada de credenciales, y (3) monitoreo continuo de IPs y servicios. Con estos pilares, gestionar cuatro nodos distribuidos se vuelve tan simple como trabajar en un único servidor.

Takeaways:

  • Usa SSH config para simplificar acceso a múltiples servidores con aliases memorables
  • Centraliza credenciales y sincroniza automáticamente cada 6 horas para evitar desincronización
  • Cloudflare Tunnel permite exponer servicios locales sin abrir puertos en router ni pagar IP estática
Regresar al blog

Deja un comentario