Terraform и infrastructură ca cod

(Secțiunea: Tehnologie și infrastructură)

Scurt rezumat

Terraform este instrumentul de bază IaC pentru crearea reproductibilă și verificabilă a infrastructurii cloud iGaming: VPC/subrețele, Balancers, baze de date/clustere, cozi/autobuze, KMS/Secrets, clustere Kubernetes, CDN și monitorizare. Succesul se bazează pe o arhitectură modulară, politici stricte de stat și de blocare, abordarea GitOps a versiunilor, Policy-as-Code, testarea automată și FinOps transparente.

1) Principiile IaC pentru iGaming

Declarativ: infrastructură descrisă prin cod; nu există pași manuali.
Idempotența: repetarea „aplicării” dă același rezultat.
Separarea mediilor: "dev/stage/prod' dintr-un singur cod cu parametri.
Compoziția modulului: un singur catalog de module pentru VPC, DB, cozi, K8s, monitorizare.
Securitate implicită: subrețele private, mTLS, drepturi IAM minime.
Observabilitate și cost: metrici/alerte/bugete sunt, de asemenea, sub Terraform.

2) Structura depozitului

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 este un repo modular (un depozit separat pentru fiecare modul) + consumatori.

3) Modularitate de bază (exemplu 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) Managementul de stat și încuietori

Backend de la distanță (de exemplu, stocarea obiectelor) + încuietori (DynamoDB/Blob-lock) - împiedică cursele „apply”.
Versionare backend și criptare de stat (KMS).
Reguli de acces: numai CI/CD și „proprietarii infraroșii” au drepturi de „aplicare”; dezvoltatori - „plan”.

• Spațiile de lucru sunt convenabile pentru medii similare (replicare),
• Directoare separate - pentru configurații clar izolate și diferite topologii.

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) Variabile, secrete și date sensibile

variabile. tf + .tfvars pentru medii; sensibil = adevărat pentru valorile private.
Secretele nu sunt stocate în Git. Utilizați Managerul Secret/KMS prin intermediul sursei de date sau al furnizorului.
Criptare implicită: pentru volume/backup-uri/instantanee/baze de date.
Rotație: cheile și parolele sunt rotite automat.

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

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

6) GitOps și CI/CD pentru Terraform

Fluxul PR: "terraform fmt' " init " " validate " " tflint " " plan "cu ieșire la PR manualul" apply "de la CI.
Promovarea mediului: modificări în primul rând în "etapă", apoi tag/îmbinare în "prod'.
Jurnale și artefacte: plan de economisire și raport diferit, artefact.

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)

Scop: respinge automat modificările nesigure/costisitoare.

• Este necesară criptarea resurselor.
• IP publică - numai prin lista de excepții.
• Limitarea dimensiunii instanțelor/clusterelor în funcție de mediu.
• Etichete necesare: 'env', 'owner', 'cost _ center'.

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

8) Testarea IaC

verificarea sintaxei terraform validate-Basic.
tflint - stil/antipatterns/furnizor-specificitate.
Infracost - estimare preliminară a costurilor în PR.
Terratest - teste de integrare (Go): ridicare/verificare/demolare stand.
Kitchen-Terraform - teste de unitate cu invarianți de resurse.
Detectarea în derivă: „plan” periodic în alertă numai pentru citire și în afara sincronizării.

9) Module tipice pentru platforma iGaming

Reţea

VPC/VNets/VPC-Peering, subrețele private/publice, rutare, NAT/Firewall, Grupuri de securitate/NSG.
DNS/Failover: Route- политики, controale de sănătate, rutare bazată pe latență.

Date

MySQL/PostgreSQL: Multi-AZ, PITR, 'auto _ minor _ version _ upgrade'.
Redis/Memcached: Multi-AZ, politici instantaneu/TTL.
Data Lake/Lakehouse: găleți, politici, tabele (catalog/metastor).
ClickHouse/clustere OLAP: timiditate/replicare, politici de disc.

Autobuze/cozi

Kafka/Pulsar/gestionate variante, ACL, retenție, scheme de registru.

K8s

EKS/AKS/GKE с NodeGroups, patts/tolerations, IRSA/Workload Identity, Ingress/Service Mesh, autoscaling.
Integrarea secretelor externe, Prometheus/Grafana, Loki/ELK, cert-manager.

Edge/CDN

Distribuția CDN, regulile de caching, WAF, atenuarea bot.

10) Variabile/Ieșiri/localnici - practică

localnici pentru valori calculate (măști, nume).
ieșiri ca API modul: minim necesar.
Denumirea resurselor '<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) Multi-cloud și regiuni

Abstracție prin aceleași module, furnizori diferiți: „aws',” azurerm', „google”.
Furnizor alias pentru resurse transregionale (DR/replicare).
Diferențele de serviciu sunt închise de condiții și phicheflags în module.
Datele sunt localizate: găleți individuale/DB pe regiuni (EU/TR/LATAM).

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

12) Observabilitate și alerte ca cod

Tablouri de bord, reguli de alertă (p95/p99, rata de eroare, CPU/IO), monitoare SLO.
Jurnalele de acces/audit (WORM), valorile costurilor (după tag/namespace).
Incidente: notificări de chat, URL-uri runbooks în adnotări de resurse.

13) FinOps: Valoarea sub control

Infracost în alerte de buget PR +.
Cote de mediu: limitarea claselor de instanță/depozit.
Auto-igienă: TTL pentru resurse dev, politici de retenție găleată/jurnal.
Spot/Preventibil pentru sarcini non-critice, rezervare pentru Prod.

14) Procese de migrare/schimbare

„import terraform” pentru resurse juridice (imediat după - „plan ”/„ aplicare”).
„moved ”/„ eliminat” blocuri atunci când refactoring pentru a evita distrugerea.
Zero-downtime modificări: dublu de rulare (albastru-verde) pentru contururi critice (DB/balansoare).
Pas cu pas PR: nou grup de resurse mai întâi, apoi trafic, apoi dezmembrare.

15) Siguranță și conformitate

Cel mai puțin privilegiu: modulele creează numai drepturile necesare, nu folosesc "

KMS peste tot: criptarea volumelor/backup-urilor/secretelor/stărilor.
Scanare terraformă/IaC în CI (SAST pentru IaC).
Secretele din afara Git: Manageri secreți Numai; audit de rotație și acces.
Zone PII: etichete/politici de acces, interregionale interdictie de export.

16) Șabloane de probă

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 verificare a implementării Terraform/IaC

1. Selectați structura depozitului (modul monorepos + directoare de mediu).
2. Configurați starea de la distanță cu încuietori și criptare (KMS).
3. Introduceți GitOps-pipeline: se aplică fmt/validate/tflint/plan → revizuire →.
4. Creați o bibliotecă de module (VPC, K8s, DB, cozi, monitorizare, CDN, secrete).
5. Activați scanările Policy-as-Code (OPA/Sentinel) și IaC în CI.
6. Organizați secrete prin manager, chei - KMS, rotații.
7. Adăugați teste: Terratest pentru module critice, Infracost în PR.
8. Definiți SLO/alerte și „monitorizarea ca cod”.
9. Stabilirea de cote/bugete și TTL pentru resurse non-critice.
10. Planificarea migrațiilor în etape (albastru-verde/cu două căi ferate).

18) Antipattern

Manual „fulgi de zăpadă” de resurse în afara Terraform → derivă și accidente atunci când „se aplică”.
Stocarea unei stări la nivel local/fără încuietori → curse și pierderea consistenței.
Secrete în Git/în '.tfvars' fără criptare.
„Modulul Dumnezeu” pentru sute de resurse → incapacitatea de a testa/reutiliza.
Direct „se aplică” de la laptop la alimente fără PR și revizuirea planului.
Ignorarea politicii ca cod/scanări → scurgeri, IP/găleți publice.
Lipsa de Infracost/bugete → costuri imprevizibile.

Rezumat

Terraform/IaC oferă platformei iGaming reproductibilitate, viteză și siguranță/cost controlat. Designul modular, starea strictă și GitOps, politicile de securitate, autotesturile și FinOps transformă infrastructura într-o „conductă” fiabilă - lansări rapide fără întreruperi, p99 previzibil și disponibilitate pentru turnee de vârf și cerințe de reglementare.