En la gestión de infraestructura tradicional, los servidores se actualizan constantemente: se aplican parches, se modifican configuraciones, se instalan nuevos paquetes. Con el tiempo, cada servidor diverge del resto, creando un estado único e irreproducible que nadie entiende completamente. La infraestructura inmutable propone una alternativa radical: los servidores nunca se modifican despues de su despliegue. Si se necesita un cambio, se construye una nueva versión de la imagen, se despliegan nuevas instancias y se destruyen las anteriores.

Infraestructura Mutable vs Inmutable

Para comprender el valor de la inmutabilidad, es necesario contrastarla con el enfoque mutable tradicional.

Infraestructura Mutable

En el modelo mutable, los servidores son entidades de larga vida que se mantienen mediante herramientas de gestión de configuración como Ansible, Chef o Puppet. Se hacen cambios in-place: se actualizan paquetes, se modifican archivos de configuración, se reinician servicios.

Problemas del enfoque mutable:

  • Configuration drift: Despues de meses de parches y cambios manuales, cada servidor tiene un estado ligeramente diferente. Un servidor de “producción” puede comportarse distinto a otro del mismo pool
  • Snowflake servers: Servidores unicos que nadie se atreve a tocar porque nadie sabe exactamente que tienen instalado
  • Rollback complejo: Revertir un cambio requiere saber exactamente que se modifico y en que orden, lo cual rara vez esta documentado por completo
  • Debugging difícil: Cuando un servidor falla, reproducir el problema en otro entorno es complicado porque el estado exacto es irreproducible

Infraestructura Inmutable

En el modelo inmutable, los servidores son efimeros y desechables. Toda la configuración esta preinstalada en una imagen (AMI, VM image, container image). Los despliegues consisten en reemplazar instancias viejas por nuevas.

Ventajas del enfoque inmutable:

  • Consistencia garantizada: Cada instancia creada desde la misma imagen es identica
  • Rollback trivial: Revertir es desplegar la imagen anterior
  • Estado conocido: El estado de cada servidor es exactamente lo que contiene la imagen
  • Seguridad mejorada: Sin acceso SSH a producción, la superficie de ataque se reduce drasticamente

Cattle vs Pets: El Cambio de Mentalidad

La analogia de “cattle vs pets” (ganado vs mascotas) captura la esencia del cambio cultural que requiere la infraestructura inmutable.

Mascotas (enfoque mutable): Cada servidor tiene nombre, personalidad y historia. Si se enferma, lo curas. Si muere, es una tragedia. Ejemplo: “el servidor de base de datos producción-db-01 que configuramos hace 3 anios”.

Ganado (enfoque inmutable): Los servidores son anonimos e intercambiables, identificados por números. Si uno falla, se reemplaza automáticamente por otro identico. Ejemplo: “una instancia del Auto Scaling Group que fue creada hace 2 horas desde la AMI v47”.

Este cambio de mentalidad es fundamental. No se trata solo de herramientas, sino de aceptar que ningun servidor individual es importante; lo que importa es la capacidad de recrear el servicio completo en cualquier momento.

Packer: Construir Golden Images

HashiCorp Packer es la herramienta estandar para crear golden images (imagenes doradas) que contienen todo lo necesario para ejecutar una aplicación: sistema operativo configurado, runtime, dependencias, agentes de monitoreo y la aplicación misma.

Template Basico de Packer

# golden-image.pkr.hcl
packer {
  required_plugins {
    amazon = {
      version = ">= 1.3.0"
      source  = "github.com/hashicorp/amazon"
    }
  }
}

source "amazon-ebs" "webapp" {
  ami_name      = "webapp-{{timestamp}}"
  instance_type = "t3.medium"
  region        = "us-east-1"

  source_ami_filter {
    filters = {
      name                = "al2023-ami-*-x86_64"
      root-device-type    = "ebs"
      virtualization-type = "hvm"
    }
    most_recent = true
    owners      = ["amazon"]
  }

  ssh_username = "ec2-user"

  tags = {
    Name        = "webapp-golden-image"
    Environment = "production"
    ManagedBy   = "packer"
    BuildTime   = "{{timestamp}}"
  }
}

build {
  sources = ["source.amazon-ebs.webapp"]

  # Instalar dependencias del sistema
  provisioner "shell" {
    inline = [
      "sudo dnf update -y",
      "sudo dnf install -y nodejs20 nginx",
      "sudo systemctl enable nginx"
    ]
  }

  # Copiar configuracion de nginx
  provisioner "file" {
    source      = "configs/nginx.conf"
    destination = "/tmp/nginx.conf"
  }

  provisioner "shell" {
    inline = [
      "sudo mv /tmp/nginx.conf /etc/nginx/nginx.conf"
    ]
  }

  # Copiar y configurar la aplicacion
  provisioner "file" {
    source      = "dist/"
    destination = "/tmp/app/"
  }

  provisioner "shell" {
    inline = [
      "sudo mkdir -p /opt/webapp",
      "sudo cp -r /tmp/app/* /opt/webapp/",
      "cd /opt/webapp && sudo npm ci --only=production",
      "sudo cp /tmp/app/webapp.service /etc/systemd/system/",
      "sudo systemctl daemon-reload",
      "sudo systemctl enable webapp"
    ]
  }

  # Instalar agentes de monitoreo
  provisioner "shell" {
    script = "scripts/install-monitoring.sh"
  }

  # Hardening del sistema operativo
  provisioner "shell" {
    script = "scripts/os-hardening.sh"
  }

  # Limpiar antes de crear la imagen
  provisioner "shell" {
    inline = [
      "sudo dnf clean all",
      "sudo rm -rf /tmp/*",
      "sudo rm -rf /var/log/*",
      "sudo rm -f /root/.bash_history",
      "sudo rm -f /home/ec2-user/.bash_history"
    ]
  }
}

Pipeline de Construcción de Imagenes

El build de la imagen debe integrarse en el pipeline de CI/CD:

# GitHub Actions: build y test de golden image
name: Build Golden Image
on:
  push:
    branches: [main]
    paths:
      - 'packer/**'
      - 'configs/**'
      - 'scripts/**'

jobs:
  build-ami:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.PACKER_ROLE_ARN }}
          aws-region: us-east-1

      - name: Packer Init
        run: packer init golden-image.pkr.hcl

      - name: Packer Validate
        run: packer validate golden-image.pkr.hcl

      - name: Packer Build
        run: |
          packer build -machine-readable golden-image.pkr.hcl | tee packer-output.log
          AMI_ID=$(grep 'artifact,0,id' packer-output.log | cut -d: -f2)
          echo "AMI_ID=$AMI_ID" >> $GITHUB_ENV

      - name: Test AMI with Terratest
        run: |
          cd tests/
          go test -v -timeout 30m -run TestGoldenImage

Blue-Green Deployments con Infraestructura Inmutable

La infraestructura inmutable habilita naturalmente los despliegues blue-green, donde se ejecutan dos ambientes identicos y se alterna el tráfico entre ellos.

Flujo de Despliegue

  1. Blue esta en producción sirviendo tráfico
  2. Se construye una nueva AMI con los cambios
  3. Se despliega el entorno Green con la nueva AMI
  4. Se ejecutan health checks y pruebas contra Green
  5. Se cambia el tráfico del Load Balancer de Blue a Green
  6. Se mantiene Blue por un período de observación (30 minutos típicamente)
  7. Si todo esta bien, se destruye Blue. Si hay problemas, se revierte el tráfico

Implementación con Terraform y ASG

# variables.tf
variable "ami_id" {
  description = "AMI ID for the golden image"
  type        = string
}

variable "app_version" {
  description = "Application version tag"
  type        = string
}

# launch_template.tf
resource "aws_launch_template" "webapp" {
  name_prefix   = "webapp-"
  image_id      = var.ami_id
  instance_type = "t3.medium"

  iam_instance_profile {
    name = aws_iam_instance_profile.webapp.name
  }

  network_interfaces {
    associate_public_ip_address = false
    security_groups             = [aws_security_group.webapp.id]
  }

  tag_specifications {
    resource_type = "instance"
    tags = {
      Name        = "webapp-${var.app_version}"
      Environment = "production"
      AppVersion  = var.app_version
    }
  }

  lifecycle {
    create_before_destroy = true
  }
}

# asg.tf
resource "aws_autoscaling_group" "webapp" {
  name                = "webapp-${var.app_version}"
  desired_capacity    = 3
  min_size            = 2
  max_size            = 6
  vpc_zone_identifier = var.private_subnet_ids
  health_check_type   = "ELB"
  health_check_grace_period = 300

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

  target_group_arns = [aws_lb_target_group.webapp.arn]

  instance_refresh {
    strategy = "Rolling"
    preferences {
      min_healthy_percentage = 75
      instance_warmup        = 120
    }
  }

  tag {
    key                 = "Name"
    value               = "webapp-${var.app_version}"
    propagate_at_launch = true
  }
}

La clave aquí es el bloque instance_refresh: cuando se actualiza la AMI en el Launch Template, el ASG reemplaza las instancias de forma gradual (rolling), manteniendo al menos el 75% de la capacidad saludable durante la actualización.

Desafios de la Infraestructura Inmutable

Adoptar infraestructura inmutable no esta libre de complejidades:

Gestión de Estado y Datos Persistentes

Los servidores inmutables no deben almacenar datos persistentes localmente. Todo el estado debe externalizarse:

  • Bases de datos: RDS, DynamoDB, o bases de datos gestionadas
  • Sesiones de usuario: Redis, ElastiCache o almacenamiento en cliente (JWT)
  • Logs: Enviar a CloudWatch, ELK Stack o similar en tiempo real
  • Archivos subidos: S3 u otro almacenamiento de objetos

Tiempo de Build

Construir una AMI completa puede tomar entre 10 y 30 minutos, lo cual es significativamente mas lento que copiar un artefacto y reiniciar un servicio. Para mitigar esto:

  • Mantener una AMI base que se actualiza semanalmente con parches del SO
  • La AMI de aplicación hereda de la base y solo agrega el código de la app
  • Usar cache de paquetes para acelerar las instalaciones

Debugging en Producción

Sin SSH a los servidores, el debugging cambia. Se necesitan:

  • Logging exhaustivo desde el dia cero (todo a CloudWatch/ELK)
  • Métricas detalladas de aplicación (Prometheus, DataDog)
  • Trazas distribuidas (Jaeger, X-Ray) para seguir requests entre servicios
  • La opción de desplegar una instancia temporal con acceso SSH para casos extremos, fuera del ASG de producción

Costo Inicial

La inversion inicial en automatización (pipelines de Packer, tests de imagen, IaC completo) es mayor que simplemente hacer SSH y ejecutar comandos. Pero el retorno se manifiesta en menos incidentes, rollbacks mas rapidos y entornos reproducibles.

Implementación Completa: Terraform + Packer + ASG

Un flujo de trabajo completo de infraestructura inmutable se ve así:

[Commit en main]
    |
    v
[CI: Build aplicacion]
    |
    v
[CI: Packer build AMI]
    |
    v
[CI: Test AMI con Terratest]
    |
    v
[CD: Terraform apply con nueva AMI]
    |
    v
[ASG Instance Refresh: rolling update]
    |
    v
[Health checks del ALB]
    |
    v
[Produccion actualizada]

Cada paso esta automatizado. No hay SSH, no hay cambios manuales, no hay scripts ejecutados a mano en servidores. El único input humano es el merge del pull request; todo lo demas lo ejecuta el pipeline.

Cuando Usar Infraestructura Inmutable

La infraestructura inmutable es ideal para:

  • Aplicaciones stateless detras de un balanceador de carga
  • Entornos con multiples instancias identicas (web servers, workers, APIs)
  • Organizaciones que priorizan la reproducibilidad y la auditabilidad
  • Equipos que ya tienen un nivel de madurez en IaC y CI/CD

No es la mejor opción para:

  • Servidores de base de datos (por naturaleza son stateful)
  • Entornos de desarrollo donde se necesita iterar rápidamente
  • Organizaciones sin inversion previa en automatización

Conclusion

La infraestructura inmutable elimina una clase entera de problemas operativos: la deriva de configuración, los snowflake servers y los rollbacks impredecibles. A cambio, exige una inversion inicial en automatización y un cambio cultural hacia el modelo de “cattle, not pets”. Con herramientas como Packer para construir golden images, Terraform para gestionar la infraestructura, y Auto Scaling Groups para el despliegue gradual, el patron se implementa de forma práctica y repetible. Los equipos que adoptan este enfoque descubren que no solo ganan en estabilidad, sino que la velocidad de despliegue aumenta una vez que el pipeline esta en su lugar.

Recursos