Skip to main content

Infraestructura Inmutable y Cloud-Init

Paradigma de gestión de servidores donde los servidores nunca se modifican manualmente después del despliegue: cualquier actualización o cambio de configuración se realiza mediante la creación de una nueva instancia estandarizada.

1. Visión general del concepto y problema sistémico

La administración manual tradicional a través de SSH conduce inevitablemente al caos:

  • Un ingeniero accede al servidor un viernes a las 10:00 PM, modifica urgentemente una línea en la configuración de Nginx, olvida documentarlo y se va a casa.
  • Seis meses después, el servidor necesita ser trasladado a otro hosting o escalado.
  • Se despliega un nuevo servidor siguiendo la antigua guía — ¡y nada funciona! Nadie recuerda qué paquetes se instalaron manualmente y qué permisos se otorgaron en /etc.

La Infraestructura Inmutable prohíbe para siempre la mutación de servidores en vivo: si es necesario cambiar al menos una configuración, no se modifica el servidor antiguo — se despliega una nueva instancia lista, se redirige el tráfico y se destruye la antigua.

2. Taxonomía arquitectónica y modelo mental

┌─────────────────────────────────────────────────────────────┐
│                 CICLO DE PROVISIONAMIENTO INMUTABLE        │
├─────────────────────────────────────────────────────────────┤
│ 1. INFRAESTRUCTURA COMO CÓDIGO (Repositorio Git):          │
│    • `cloud-init.yaml`: Endurecimiento de seguridad, UFW, Docker │
│    • `docker-compose.prod.yml`: Pila de aplicación          │
├─────────────────────────────────────────────────────────────┤
│                          │                                  │
│                          ▼ Activar: Provisionar Nuevo VPS (API) │
├─────────────────────────────────────────────────────────────┤
│ 2. INICIALIZACIÓN DE CLOUD-INIT (< 90 segundos en Hetzner): │
│    • Deshabilitar inicio de sesión root y autenticación por contraseña │
│    • Provisionar usuario no root `deployer` con claves SSH  │
│    • Asegurar UFW (permitir SOLO puertos 80, 443, WireGuard) │
│    • Instalar Docker Engine y daemon de Tailscale           │
├─────────────────────────────────────────────────────────────┤
│ 3. INTERCAMBIO DE TRÁFICO Y CAMBIO SIN TIEMPO DE INACTIVIDAD: │
│    • Healthcheck PASA ➔ Apuntar DNS / IP Flotante al NUEVO VPS │
│    • Terminar VPS ANTIGUO ➔ ¡Sin residuos, sin deriva!     │
└─────────────────────────────────────────────────────────────┘

3. Pipeline técnico y mecánica interna

01. Script de Cloud-Init de referencia para solicitar un VPS seguro

Se pasa en el campo User Data al crear el servidor:

#cloud-config
users:
  - name: orlov
    groups: sudo
    shell: /bin/bash
    sudo: ['ALL=(ALL) NOPASSWD:ALL']
    ssh_authorized_keys:
      - ssh-ed25519 AAAAC3NzaC1lZDI1NTE5...
package_update: true
packages:
  - ufw
  - fail2ban
  - docker.io
runcmd:
  - ufw default deny incoming
  - ufw default allow outgoing
  - ufw allow 22/tcp
  - ufw allow 80/tcp
  - ufw allow 443/tcp
  - ufw --force enable
  - systemctl enable --now docker

4. Escenarios prácticos de ingeniería en producción

01. Implementación de un VPS seguro con Cloud-Init

Utilizando el script anterior, se asegura que el VPS esté correctamente configurado desde el inicio, evitando configuraciones manuales que podrían llevar a errores.

02. Migración de servidores sin tiempo de inactividad

Al implementar un nuevo VPS, se puede redirigir el tráfico al nuevo servidor mientras se destruye el antiguo, garantizando una transición fluida y sin interrupciones.

03. Automatización del endurecimiento de seguridad

Mediante el uso de Cloud-Init, se puede automatizar el proceso de endurecimiento de seguridad, asegurando que cada nuevo servidor cumpla con las políticas de seguridad establecidas sin intervención manual.

5. Errores comunes, trampas y seguridad

  • Intento de mantener estado local en un servidor inmutable: Si una aplicación almacena archivos subidos por usuarios directamente en el disco local del servidor, esos archivos se perderán al reemplazar la instancia. Todo el estado del usuario debe almacenarse en almacenes dedicados (S3, Cloudflare R2) o bases de datos.
  • Errores en el script de inicialización: Si hay un error de sintaxis en el archivo cloud-init.yaml, el servidor se levantará sin acceso. Siempre pruebe las configuraciones de inicialización en máquinas de prueba económicas.
/ Preguntas frecuentesSchema.org FAQPage

FAQ: Infraestructura Inmutable y Cloud-Init

En el antiguo enfoque (Pets): cada servidor tiene un nombre único, el administrador lo repara manualmente durante años, teme reiniciarlo y se angustia si falla. En la infraestructura inmutable (Cattle): todos los servidores son copias idénticas numeradas. Si un servidor comienza a fallar, simplemente se destruye y se crea uno nuevo en 60 segundos mediante un script automático.
/ Enlaces internos
Todos los términos