Terraform и Infrastructure as Code

(Sección: Tecnologías e Infraestructura)

Resumen breve

Terraform es la herramienta básica de IaC para la creación reproducible y verificable de la infraestructura de la nube de iGaming: VPC/subredes, balanceadores, DB/clústeres, colas/bus, KMS/Secrets, clústeres de Kubernetes, CDFORM N y monitoreo. El éxito se basa en la arquitectura modular, la estricta política de state and blocks, el enfoque GitOps para lanzamientos, Policy-as-Code, pruebas automatizadas y FinOps transparente.

1) Principios de IaC para iGaming

Declaratividad: la infraestructura está descrita por el código; no hay pasos manuales.
Idempotencia: la repetición 'apply' produce el mismo resultado.
Separación de entornos: 'dev/stage/prod' a partir de un código único con parámetros.
Composición de módulos: un único directorio de módulos para VPC, DB, colas, K8s, monitoreo.
Seguridad predeterminada: subredes privadas, mTLS, derechos IAM mínimos.
Observabilidad y costo: métricas/alertas/presupuestos - también bajo Terraform.

2) Estructura del repositorio

iac/
modules/
vpc/
mysql/
kafka/
eks_aks_gke/
redis/
monitoring/
envs/
prod/
eu-west/
main. tf variables. tf backend. tf stage/
eu-west/
...
dev/
...
policies/
opa/
sentinel/
pipelines/
ci_cd/

La alternativa es un repositorio modular (repositorio separado para cada módulo) + consumidores.

3) Modularidad básica (ejemplo HCL)

hcl variable "name" {}
variable "cidr" {}
variable "az_count" { default = 3 }

cloud provider resources (summarized)
resource "cloud_vpc" "this" { name = var. name cidr = var. cidr }
resource "cloud_subnet" "private" {
count = var. az_count vpc_id = cloud_vpc. this. id type  = "private"
}
output "vpc_id" { value = cloud_vpc. this. id }
output "private_subnets" { value = cloud_subnet. private[].id }

hcl module "vpc" {
source = "../../modules/vpc"
name  = "prod-eu-west"
cidr  = "10. 20. 0. 0/16"
}

module "mysql" {
source = "../../modules/mysql"
name  = "payments"
vpc_id = module. vpc. vpc_id subnets = module. vpc. private_subnets pitr  = true size  = "r6g. large"
kms_key = module. kms. key_id
}

4) Control de state (state) y bloqueo

Backend remoto (por ejemplo, almacenamiento de objetos) + bloqueos (DynamoDB/Blob-lock): impide las carreras 'apply'.
Versionar backend y cifrar state (KMS).
Reglas de acceso: sólo CI/CD e «infra owners» tienen derechos de 'apply'; desarrolladores - 'plan'.

• Los espacios de trabajo son convenientes para entornos similares (replicación),
• Directorios individuales: para configuraciones claramente aisladas y topología diferente.

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

5) Variables, secretos y datos sensibles

variables. tf + .tfvars para entornos; sensitive = true para valores privados.
Los secretos no se guardan en Git. Utilice la consumación de Secret Manager/KMS a través de data-source o proveedor.
Cifrado predeterminado: para volúmenes/backups/snapshots/bases de datos.
Rotación: las claves y contraseñas se rotan automáticamente.

hcl variable "db_password" {
type   = string sensitive = true
}

data "external_secret" "db_password" {
conceptual secret source name = "prod/payments/db_password"
}

6) GitOps y CI/CD para Terraform

PR-flow: 'terraform fmt' → 'init' → 'validate' → 'tflint' → 'plan' con salida en PR → manual approve → 'apply' de CI.
Promoción de los alrededores: cambios primero en 'stage', luego etiqueta/merge en 'prod'.
Registros y artefactos: preservación del plan y el diff, informe del artefacto.

yaml steps:
- run: terraform fmt -check
- run: terraform init -upgrade
- run: terraform validate
- run: tflint --enable-rule=terraform_standard_module_structure
- run: terraform plan -var-file=envs/stage/eu-west/vars. tfvars -out tfplan
- run: terraform show -no-color tfplan > plan. txt after April
- run: terraform apply tfplan

7) Policy-as-Code (OPA/Sentinel)

Objetivo: desviar automáticamente los cambios inseguros/costosos.

• El cifrado de recursos es obligatorio.
• IP pública - sólo a través de la lista de excepciones.
• Limitar el tamaño de las instancias/clústeres en el entorno.
• Etiquetas obligatorias: 'env', 'owner', 'cost _ center'.

rego deny[msg] {
input. resource. type == "db_instance"
not input. resource. encrypted msg:= "DB must be encrypted at rest"
}

8) Pruebas de IaC

validate terraform - comprobación básica de la sintaxis.
tflint - stil/antipatterny/provayder-spetsifika.
Infracost - una estimación preliminar del valor en PR.
Terratest - Pruebas de integración (Go): elevar/comprobar/demoler el stand.
Kitchen-Terraform son pruebas modulares con invariantes de recursos.
Drift-detect: un 'plan' periódico en read-only y una alerta en rassincrone.

9) Módulos típicos para la plataforma iGaming

Red

VPC/VNets/VPC-Peering, sabnets privados/públicos, routing, NAT/Firewall, Security Groups/NSG.
DNS/Failover: Route-политики, health-checks, latency-based routing.

Datos

MySQL/PostgreSQL: Multi-AZ, PITR, `auto_minor_version_upgrade`.
Redis/Memcached: Políticas multi-AZ, snapshot/TTL.
Data Lake/Lakehouse: baquetas, políticas, tablas (catálogo/metástor).
Clústeres ClickHouse/OLAP: cifrado/replicación, políticas de disco.

Bus/

Opciones Kafka/Pulsar/Managed, ACL, retoque, diagrama de registro.

K8s

EKS/AKS/GKE с NodeGroups, taints/tolerations, IRSA/Workload Identity, Ingress/Service Mesh, autoscaling.
Integración de Exteriores Secrets, Prometheus/Grafana, Loki/ELK, cert-manager.

Edge/CDN

Distribución CDN, reglas de caché, WAF, mitigación de bots.

10) Variables/Outputs/locales - práctica

locals para valores calculados (máscaras, nombres).
outputs como API del módulo: mínimo necesario.
Nomenclatura de recursos: '<env' - «región» - «dominio» - «componente».
Тэги: `env`, `owner`, `cost_center`, `criticality`, `pii`.

hcl locals {
name_prefix = "${var. env}-${var. region}-${var. service}"
}
resource "cloud_lb" "api" { name = "${locals. name_prefix}-lb" }

11) Multioblaco y regiones

Abstracción a través de los mismos módulos, diferentes proveedores: 'aws',' azurerm', 'google'.
Provider alias para recursos entre regiones (DR/replicación).
Las diferencias de servicios se cierran con condiciones y fichflags en los módulos.
Los datos se localizan: baquetas/DAB por región (EU/TR/LATAM).

hcl provider "aws" { region = "eu-west-1" alias = "eu" }
provider "aws" { region = "sa-east-1" alias = "latam" }

12) Observabilidad y alertas como código

Dashboards, reglas de alertas (p95/p99, error-rate, CPU/IO), monitores SLO.
Registros de acceso/auditoría (WORM), métricas de valor (by tag/namespace).
Incidentes: notificaciones de chat, runbooks URLs en anotaciones de recursos.

13) FinOps: el costo bajo control

Infracost en PR + alertas presupuestarias.
Cupos por entorno: limitación de clases de instancia/almacén.
Higiene automática: TTL para recursos dev, política de retoque de baquetas/registros.
Spot/Preemptible para tareas no críticas, redundancia para el prod.

14) Procesos de migración/cambio

'terraform nat' para legasi-recursos (inmediatamente después - 'plan '/' apply').
'moved '/' removed' bloques cuando se refactoriza para evitar la destrucción.
Cambios zero-downtime: doble rodillo (azul-verde) para circuitos críticos (DB/balanceadores).
PR paso a paso: primero el nuevo grupo de recursos, luego el tráfico, luego el desmantelamiento.

15) Seguridad y cumplimiento

Privilegio Least: los módulos sólo crean los derechos deseados, no utilizan ".
KMS en todas partes: cifrado de volúmenes/backups/secretos/state.
Análisis de Terraform/IaC en CI (SAST para IaC).
Secretos fuera de Git: sólo los gestores de secretos; rotación y auditoría de acceso.
Zonas PII: etiquetas/políticas de acceso, prohibición de exportaciones interregionales.

16) Ejemplos de plantillas

hcl module "db" {
source   = "../../modules/mysql"
name    = "wallet"
multi_az  = true storage_gb = 500 pitr    = true backup_retention_days = 14 deletion_protection  = true
}

hcl module "slo_latency" {
source = "../../modules/monitoring/slo"
name  = "api-latency-p95"
target_ms = 250 window  = "30m"
alert_channels = ["chatops#incidents"]
}

hcl module "cdn" {
source = "../../modules/cdn"
domain = "example. com"
waf_enabled = true cache_ttl  = 600
}

17) Lista de comprobación de la implementación de Terraform/IaC

1. Seleccione la estructura del repositorio (monopode + directorios de entorno).
2. Configure el estado remoto con bloqueo y cifrado (KMS).
3. Escriba GitOps-pipeline: fmt/validate/tflint/plan → review → apply.
4. Forme una biblioteca de módulos (VPC, K8s, DB, colas, monitoreo, CDN, secretos).
5. Incluya Policy-as-Code (OPA/Sentinel) y escaneos IaC en CI.
6. Organizar los secretos a través del gestor, llaves - KMS, rotaciones.
7. Añadir pruebas: Terratest para módulos críticos, Infracost en PR.
8. Definir SLO/alertas y «monitoreo como código».
9. Configure cuotas/presupuestos y TTL para recursos no críticos.
10. Planifique las migraciones por etapas (blue-green/dual rail).

18) Antipattern

Manuales «copos de nieve» recursos fuera de Terraform → deriva y accidente en 'apply'.
Almacenar el estate localmente/sin bloqueos → carreras y pérdida de consistencia.
Secretos en Git/in '.tfvars' sin cifrado.
Un «módulo god» con cientos de recursos → la imposibilidad de probar/volver a utilizar.
Directo 'apply' desde el ordenador portátil en el prod sin PR y plan de rugido.
Ignorar Policy-as-Code/escaneos → fugas, IP/baquetas públicas.
La falta de Infracost/presupuestos → un costo impredecible.

Terraform/IaC le da a la plataforma iGaming reproducibilidad, velocidad y seguridad/costo controlado. El diseño modular, el estricto state y GitOps, las políticas de seguridad, las autotestas y las FinOps convierten la infraestructura en un «transportador» fiable: lanzamientos rápidos sin downtime, p99 predecible y preparación para torneos de pico y requisitos regulatorios.