Infrastructure as Code: Terraform, Ansible

Infrastructure as Code: Terraform, Ansible

1) Por qué IaC y en qué difieren las herramientas

Terraform es un orchestrator-IaC declarativo: crea/modifica infraestructura en la nube (VPC, K8s, LB, DB, IAM) a través de proveedores. Administra el ciclo de vida de los recursos y almacena el estado.
Ansible es un config-IaC de procedimiento y gestión de configuración: configura hosts/software (paquetes, archivos, servicios), sabe navegar aplicaciones, template, orquestación de pasos. Sin agente (SSH/WinRM), con idempotencia de tareas.

Combinación: Terraform - «de lo que está hecha la plataforma», Ansible - «cómo se configura y se ejecuta».

2) Estructura de repositorios y capas

1. Foundation (Landing Zone): redes, IAM, KMS, registros básicos/monitoreo.

2. Plataforma: clústeres de Kubernetes, bases, colas, pila de observabilidad.

3. Workloads: espacios/no espacios, cuentas de servicio, políticas, confecciones.

• 'iac/terraform/' - módulos y entornos (' módulos/', 'envs/').
• 'iac/ansible/' - roles (' roles/'), playbooks ('playbooks/'), inventarios (' inventories/').
• 'policies/' - Regla OPA/Conftest.
• 'pipelines/' - scripts CI/CD (lint/plan/apply/test).

3) Terraform: módulos, estate, entorno

3. 1 Módulos

Pequeños, reutilizables: 'vpc', 'eks', 'rds',' redis ',' amb ',' iam-role '.
Entradas → 'variables. tf ', salidas →' outputs. tf ', versiones - a través del registro de módulos/git-tags.

hcl module "vpc" {
source = "git::ssh://git@repo/iac. git//modules/vpc? ref=v1. 6. 0"
name  = "prod-core"
cidr  = "10. 0. 0. 0/16"
azs  = ["eu-central-1a","eu-central-1b"]
}

3. 2 Estado (estado)

Backend remoto (S3/GCS + DynamoDB/LockTable) + bloqueos.
Separación por entornos: 'prod. tfstate`, `staging. tfstate`.
State-drift: 'terraform plan' en CI según lo programado; alerta a la deriva.

hcl terraform {
backend "s3" {
bucket     = "iac-state"
key      = "prod/network/terraform. tfstate"
region     = "eu-central-1"
dynamodb_table = "iac-locks"
encrypt    = true
}
}

3. 3 Workspaces / Envs

• Directorios individuales 'envs/prod',' envs/stage '(visualmente).
• Talleres para variaciones ligeras, pero evitar mezclar secretos.
• Opciones a través de 'tfvars': 'prod. tfvars`, `stage. tfvars`.

4) Ansible: roles, inventarios, idempotencia

4. 1 Roles y playbucks

roles/
nginx/
tasks/main. yml templates/.j2 handlers/main. yml defaults/main. yml playbooks/
site. yml

yaml
- hosts: web become: true roles:
- role: nginx vars:
nginx_listen_port: 8080

4. 2 Inventario y altavoz

`inventories/prod/hosts. yml '+ variables' group _ vars/host _ vars'.
Inventario dinámico: 'aws _ ec2', 'gcp _ compute', 'kubernetes. core`.

4. 3 Idempotencia

Utilice módulos (no 'shell') donde sea posible.
'changed _ when '/' check _ mode' para carreras en seco.
Los handlers solo se reflejan cuando se producen cambios.

5) Secretos y confecciones

Terraform: secreción de valores a través de 'sensitive = true'; los secretos en sí no se encuentran en el estado (guarde en AWS Secrets Manager/HashiCorp Vault/KMS y enlace la fuente de datos).
Ansible: Vault para cifrado de variables ('ansible-vault encrypt'), integración con HashiCorp Vault/KMS.
GitOps: secretos en reposo/almacenamiento independiente, acceso a través de least-privilege.

6) Políticas y cumplimiento (Policy as Code)

OPA/Conftest para planes de Terraform: prohibición de los S3 públicos abiertos por SG, recursos no etiquetados (tags).
Terraform Cloud/Enterprise - Sentinel como alternativa.
Ansible Lint: estilo y seguridad (sin 'sudo: yes' donde no hace falta, sin raw-shell).

rego package terraform. security

deny[msg] {
input. resource_type == "aws_security_group_rule"
input. values. cidr_blocks[_] == "0. 0. 0. 0/0"
input. values. from_port == 22 msg:= "SSH from 0. 0. 0. 0/0 is forbidden"
}

7) Pruebas de IaC

Terraform: 'tflint', 'tfsec '/' checkov', Terratest (Go) para los controles de integración.
Ansible: 'ansible-lint', Molecule (+ Docker/Podman/EC2) para validar roles.
Pruebas de smoke después de apply: pruebas HTTP, puerto/procesos, derechos.

8) CI/CD и GitOps

1. Lint/Sec: tflint, tfsec/checkov, ansible-lint.

2. Plan: 'plan de superficie' con la publicación del artefacto (comentario en MR).

3. Policy Gate: Conftest/Sentinel.

4. Apply (manual/approved): sólo en main con la firma de artefactos.

5. Ansible deploy: '--check' en el escenario, luego '--diff' en el prod.

6. Post-checks: sintético/Probe, anotación de dashboard de lanzamiento.

• Guarde los manifiestos como fuente de la verdad; Argo CD/Flux para Kubernetes, pero los clústeres/primitivos básicos son a través de Terraform.

9) Patrones para Kubernetes, redes, DB

9. 1 Kubernetes

Terraform: clústeres EKS/GKE/AKS, nodos, IAM, StorageClass, LB.
Ansible: preparación de AMI/bastiones, ensamblaje de imágenes/repositorios, instalación posterior (loggers/agentes/OTel).

9. 2 Redes y perímetro

Terraform: VPC/subredes/NAT/Transit-Gateway/WAF, rutas.
Ansible: Confit NGINX/Envoy/HAProxy, TLS, WAF configuraciones de reglas.

9. 3 Bases/caché/cola

Terraform: RDS/CloudSQL parámetro-group, Redis/ElastiCache, Kafka/MSK.
Ansible: calentamiento de caché, trabajos de migración, configuración de backups/agentes.

10) Ejemplos de confecciones

10. 1 Terraform — RDS PostgreSQL + SG

hcl module "db" {
source        = "terraform-aws-modules/rds/aws"
engine        = "postgres"
engine_version    = "15. 4"
instance_class    = "db. m6g. large"
allocated_storage  = 100 name         = "core"
username       = var. db_user password       = var. db_password # см. secret data source vpc_security_group_ids = [module. db_sg. security_group_id]
multi_az       = true backup_retention   = 7
}

module "db_sg" {
source = "terraform-aws-modules/security-group/aws"
name  = "db-core"
vpc_id = module. vpc. vpc_id ingress_cidr_blocks = ["10. 0. 0. 0/8"]
ingress_rules    = ["postgresql-tcp"]
}

10. 2 Terraform - fuente de datos del secreto

hcl data "aws_secretsmanager_secret_version" "db" {
secret_id = "prod/db/core"
}
variable "db_password" {
type   = string sensitive = true default  = jsondecode(data. aws_secretsmanager_secret_version. db. secret_string). password
}

10. 3 Ansible - rol postgresql-client (fragmento)

yaml
- name: Install packages apt:
name: [ "postgresql-client-15" ]
state: present update_cache: yes

- name: Create. pgpass copy:
dest: /home/deploy/.pgpass mode: '0600'
content: "{{ db_host }}:5432:core:{{ db_user }}:{{ db_password }}"
no_log: true

- name: Smoke query shell: psql -h {{ db_host }} -U {{ db_user }} -d core -c "select 1"
register: psql_out changed_when: false

10. 4 Ansible - NGINX con template

yaml
- name: Deploy nginx. conf template:
src: templates/nginx. conf. j2 dest: /etc/nginx/nginx. conf notify: Restart nginx

- name: Ensure nginx running service:
name: nginx state: started enabled: true

handlers:
- name: Restart nginx service: { name: nginx, state: restarted }

11) Gestión de la deriva y el cumplimiento

El 'plan de terraforma' periódico en una clave de lectura única; crea un ticket cuando hay una discrepancia.
Ansible --check programado para roles críticos (modo audit).
Informes: políticas OPA/Conftest no cumplidas, recursos sin etiquetas/backup/monitoreo.

12) Observabilidad y auditoría

Logs 'terraform apply' y artefactos de planos - guardar en el almacén de objetos.
Ansible: 'callback _ plugins' (json) → registro central/ELK; incluya job ID, commit SHA, trace_id.
Métricas: tiempo de ejecución de planes/playbooks, frecuencia de cambios, cobertura de pruebas.

13) Seguridad

Firma de módulos/roles o etiquetas/hashes fijos.
Derechos mínimos de IAM ('plan' ≠ 'apply'), comparte los roles de CI y appruver humano.
Cifrado de estado/registro, registros privados de módulos/roles.
La política «no plaintext secrets in VCS», los escáneres de secreto (gitleaks/trufflehog).

14) Anti-patrones

Un módulo monstruo de Terraform «por todo»; ausencia de versiones de módulos.
Local 'terraform. tfstate 'y ningún bloqueo.
Correcciones manuales en la nube sobre IaC → una deriva eterna.
Ansible 'shell '/' command' en lugar de módulos (rompe la idempotencia).
Inventario «en un solo archivo» sin grupos/variables, mezcla prod/stage.
Secretos en vars/repositorio, sin Vault/KMS.
Apply sin Plan y sin Peer Review.

15) Lista de verificación de implementación (0-45 días)

0-10 días

Configurar backend/lock remoto, descomponer los módulos de Terraform.
Habilitar tflint/tfsec/checkov, ansible-lint; negociar etiquetas/etiquetas de recursos.
Crear roles ansibles para NGINX/agentes/logers; Organizar los inventarios.

11-25 días

Agregar Conftest/OPA, Terratest y Molecule para módulos/roles críticos.
CI: 'plan' sobre MR, el artefacto del plan, manual-apply con appruve; Ansible `--check` на stage.
Integrar almacenamiento secreto (Vault/KMS/Secrets Manager).

26-45 días

Plan de Auto-Plan para el Bebé Drift, Informes de Políticas.
Directorio de módulos/roles versionados; documentación 'README. md 'en cada uno.
GitOps: anotaciones de lanzamientos, un conjunto de monitoreo y alert gates.

16) Métricas de madurez

% de los entornos con state y locks remotos = 100%.
Porcentaje de módulos/roles con pruebas (Terratest/Molecule) ≥ 70%.
El tiempo promedio desde MR hasta apply (prod) es horas, no días.
Cero «deriva manual» (todos los cambios pasan por MR).
El 100% de los recursos críticos están cubiertos por Policy as Code (etiquetas, cifrado, copia de seguridad).

17) Conclusión

Terraform especifica una base de infraestructura predecible y repetible; Ansible lleva a los hosts y servicios al estado requerido. Agregue Policy as Code, un estado remoto con ubicación, pruebas, gestión secreta y CI/CD con plan→review→apply, y su circuito IaC será manejable, seguro y rápido, y las versiones serán atómicas y reversibles.