Terraform и Infrastructure as Code

(Sezione Tecnologia e infrastruttura)

Breve riepilogo

Terraform è uno strumento di base per la riproduzione e la verifica di un'infrastruttura cloud : VPC/subnet, Bilanciatori, OBD/cluster, code/pneumatici, KMS/Secret, Kubernets-cluster, CDN e monitoraggio. Il successo si basa su architettura modulare, rigorosa politica di state e blocchi, approccio GitOps alle release, Policy-as-Code, test automatizzati e trasparente.

1) Principi di IaC per il iGaming

Dichiarazione: l'infrastruttura è descritta dal codice; Non ci sono passi manuali.
Idampotenza: il ripetuto «apply» ha lo stesso risultato.
Separa gli ambienti Dav/stage/prod da un unico codice con parametri.
Composizione dei moduli: un unico catalogo di moduli per VPC, database, code, K8s, monitoraggio.
Protezione predefinita: sottoassiemi privati, mTLS, diritti IAM minimi.
Osservabilità e costo: metriche/alert/budget - anche sotto Terraform.

2) Struttura del repository

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 modulare (repository separato per ogni modulo) + consumatori.

3) Modularità di base (esempio 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) Gestisci state (state) e blocchi

Backend remoto (ad esempio archivio oggetti) + blocchi (DynamoDB/Blob-lock) - Impediscono le corse «apply».
Versioning backend e crittografia state (KMS).
Regole di accesso: solo CI/CD e «infra owners» hanno i diritti «apply»; gli sviluppatori dì piano ".

• Workspkes è conveniente per ambienti simili (riproduzione),
• Cataloghi separati per configurazioni ben isolate e topologie diverse.

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) Variabili, segreti e dati sensibili

variables. tf + .tfvars per gli ambienti; sensitive = true per i valori privati.
I segreti non sono conservati in Git. Utilizzare la consumazione da Secret Manager/KMS tramite data source o provider.
Crittografia predefinita per volumi/bacap/snapshot/database.
Rotation: le chiavi e le password vengono rotate 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 per Terraform

PR-flow: 'terraform fmt'init' 'validate' ' tflint'l'plan'con l'output in PR dell'approve manuale dì apply'da CI.
Promozione ambienti: modifiche prima in «stage», poi tag/merge in «prod».
Loghi e manufatti: salvataggio del piano e del diffide, rapporto artefatto.

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)

Obiettivo: rifiutare automaticamente modifiche non sicure/costose.

• La crittografia delle risorse è obbligatoria.
• IP pubblico - solo attraverso la lista delle eccezioni.
• Limita le dimensioni delle istanze/cluster per ambiente.
• I tag obbligatori sono «eng», «owner», «cost _ center».

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

8) Test di IaC

terraform validate è un controllo base della sintassi.
tflint - stile/antipattern/provider-specifico.
Infracost è una stima preliminare del costo in PR.
Terratest - Test di integrazione (Go) - Sollevare/controllare/demolire lo stand.
Kitchen-Terraform - Test modulari con invarianti di risorse.
Oggetto Drift - Periodico «plan» in read-only e notifica in rassincrone.

9) Moduli tipici per piattaforme iGaming

Rete

VPC/VNets/VPC-Peering, private/pubbliche, routing, NAT/Firewall, Security Groups/NSG.
DNS/Failover: Route-политики, health-checks, latency-based routing.

Dati

MySQL/PostgreSQL: Multi-AZ, PITR, `auto_minor_version_upgrade`.
Redis/Memcached: Multi-AZ, regole snapshot/TTL.
Data Lake/Lakehouse: baguette, criteri, tabelle (catalogo/metastore).
Cluster ClickHouse/OLAP: Charding/Replica, Criteri su disco.

Pneumatici/code

Kafka/Pulsar/managed-varianti, ACL, retensh, schemi-registro.

K8s

EKS/AKS/GKE с NodeGroups, taints/tolerations, IRSA/Workload Identity, Ingress/Service Mesh, autoscaling.
Integrazione di Extra Secret, Prometheus/Grafana, Loki/ELK, cert-manager.

Edge/CDN

distribuzione CDN, regole di cache, WAF, mitigazione dei bot.

10) Variabili/Outputs/locals - pratica

locals per i valori calcolati (maschere, nomi).
outputs come API del modulo: minimo necessario.
Nome delle risorse: '<env> - <region> - <domain> - <component>'.
Тэги: `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 regioni

Astrazione attraverso gli stessi moduli, provider diversi: «aws», «azurerm», «google».
Provider alias per risorse cross-regionali (DR/replica).
Le differenze di servizio si chiudono con condizioni e phicheflag nei moduli.
I dati sono localizzati: singoli contenitori/database per regione (EU/TR/LATAM).

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

12) Osservabilità e alert come codice

Dashboard, regole degli alert (p95/p99, error-rate, CPU/IO), monitor SLO.
Logi di accesso/controllo (WORM), metriche di costo (by tag/namespace).
Incidenti: chat-notifiche, runbooks TUFS nelle annotazioni di risorse.

13) FinOps: costo sotto controllo

Infracost in PR + alert di bilancio.
Quote degli ambienti: limitazione delle classi di istanza/magazzino.
Igiene automatica: TTL per le risorse UV, regole di reticenza dei botti/logi.
Spot/Preemptile per attività non ritiche, ridondanza per protesi.

14) Processi di migrazione/modifica

«terraform import» per le risorse legasi (subito dopo - «piano »/« apply»).
«moved »/« removed» blocchi di rifacimento per evitare danni.
Zero-downtime modifiche - Doppia mappatura (blue-green) per i contorni critici (database/bilanciatori).
PR passo passo: prima nuovo gruppo di risorse, poi traffico, poi smontaggio.

15) Sicurezza e conformità

Least private: i moduli creano solo i diritti necessari, non utilizzano ".
KMS everywhere: crittografia di volumi/bacap/segreti/strage.
Scan Terraform/IaC in CI (SAST per il IaC).
I segreti fuori dal Git sono solo gestori di segreti; rotazione e controllo dell'accesso.
Zone PII: tag/criteri di accesso, divieto di esportazione interregionale.

16) Esempi di modelli

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) Assegno-foglio di implementazione

1. Selezionare la struttura del repository (moduli monorepo + directory degli ambienti).
2. Configurare remote state con blocchi e crittografia (KMS).
3. Inserisci GitOps-pipline: fmt/validate/tflint/plan n'review n'apply.
4. Formate una libreria di moduli (VPC, K8s, database, code, monitoraggio, CDN, segreti).
5. Attivare Policy-as-Code (OPA/Sentinel) e scansioni in CI.
6. Organizzate i segreti tramite manager, chiavi - KMS, rotazioni.
7. Aggiungi i test: Terratest per i moduli critici, Infracost per PR.
8. Definisci SLO/alert e «monitoraggio come codice».
9. Impostare quote/budget e TTL per le risorse non ritriche.
10. Pianificare la migrazione in modo graduale (blue-green/doppio binario).

18) Antipattern

I fiocchi di neve manuali fuori Terraform hanno → la deriva e gli incidenti con «apply».
Conservazione locale/senza blocchi di gara e perdita di consistenza.
Segreti in Git/in «.tfvars» senza crittografia.
Il modulo God per centinaia di risorse non può essere testato o riutilizzato.
Dritto «apply» da un portatile a un portatile senza PR e piano-ringhiera.
Ignorare Policy-as-Code/scene di fuoriuscite, IP/baguette pubbliche.
L'assenza di budget/budget infracost è un costo imprevedibile.

Riepilogo

Terraform/IaC fornisce alla piattaforma iGaming riproduzione, velocità e sicurezza controllata/costo. Il design modulare, lo stato rigoroso e la sicurezza, le politiche di sicurezza, gli autoveicoli e le trasformano l'infrastruttura in una catena di montaggio affidabile: rilasci veloci senza downtime, p99 prevedibile e preparazione ai tornei di punta e ai requisiti regolatori.