Diseñando la infraestructura en la nube con Terraform e IaaS

En la ingeniería de software moderna, la velocidad del despliegue está intrínsecamente ligada a la agilidad de la infraestructura subyacente. La provisión, configuración y gestión manuales de los recursos en la nube ya no son escalables, repetibles o fiables. Introducen errores humanos, generan inconsistencias en la configuración y representan un cuello de botella significativo en el proceso de entrega. Es aquí donde Infraestructura como código (IaC)Infraestructura como Código (IaC)

Terraform, de HashiCorp, se ha convertido en la herramienta estándar de la industria, independiente de la nube, para implementar IaC. Permite a los equipos de ingeniería definir y configurar una infraestructura completa —desde redes virtuales y balanceadores de carga hasta bases de datos y clústeres Kubernetes — utilizando un lenguaje de configuración de alto nivel y declarativo conocido como HashiCorp Configuration Language (HCL).

Este artículo no es una guía "para empezar". Es un análisis técnico profundo para directores de tecnología (CTOs) y ingenieros senior sobre ¿cómo?cómo

Servicios de Ingeniería de Productos

Colabore con nuestros gestores de proyectos, ingenieros de software y probadores de calidad para desarrollar su nuevo producto de software personalizado o para apoyar su flujo de trabajo actual, siguiendo metodologías Agile, DevOps y Lean.

Build with 4Geeks

Arquitectura central: Más allá de terraform apply

Para aprovechar al máximo Terraform, es necesario comprender sus componentes principales y, lo más importante, su gestión del estado.

Configuración declarativa y Proveedores

El poder de Terraform reside en su modelo declarativo. No se escriben scripts que ejecuten una secuencia de comandos (por ejemplo, "crear una VPC, luego crear una subred"). En cambio, usted define el estado deseado de su infraestructura. El motor principal de Terraform analiza este estado deseado, lo compara con el estado actual de su infraestructura, y genera un plan de ejecución preciso para reconciliar los dos.

Esto es posible gracias a su arquitectura independiente:

• Terraform Core: El componente binario responsable de analizar HCL, gestionar el estado, construir el grafo de recursos y generar planes de ejecución.
• Proveedores: Estos son los complementos que actúan como la capa de traducción entre la sintaxis declarativa de Terraform y las llamadas API específicas de una plataforma objetivo (por ejemplo, aws, azurerm, google, kubernetes, datadog). Esto hace que Terraform sea independiente de la nube; simplemente se sustituye el proveedor para gestionar los recursos en una plataforma diferente.

Gestión del Estado: La Única Fuente de Verdad

El componente más crítico de una implementación de Terraform es elarchivo de estado(<s3>terraform.tfstateestado del código Terraform). Este archivo JSON es la "memoria" de Terraform, y almacena una correspondencia entre sus recursos HCL y los recursos reales (por ejemplo, el ID de instancia de AWS).i-123abc...) lo gestiona.

Un archivo de estado local es inaceptable para cualquier equipo. Esto crea un único punto de fallo y dificulta la colaboración. La mejor práctica, que no puede ser negociada, es el almacenamiento remoto del estado.

El almacenamiento remoto guarda el archivo de estado en una ubicación compartida, persistente y segura. Lo más importante es que proporciona bloqueo estatal. El bloqueo garantiza que solo un comando terraform apply pueda ejecutarse a la vez para un estado determinado, evitando la corrupción de datos cuando dos ingenieros intentan modificar la misma infraestructura simultáneamente.

Ejemplo de implementación: S3 + DynamoDB para AWS

Para un entorno de AWS, el patrón estándar es utilizar un bucket de S3 para el almacenamiento persistente y una tabla de DynamoDB para el bloqueo.

Primero, debe crear estos recursos fuera de Terraform (por ejemplo, a través de la AWS CLI), ya que son requisitos previos.

Configurar el backend de Terraform: En su proyecto de Terraform, declara este backend en un archivo backend.tf o dentro del bloque principal de Terraform.

# backend.tf
terraform {
  backend "s3" {
    bucket         = "my-company-tf-state-prod"
    key            = "global/networking/terraform.tfstate" # Use a logical path for your project
    region         = "us-east-1"
    dynamodb_table = "my-company-tf-lock-table"
    encrypt        = true
  }

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

Cree la tabla de bloqueo para DynamoDB:

aws dynamodb create-table \
    --table-name my-company-tf-lock-table \
    --attribute-definitions AttributeName=LockID,AttributeType=S
    --key-schema AttributeName=LockID,KeyType=HASH \
    --provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 \
    --region us-east-1

Crear el contenedor S3:

aws s3api create-bucket \
    --bucket my-company-tf-state-prod \
    --region us-east-1 \
    --create-bucket-configuration LocationConstraint=us-east-1

# Enable versioning and encryption
aws s3api put-bucket-versioning --bucket my-company-tf-state-prod --versioning-configuration Status=Enabled
aws s3api put-bucket-encryption --bucket my-company-tf-state-prod --server-side-encryption-configuration '{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"AES256"}}]}'

Cuando ejecutes la siguiente vez terraform init, Terraform te pedirá que migres tu estado local (si existe) a este nuevo backend remoto. A partir de este punto, todas las operaciones (plan, apply) primero obtendrán un bloqueo de DynamoDB y leerán/escribirán el estado desde S3.

Implementación práctica: Módulos y Entornos

Gestionar un conjunto monolítico de .tf archivos para toda su infraestructura es inviable. La solución es diseñar su código utilizando módulos y entornos, lo que promueve la reutilización, la facilidad de prueba y la separación de responsabilidades.

• Módulos: Un módulo es un paquete reutilizable y autónomo de configuraciones de Terraform que define una colección lógica de recursos (por ejemplo, una "VPC", una "Base de datos RDS" o un "Clúster EKS").
• Entornos (Espacios de trabajo): Estos son las configuraciones de nivel superior (por ejemplo, preproducción, producción) que usan módulos para componer un entorno completo. Cada entorno tiene su propio archivo de estado independiente.

Estructura de Proyecto Recomendada

.
├── environments/
│   ├── production/
│   │   ├── main.tf           # Instantiates modules for prod
│   │   ├── variables.tf      # Prod-specific variable declarations
│   │   └── terraform.tfvars  # Prod-specific variable values
│   └── staging/
│       ├── main.tf           # Instantiates modules for staging
│       ├── variables.tf
│       └── terraform.tfvars
│
├── modules/
│   ├── vpc/
│   │   ├── main.tf           # The core VPC resources
│   │   ├── variables.tf      # Input variables (e.g., cidr_block)
│   │   └── outputs.tf        # Outputs (e.g., vpc_id, subnet_ids)
│   ├── rds_aurora/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   └── outputs.tf
│   └── web_app_service/
│       ├── main.tf           # (e.g., ALB, ASG, Launch Template)
│       ├── variables.tf
│       └── outputs.tf
│
└── backend.tf                # Root backend config (often overridden by envs)

Ejemplo de módulo: módulos/vpc

Este módulo define un estándar reutilizable de VPC.

módulos/vpc/variables.tf:

variable "project_name" {
  description = "The name of the project"
  type        = string
}

variable "vpc_cidr" {
  description = "CIDR block for the VPC"
  type        = string
}

variable "public_subnet_cidrs" {
  description = "List of CIDR blocks for public subnets"
  type        = list(string)
}

variable "private_subnet_cidrs" {
  description = "List of CIDR blocks for private subnets"
  type        = list(string)
}

variable "availability_zones" {
  description = "List of AZs to deploy subnets into"
  type        = list(string)
}

módulos/vpc/main.tf:

resource "aws_vpc" "main" {
  cidr_block           = var.vpc_cidr
  enable_dns_support   = true
  enable_dns_hostnames = true

  tags = {
    Name = "${var.project_name}-vpc"
  }
}

resource "aws_internet_gateway" "main" {
  vpc_id = aws_vpc.main.id
  tags = {
    Name = "${var.project_name}-igw"
  }
}

resource "aws_subnet" "public" {
  # Create one subnet for each CIDR in the list
  count                   = length(var.public_subnet_cidrs)
  vpc_id                  = aws_vpc.main.id
  cidr_block              = var.public_subnet_cidrs[count.index]
  availability_zone       = var.availability_zones[count.index]
  map_public_ip_on_launch = true

  tags = {
    Name = "${var.project_name}-public-${var.availability_zones[count.index]}"
  }
}

resource "aws_subnet" "private" {
  count             = length(var.private_subnet_cidrs)
  vpc_id            = aws_vpc.main.id
  cidr_block        = var.private_subnet_cidrs[count.index]
  availability_zone = var.availability_zones[count.index]

  tags = {
    Name = "${var.project_name}-private-${var.availability_zones[count.index]}"
  }
}

# ... (Additional resources: Route Tables, NAT Gateways, Endpoints, etc.) ...

módulos/vpc/outputs.tf:

output "vpc_id" {
  description = "The ID of the created VPC"
  value       = aws_vpc.main.id
}

output "public_subnet_ids" {
  description = "List of public subnet IDs"
  value       = aws_subnet.public[*].id
}

output "private_subnet_ids" {
  description = "List of private subnet IDs"
  value       = aws_subnet.private[*].id
}

entornos/producciónentornos/producción

El entorno de producción requiere este módulo.este módulo.

entornos/producción/main.tf:

terraform {
  # This backend configuration overrides any root-level config
  # and ensures 'production' has its own isolated state.
  backend "s3" {
    bucket         = "my-company-tf-state-prod"
    key            = "production/terraform.tfstate" # State path specific to this env
    region         = "us-east-1"
    dynamodb_table = "my-company-tf-lock-table"
    encrypt        = true
  }
}

provider "aws" {
  region = var.aws_region
}

# Instantiate the VPC module
module "vpc" {
  source              = "../../modules/vpc" # Path to the module
  project_name        = var.project_name
  vpc_cidr            = "10.100.0.0/16"
  public_subnet_cidrs = ["10.100.1.0/24", "10.100.2.0/24"]
  private_subnet_cidrs = ["10.100.10.0/24", "10.100.11.0/24"]
  availability_zones  = ["us-east-1a", "us-east-1b"]
}

# Instantiate the database module, passing it the private subnets from the VPC module
module "database" {
  source           = "../../modules/rds_aurora"
  project_name     = var.project_name
  instance_class   = "db.r6g.large" # Prod-sized instance
  db_subnet_ids    = module.vpc.private_subnet_ids
  vpc_id           = module.vpc.vpc_id
  db_password_arn  = var.db_password_secret_arn # Pass secret ARN
}

entornos/producción/terraform.tfvars:

# Production-specific values
project_name         = "my-app-production"
aws_region           = "us-east-1"
db_password_secret_arn = "arn:aws:secretsmanager:us-east-1:123456789012:secret:prod/db_password-AbCdEf"

Esta arquitectura proporciona una clara separación de responsabilidades. El directorio módulos define qué puedes crear, y el directorio entornos define cómo se construye para un despliegue específico.

Consideraciones estratégicas y arquitectónicas para el liderazgo

1. El flujo de trabajo principal: planificar en CI/CD

El comando más potente en Terraform no es apply, sino plan.

• terraform plan: Esta es una simulación de prueba sin afectar los recursos. Genera un plan de ejecución que detalla exactamente lo que Terraform hará: qué recursos se crearán, modificarán, o destruirán.
• terraform apply: Ejecuta el plan.

Este proceso en dos pasos es la clave para reducir los riesgos asociados a los cambios en la infraestructura. Tu flujo de trabajo de ingeniería debe estar basado en él.

El flujo de trabajo de GitOps:

1. Solicitud de integración: Un ingeniero modifica el HCL en una rama de características (p. ej., para actualizar el tipo de instancia de RDS) y crea una Solicitud de integración.
2. Planificación automatizada: Su sistema CI/CD (GitHub Actions, GitLab CI, Jenkins) ejecuta automáticamente terraform plan para el entorno correspondiente.
3. Plan de revisión: La salida del plan se publica como comentario en la PR. El líder de ingeniería revisa el resultado del plan, no solo el HCL. Este es el paso crítico de revisión. ¿Coincide el plan con la intención? ¿Solo está modificando la instancia de RDS, o inesperadamente planea destruir una VPC?
4. Aplicar al fusionar: Una vez que la PR ha sido aprobada y fusionada en main, se ejecuta un trabajo CI/CD separado (a menudo con un paso de aprobación manual) que ejecuta terraform apply para ejecutar el plan aprobado.

Herramientas como Atlantis o plataformas comerciales como Terraform Cloud/Spacelift están diseñadas para gestionar este flujo de trabajo basado en PR, gestionando el bloqueo del estado y la salida del plan automáticamente.

Servicios de Ingeniería de Productos

Trabaje con nuestros gestores de proyectos, ingenieros de software y probadores de calidad internos para desarrollar su nuevo producto de software personalizado o para apoyar su flujo de trabajo actual, siguiendo metodologías Agile, DevOps y Lean.

Build with 4Geeks

2. Gestión de secretos: El enfoque de "Confianza Cero"

Un patrón común y peligroso es codificar contraseñas de bases de datos o claves de API directamente en los archivos de .tfvars, y luego subirlos a Git.

El enfoque correcto es obtener las credenciales de forma dinámica en el momento de la aplicación desde un administrador de credenciales dedicado (como AWS Secrets Manager, Azure Key Vault o HashiCorp Vault). Terraform nunca almacena el valor de la credencial en su archivo de estado; solo almacena una referencia a ella.

# 1. Define the data source to fetch the secret
data "aws_secretsmanager_secret_version" "db_password" {
  # Get the ARN from a variable (set via terraform.tfvars or CI env var)
  secret_id = var.db_password_secret_arn
}

# 2. Use the fetched secret value directly in the resource
resource "aws_rds_cluster" "main" {
  # ...
  engine          = "aurora-postgresql"
  master_username = "postgres"
  master_password = data.aws_secretsmanager_secret_version.db_password.secret_string
  
  # Ensure the RDS cluster is only created after the secret is read
  depends_on = [
    data.aws_secretsmanager_secret_version.db_password
  ]
}

Este HCL es seguro de confirmar. La cadena secreta cadena secretasecret_stringsolicitarfuncionamiento y nunca se escribe explícitamente.

3. Detección de Desviaciones en la Configuración

Drift es lo que ocurre cuando tu infraestructura actual (en la nube) ya no coincide con el estado deseado(en tu código HCL). Esto suele ser causado por un cambio manual, fuera del flujo normal (p. ej., "Solo abriré el puerto 22 en el grupo de seguridad para una solución rápida...").

Terraform detectará automáticamente cualquier desviación en el siguiente plan. El plan mostrará el cambio realizado manualmente y propondrá una acción para revertirlo, haciendo que tu código sea la única fuente de verdad.

Estrategia: Ejecutar una tarea programada de "solo lectura" de planificación (por ejemplo, diaria) contra su entorno de producción. Si la planificación no está vacía, significa que ha ocurrido un cambio. Enviar una alerta a su equipo de soporte o al equipo de la plataforma para investigar y solucionar el problema. Esto convierte a Terraform en una herramienta poderosa para auditorías y cumplimiento.planificación con Terraformtarea (por ejemplo, diaria) contra tu entorno de producción. Si el plan no está vacío, significa que ha ocurrido una desviación. Envía una alerta a tu equipo de soporte o al equipo de la plataforma para que investiguen y solucionen el problema. Esto convierte a Terraform en una herramienta poderosa para auditorías y cumplimiento.

Finalmente

Terraform no es simplemente una herramienta de automatización; es una plataforma integral para gestionar todo el ciclo de vida de su infraestructura. Cuando se implementa correctamente con una arquitectura modular, estado remoto y un flujo de trabajo impulsado por CI/CD, ofrece una mejora significativa en las capacidades de ingeniería.

Para directores de tecnología y líderes de ingeniería, los beneficios son estratégicos:

• Visibilidad: Todos los cambios de infraestructura son visibles, revisados y auditados a través de las solicitudes de extracción (pull requests).
• Repetibilidad: Puede crear una copia perfecta de su entorno de producción para pruebas o recuperación ante desastres en cuestión de minutos.
• Reducción de riesgos: El comando terraform plan proporciona previsibilidad, convirtiendo los cambios de infraestructura de una actividad de alto riesgo en una ciencia repetible y de bajo riesgo.

Al adoptar estas prácticas, usted ayuda a su equipo a pasar de reaccionar ante problemas de infraestructura a diseñar una infraestructura como un producto de software fiable, escalable y con control de versiones.

Preguntas frecuentes