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

Lo que funciona

• 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 pautas 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

Tips de Rendimiento

1. Pre-bakea dependencias en la imagen. Instalar paquetes npm o pip en startup añade 30-60s al tiempo de boot. Bakearlos en la imagen:

# En el build de la imagen
RUN npm ci --omit=dev
# En runtime, no se necesita instalación
CMD ["node", "server.js"]

2. Usa instancias EBS-optimized para boot de AMI más rápido. t3.medium y superior soportan EBS optimization, reduciendo latencia de first-boot en 10-20s.

3. Paraleliza builds de Packer para multi-región. Construye AMIs en todas las regiones simultáneamente:

build {
  sources = [
    "source.amazon-ebs.webapp_us_east_1",
    "source.amazon-ebs.webapp_us_west_2",
    "source.amazon-ebs.webapp_eu_west_1",
  ]
}

4. Usa skip_create_ami de Packer para testing. Valida el proceso de build sin crear un AMI real:

$ packer build -skip-create-ami packer.pkr.hcl

5. Cachea capas de Docker en CI. Acelera builds de imágenes cacheando capas:

- uses: docker/build-push-action@v5
  with:
    cache-from: type=gha
    cache-to: type=gha,mode=max