Infraestructura Inmutable

Visión General

La infraestructura inmutable trata los servidores y despliegues como artefactos desechables que nunca se modifican después de su creación. En lugar de parchar máquinas en ejecución, construyes nuevas imágenes desde definiciones versionadas y reemplazas las instancias antiguas por completo. Esto elimina el configuration drift, hace los rollbacks triviales y asegura que cada ambiente — desde desarrollo hasta producción — ejecute stacks de software idénticos. Consulta estrategias de despliegue para patrones de rollback y blue-green deployment para swaps sin downtime.

Cuándo Usar

Usa este recurso cuando:

• El configuration drift causa problemas de “funciona en mi máquina” entre ambientes
• Necesitas despliegues reproducibles que pueden hacerse rollback cambiando IDs de AMI
• Auditores requieren cambios de infraestructura rastreables con control de versiones
• El escalado requiere lanzar instancias idénticas sin configuración manual

Solución

Packer + AWS AMI Build (JSON)

{
  "builders": [{
    "type": "amazon-ebs",
    "region": "us-east-1",
    "source_ami": "ami-12345678",
    "instance_type": "t3.micro",
    "ssh_username": "ubuntu",
    "ami_name": "webapp-{{timestamp}}"
  }],
  "provisioners": [{
    "type": "shell",
    "script": "setup.sh"
  }, {
    "type": "file",
    "source": "app.tar.gz",
    "destination": "/tmp/app.tar.gz"
  }]
}

Dockerfile para Container Inmutable

FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production

FROM node:20-alpine
WORKDIR /app
COPY --from=builder /app/node_modules ./node_modules
COPY . .
RUN addgroup -g 1001 -S nodejs && adduser -S nodejs -u 1001
USER nodejs
EXPOSE 3000
CMD ["node", "server.js"]

Terraform Blue-Green Deploy con AMI Inmutable

resource "aws_launch_template" "app" {
  name_prefix   = "app-"
  image_id      = var.ami_id
  instance_type = "t3.medium"

  tag_specifications {
    resource_type = "instance"
    tags = {
      Name = "app-server"
      AMI  = var.ami_id
    }
  }
}

resource "aws_autoscaling_group" "app" {
  desired_capacity    = 3
  max_size            = 10
  min_size            = 2
  vpc_zone_identifier = var.subnet_ids

  launch_template {
    id      = aws_launch_template.app.id
    version = "$Latest"
  }
}

Explicación

Principios core:

1. No SSH a producción: Si no puedes iniciar sesión, no puedes mutar
2. Versiona todo: Los IDs de AMI, digests de containers y estados de Terraform son referencias inmutables
3. Servidores Phoenix: Quema y reemplaza en lugar de parchar in situ
4. Imágenes golden: OS pre-baked + aplicación + dependencias como un único artifact

Inmutable vs. mutable:

Aspecto	Inmutable	Mutable
Método de update	Reemplazar instancia completa	Parchar sistema en ejecución
Rollback	Cambiar AMI / revertir despliegue	Deshacer parches manualmente
Drift	Imposible	Común
Tiempo de startup	Rápido (pre-baked)	Lento (provisioning)
Storage	Rootfs read-only	Writable en todas partes

Variantes

Tecnología	Caso de Uso	Características Destacadas
Packer	Imágenes multi-cloud	Una config → AWS, GCP, Azure, VMware
Docker	Imágenes de container	Layer caching; registries
NixOS	OS reproducible	Configuración declarativa; rollbacks
Flatcar	OS container-optimized	Actualizaciones automáticas; /usr read-only
Bottlerocket	AWS container OS	Superficie de ataque mínima; API-driven

Mejores Prácticas

• Almacena imágenes en registries: ECR, GCR, ACR o Docker Hub con tags inmutables
• Escanea imágenes antes del deploy: Trivy, Clair o Snyk en pipeline de CI. Para una guía dedicada, consulta escaneo de seguridad de containers.
• Tag imágenes con git SHA: myapp:abc1234 vincula artifacts a código fuente
• Usa read-only root filesystem: Los containers que no pueden escribir no pueden ser comprometidos fácilmente
• Separa datos de código: Adjunta volúmenes EBS o usa S3 para estado; nunca almacenes estado en la imagen

Errores Comunes

1. Containers mutables: Ejecutar apt-get install dentro de un container en ejecución anula la inmutabilidad
2. Tags latest: :latest es mutable y no determinístico; siempre fija digests o SHAs
3. Almacenar secrets en imágenes: Bakear credenciales en AMIs y containers crea exposición permanente. Sigue mejores prácticas de secrets management.
4. Olvidar data volumes: Un rootfs read-only significa que logs y uploads necesitan storage externo
5. Sin política de lifecycle de imágenes: Las imágenes viejas acumulan costos de storage y se convierten en liabilities de seguridad

Preguntas Frecuentes

P: ¿La infraestructura inmutable es más cara? R: Storage ligeramente mayor para imágenes, pero menor costo operacional debido a incidentes eliminados por drift.

P: ¿Cómo manejo patches de emergencia? R: Construye una nueva imagen con el patch, despliégala y decomisiona las instancias viejas. El proceso es idéntico a despliegues normales.

P: ¿Puedo usar infraestructura inmutable con bases de datos? R: Para servidores de app stateless, sí. Para bases de datos, usa configuración inmutable + volúmenes de datos persistentes, no datos inmutables. Aprende más en diseño de bases de datos.