Terraform и Infrastructure as Code

(Secção Tecnologia e Infraestrutura)

Resumo curto

O Terraform é uma ferramenta básica de IaC para a criação de infra-estruturas de nuvem de iGaming reproduzível e verificável: VPC/sub-redes, Balanceadores, BD/clusters, filas/pneus, KMS/Segredos, Kubernetes, CDN e monitoramento. O sucesso é mantido em arquitetura modular, política de estações e bloqueios rigorosos, abordagem GitOps de lançamentos, Policy-as-Código, testes automatizados e FinOps transparente.

1) Princípios de IaC para iGaming

Declaração: infraestrutura descrita pelo código; Não há passos manuais.
Idempotidade: A repetição 'apply' tem o mesmo resultado.
Separação de ambientes: 'dave/estágio/prod' a partir de um único código com parâmetros.
A composição dos módulos é um único catálogo de módulos para VPC, BD, filas, K8s, monitoramento.
Segurança padrão: Subretas privadas, mTLS, direitos IAM mínimos.
Observabilidade e custo: métricas/alertas/orçamentos - também sob Terraform.

2) Estrutura do repositório

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/

Alternativa - Repo modular (repositório separado para cada módulo) + consumidores.

3) Modularidade básica (exemplo 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) Controle de bits (state) e bloqueios

Backend remoto (por exemplo, armazenamento de objetos) + bloqueio (DynamoDB/Blob-lock) - impede corridas de 'apply'.
Versionagem de Backend e criptografia de estágio (KMS).
As regras de acesso são apenas CI/CD e «infra owners» têm permissões «apply»; desenvolvedores: «plano».

• Workspaces são fáceis para ambientes semelhantes (reprodução),
• Diretórios individuais para configurações bem isoladas e topologias diferentes.

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) Variáveis, segredos e dados sensíveis

variables. tf + .tfvars para ambientes; sensitivo = true para valores privados.
Os segredos não estão guardados no Git. Use a consumpção do Secret Management/KMS através de data-fonte ou provedor.
Criptografia padrão: para volumes/bacapes/snapshots/bancos de dados.
Rotation: As chaves e as senhas são rotativas automaticamente.

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

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

6) GitOps e CI/CD para Terraform

PR-flow: 'terraform fmt' n' init' 'validate' n' 'n' n' plan' com saída em PR apprive manual 'apply' da CI.
Promoção de ambientes: alterações em primeiro lugar em 'estágio', seguida de tag/merj em 'prod'.
Logs e artefactos, preservação de plano e difa, relatório 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)

O objectivo é desviar automaticamente alterações inseguras/caras.

• Criptografar recursos é obrigatório.
• IP público - apenas através de uma lista de exceções.
• Limite o tamanho das instâncias/clusters por ambiente.
• Marcas de formatação obrigatórias: 'eng', 'owner', 'cost _ center'.

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

8) Testes de IaC

terraform validate - verificação básica de sintaxe.
taplint - estilo/antipattern/provedor de especificidades.
Infracost é uma estimativa preliminar do valor em PR.
Terratest - Testes de integração (Go): levantar/verificar/derrubar o estande.
Kitchen-Terraform - testes modulares com invariantes de recursos.
Detecção Draft: Periodicamente 'plano' em read-only e alerta para rashinchron.

9) Módulos típicos para plataforma iGaming

Rede

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

Dados

MySQL/PostgreSQL: Multi-AZ, PITR, `auto_minor_version_upgrade`.
Redis/Memcached: Multi-AZ, políticas snapshot/TTL.
Data Lake/Lakehouse: baquetes, políticas, tabelas (catálogo/metástor).
Clusters ClickHouse/OLAP: charding/replicação, políticas de disco.

Pneus/filas

Kafka/Pulsar/managed-variantes, LCA, retenha, registro de circuito.

K8s

EKS/AKS/GKE с NodeGroups, taints/tolerations, IRSA/Workload Identity, Ingress/Service Mesh, autoscaling.
Integração de External Secret, Prometheus/Grafana, Loki/ELK, cert-gerente.

Edge/CDN

Distribuição CDN, regras de cajagem, WAF, mitigação de bots.

10) Variáveis/Outputs/locals - prática

locals para valores computáveis (máscaras, nomes).
outputs como API do pod: mínimo necessário.
Nome de recursos: '<eng> - <region> - <domain> - <composto>'.
Тэги: `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) Multiblaco e regiões

Abstração através de módulos iguais, provedores diferentes: 'aws', 'azurerm', 'google'.
Provider alias para recursos cruzados (DR./replicação).
As diferenças de serviços são encerradas com condições e fichiflags nos módulos.
Os dados são localizados: baquetes/BD individuais por região (EU/TR/LATAM).

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

12) Observabilidade e alertas como código

Dashboards, regras de alertas (p95/p99, erro-rate, CPU/IO), monitores SLO.
Logs de Acesso/Auditoria (WORM), métricas de valor (by tag/namespace).
Incidentes: notificações de bate-papo, runbooks TUFs em anotações de recursos.

13) FinOps: custo sob controle

Infracost em PR + alertas de orçamento.
Quotas de ambientes: limitação das classes de instância/armazém.
Higiene automática: TTL para recursos dave, política de reticência de baquetes/logs.
Spot/Preemptible para tarefas não-ríticas, reserva para protas.

14) Processos de migração/mudança

'terraform import' para os recursos legasi (logo depois de 'plano '/' apply').
'moved '/' removed' blocos de refacção para evitar estragos.
Alterações zero-downtime: desenho duplo (blue-green) para contornos críticos (BD/balanceadores).
Passo a passo, primeiro novo grupo de recursos, depois tráfego, depois desmontagem.

15) Segurança e conformidade

Least privege: os módulos criam apenas as permissões desejadas, não usam ".
KMS everywhere: criptografia de volumes/bacapes/segredos/esteira.
Scan Terraform/IaC em CI (SAST para IaC).
Segredos fora do Git: apenas gerentes de segredos; rotação e auditoria de acesso.
Áreas PII: marcas/políticas de acesso, proibição de exportação interregional.

16) Exemplos de modelos

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) Folha de cheque de implementação Terraform/IaC

1. Selecione a estrutura do repositório (plug-ins + diretórios de ambientes).
2. Configure o remote state com bloqueios e criptografia (KMS).
3. Digite GitOps-pipline: fmt/validate/08lint/place → review → apply.
4. Forme uma biblioteca de módulos (VPC, K8s, BD, filas, monitoramento, CDN, segredos).
5. Inclua o Policy-as-Code (OPA/Sentinel) e os scans IaC no CI.
6. Organize segredos através do gerente, chaves - KMS, roteiros.
7. Adicione testes: Terratest para módulos críticos, Infracost para PR.
8. Defina o SLO/alert e o «monitoramento como código».
9. Configure quotas/orçamentos e TTL para recursos não-ríticos.
10. Planeje as migrações em etapas (blue-green/duplo).

18) Antipattern

«Flocos de neve» manuais de recursos fora da Terraform → à deriva e acidentes com 'apply'.
Armazenamento local/sem bloqueios → corrida e perda de consistência.
Segredos em Git/em '.tfvars' sem criptografia.
O pod God para centenas de recursos → impossibilidade de testar/reutilizar.
Direto 'apply' de um laptop em prod sem PR e plano-revezamento.
Ignorar Policy-as-Código/raias → fugas, IP/baquetes públicos.
A falta de orçamento/infracost → um custo imprevisível.

Resumo

Terraform/IaC dá a plataforma iGaming reprodutividade, velocidade e segurança/custo controlado. Design modular, estatura rigorosa e GitOps, políticas de segurança, autopeças e FinOps transformam a infraestrutura em uma linha de montagem confiável - lançamentos rápidos sem downthame, p99 previsível e prontidão para torneios de pico e requisitos regulatórios.