Concepto clave

En el mundo del DevOps, la infraestructura como código (IaC) con Terraform en AWS es como tener un plano arquitectónico digital que puedes versionar, compartir y ejecutar repetidamente. Imagina construir una casa: en lugar de contratar obreros cada vez, tienes un conjunto de instrucciones detalladas que una máquina puede seguir para crear paredes, instalar tuberías y conectar electricidad de forma idéntica cada vez. Terraform es ese lenguaje de instrucciones, y AWS es el terreno donde construyes.

El proyecto integrador representa la culminación de esta analogía: no solo construyes una habitación, sino una casa completa con sistemas interconectados. A nivel intermedio, dominar esto significa entender cómo los módulos de Terraform, los estados remotos y las políticas de IAM trabajan juntos para crear infraestructura escalable y repeatable. La clave está en la idempotencia: ejecutar el mismo código múltiples veces debe resultar en el mismo estado deseado, sin efectos secundarios no deseados.

Cómo funciona en la práctica

En un escenario real, un DevOps Engineer usa Terraform para desplegar una aplicación web en AWS. Comienza definiendo proveedores y configuraciones básicas en un archivo main.tf. Luego, estructura el proyecto en módulos: uno para la red VPC, otro para instancias EC2, y otro para balanceadores de carga. Cada módulo tiene sus propias variables y salidas, promoviendo reutilización.

Paso a paso: primero, inicializa el directorio con terraform init para descargar proveedores. Luego, planifica con terraform plan para revisar cambios antes de aplicarlos. Finalmente, aplica con terraform apply para crear recursos en AWS. Herramientas como terraform fmt y terraform validate aseguran calidad del código. En proyectos grandes, se usa un backend remoto como S3 para almacenar el estado, permitiendo colaboración en equipo.

Codigo en accion

Antes: Un archivo monolítico que mezcla recursos, dificultando el mantenimiento.

# main.tf (version antigua)
provider "aws" {
  region = "us-east-1"
}

resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
}

resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
  vpc_id        = aws_vpc.main.id
}

Despues: Estructura modular que separa responsabilidades, mejorando escalabilidad.

# modules/network/main.tf
resource "aws_vpc" "this" {
  cidr_block = var.cidr_block
  tags = {
    Name = "${var.environment}-vpc"
  }
}

# modules/compute/main.tf
resource "aws_instance" "this" {
  ami           = var.ami_id
  instance_type = var.instance_type
  subnet_id     = var.subnet_id
  tags = {
    Name = "${var.environment}-instance"
  }
}

# root main.tf
module "network" {
  source = "./modules/network"
  cidr_block = "10.0.0.0/16"
  environment = "prod"
}

module "compute" {
  source = "./modules/compute"
  ami_id = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
  subnet_id = module.network.subnet_id
  environment = "prod"
}

Errores comunes

No usar backend remoto: Almacenar el estado localmente causa conflictos en equipos. Solución: Configurar un backend S3 con bloqueo DynamoDB para consistencia.
Hardcodear valores: Incluir IDs de AMI o regiones directamente en código reduce portabilidad. Solución: Usar variables y data sources para hacerlo dinámico.
Ignorar políticas de IAM: Asignar permisos excesivos a Terraform crea riesgos de seguridad. Solución: Seguir el principio de menor privilegio, usando roles específicos.
No versionar módulos: Cambiar módulos sin control rompe entornos. Solución: Usar etiquetas de version en fuentes de módulos (e.g., Git tags).
Olvidar terraform destroy en pruebas: Dejar recursos ejecutándose genera costos innecesarios. Solución: Automatizar limpieza con scripts o entornos efímeros.

Checklist de dominio

¿Puedes estructurar un proyecto Terraform con módulos reutilizables?
¿Sabes configurar un backend remoto en S3 para estado compartido?
¿Entiendes cómo usar variables y outputs para parametrizar infraestructura?
¿Puedes aplicar políticas de IAM seguras para ejecutar Terraform en AWS?
¿Dominas comandos como plan, apply, y destroy en flujos reales?
¿Eres capaz de depurar errores comunes (e.g., problemas de proveedor o sintaxis)?
¿Puedes integrar Terraform con pipelines CI/CD para despliegues automatizados?

Refactorizar un Proyecto Terraform para Escalabilidad

En este ejercicio, tomarás un proyecto Terraform existente y lo refactorizarás para hacerlo más escalable y mantenible, aplicando conceptos del módulo.

Descarga el código base: Comienza con un archivo main.tf que contiene recursos para una VPC, dos subnets, un grupo de seguridad y una instancia EC2, todo en un solo archivo.
Estructura en módulos: Crea una carpeta modules/ con subcarpetas para network, security, y compute. Mueve los recursos relevantes a cada módulo, definiendo variables y outputs apropiados.
Configura variables: Reemplaza valores hardcodeados (como CIDR blocks o AMI IDs) con variables en un archivo variables.tf en la raíz. Usa un archivo terraform.tfvars para asignar valores específicos del entorno.
Implementa backend remoto: Configura un backend S3 en AWS para almacenar el estado. Asegúrate de que el bucket exista y tenga políticas de acceso adecuadas.
Prueba y valida: Ejecuta terraform init, terraform plan para verificar cambios, y terraform apply (en un entorno de prueba) para desplegar la infraestructura refactorizada. Luego, usa terraform destroy para limpiar.

Pistas

Usa la documentación oficial de Terraform para guiarte en la sintaxis de módulos y backends.
Considera usar data sources de AWS para obtener AMIs dinámicamente en lugar de hardcodear IDs.
Verifica que las políticas de IAM para el backend S3 permitan lectura/escritura desde tu cuenta.

Evalua tu comprension

Completa el quiz interactivo de arriba para ganar XP.

Quiz: Evaluación Final del Proyecto Integrador

Quiz Interactivo