Infraestructura como código

Declarativo e imperativo

• Las herramientas declarativas (Terraform, CloudFormation, manifiestos de Kubernetes) describen el estado final deseado; la herramienta descubre cómo llegar.
• Las herramientas y scripts imperativos describen los pasos. Son flexibles, pero es más fácil ejecutarlos dos veces con resultados distintos.
• La gestión de configuración (Ansible, Chef) instala y configura software en las máquinas; las herramientas de aprovisionamiento crean las máquinas y los recursos de nube. Muchos equipos usan ambas, o evitan servidores mutables generando imágenes ya preparadas.
• Prefiere infraestructura inmutable: reemplaza en lugar de parchear en sitio.

El ciclo de plan y apply

terraform {
  required_version = ">= 1.6"
  required_providers {
    aws = { source = "hashicorp/aws", version = "~> 5.0" }
  }
  backend "s3" {
    bucket         = "example-terraform-state"
    key            = "network/prod.tfstate"
    region         = "us-east-1"
    dynamodb_table = "terraform-locks"
    encrypt        = true
  }
}

resource "aws_vpc" "main" {
  cidr_block           = var.vpc_cidr
  enable_dns_hostnames = true
  tags                 = merge(var.tags, { Name = "main" })
}

terraform fmt -check && terraform validate
terraform plan -out=tfplan             # revisa esto en el pull request
terraform apply tfplan                 # lo ejecuta el pipeline, no una laptop

Prácticas

• State remoto, con lock y cifrado; nunca hagas commit de archivos de state (pueden contener secretos).
• Módulos pequeños con entradas y salidas claras, versionados y reutilizados; evita un único módulo raíz gigante.
• Separa los entornos por state y por cuenta, no por una variable que puedes olvidar cambiar.
• Detecta y corrige el drift: programa un plan y alerta cuando la realidad difiera del código.
• Escanea el código y el plan en busca de configuraciones inseguras antes del apply (ver Infrastructure as code security en el dominio Engineering).
• Mantén los secretos fuera del código; referencia un gestor de secretos.

Trampas

• Cambios manuales en la consola que el código luego sobrescribe o con los que pelea.
• Un destroy escondido en un plan grande: lee lo que se reemplaza, no solo lo que se agrega.
• Versiones de provider y de módulo dejadas flotantes, de modo que un plan cambia sin un cambio de código.
• Un único state para todo: un pequeño error bloquea a todos los equipos y el radio de impacto es toda la empresa.