Terraform а Infrastruktura jako kod

(Sekcja: Technologia i infrastruktura)

Krótkie podsumowanie

Terraform jest podstawowym narzędziem IaC do odtwarzania i sprawdzania tworzenia infrastruktury chmury iGaming: VPC/podsieci, Balancery, bazy danych/klastry, kolejki/autobusy, KMS/Secrets, klastry Kubernetes, CDN i monitoring. Sukces opiera się na architekturze modułowej, ścisłej polityce stanu i blokady, podejściu GitOps do wydań, polityce jako kodeksie, zautomatyzowanych testach i przejrzystych FinOp.

1) Zasady IaC dla iGaming

Deklaracja: infrastruktura opisana kodem; nie ma żadnych podręczników.
Idempotencja: powtarzane „zastosowanie” daje ten sam wynik.
Oddzielenie środowisk: 'dev/stage/prod' od jednego kodu z parametrami.
Skład modułu: jeden katalog modułów VPC, DB, kolejek, K8s, monitorowania.
Domyślne zabezpieczenia: prywatne podsieci, mTLS, minimalne prawa IAM.
Obserwowalność i koszt: mierniki/wpisy/budżety są również w ramach Terraform.

2) Struktura repozytorium

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/

Alternatywą jest modułowy repo (oddzielne repozytorium dla każdego modułu) + konsumenci.

3) Modułowość podstawowa (przykład 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) Zarządzanie państwem i zamki

Remote backend (na przykład magazynowanie obiektów) + blokady (DynamoDB/Blob-lock) - zapobieganie wyścigom „apply”.
Wersioning backendowy i szyfrowanie stanu (KMS).
Zasady dostępu: tylko CI/CD i „właściciele infra” mają „zastosowanie” prawa; deweloperzy - „plan”.

• Miejsca pracy są wygodne dla podobnych środowisk (replikacja),
• Oddzielne katalogi - dla wyraźnie odizolowanych konfiguracji i różnych 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) Zmienne, tajemnice i dane wrażliwe

zmienne. tf + .tfvars dla środowisk; sensitive = true dla wartości prywatnych.
Tajemnice nie są przechowywane w Git. Użyj programu Secret Manager/KMS za pośrednictwem źródła danych lub dostawcy.
Domyślne szyfrowanie: dla woluminów/kopii zapasowych/migawek/baz danych.
Obrót: klucze i hasła są automatycznie obracane.

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 dla Terraform

Przepływ PR: 'terraform fmt' →' init' → 'validate' → 'tflint' → 'plan' z wyjściem do PR → ręczne zatwierdzenie → 'apply' from CI.
Promocja środowiska: zmiany najpierw w "etapie", następnie znacznik/połączenie w "prod'.
Kłody i artefakty: plan oszczędzania i diffa, artefakt-raport.

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) Kod polityki (OPA/Sentinel)

Cel: automatycznie odrzucić niebezpieczne/drogie zmiany.

• Wymagane jest szyfrowanie zasobów.
• Publiczny IP - tylko poprzez listę wyjątków.
• Ograniczenie wielkości instancji/klastrów według środowiska.
• Wymagane znaczniki: 'na', 'właściciel', 'cost _ center'.

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

8) Badanie IaC

terraform validate-Podstawowa kontrola składni.
tflint - styl/antipatters/dostawca-specyfika.
Infracost - wstępne oszacowanie kosztów w PR.
Terratest - testy integracyjne (Go): lift/check/demolish the stand.
Kuchnia-Terraform - testy jednostkowe z niezmiennymi zasobami.
Wykrywanie dryfów: okresowy „plan” w ostrzeżeniu tylko do odczytu i poza synchronizacją.

9) Typowe moduły dla platformy iGaming

Sieć

VPC/VNets/VPC-Peering, prywatne/publiczne podsieci, routing, NAT/Firewall, Grupy bezpieczeństwa/NSG.
DNS/Failover: Route-литика, health-checks, latency-based routing.

Dane

MySQL/PostgreSQL: Multi-AZ, PITR, 'auto _ minor _ version _ upgrade'.
Redis/Memcached: Multi-AZ, migawka/polityka TTL.
Data Lake/Lakehouse: wiadra, zasady, tabele (katalog/przerzut).
Klastry ClickHouse/OLAP: shardiness/replikacja, zasady dysku.

Autobusy/kolejki

Warianty Kafka/Pulsar/zarządzane, ACL, retencja, systemy rejestru.

K8s

EKS/AKS/GKE NodeGroups, taints/tolerances, IRSA/Workload Identity, Ingress/Service Mesh, autoskalowanie.
Integracja tajemnic zewnętrznych, Prometheus/Grafana, Loki/ELK, cert-manager.

Krawędź/CDN

Dystrybucja CDN, zasady buforowania, WAF, łagodzenie bot.

10) Zmienne/wyjścia/miejscowi - praktyka

miejscowi dla obliczonych wartości (maski, nazwy).
wyjścia jako moduł API: minimum wymagane.
Nazewnictwo zasobu '<α> - <region> - <domain> - <component>'.
Тима: '', 'właściciel', 'cost _ center', 'krytyczność', 'pii'.

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

11) Wielobłok i regiony

Abstrakcja za pośrednictwem tych samych modułów, różnych dostawców: 'aws',' azurerm', 'google'.
Dostawca alias dla zasobów ponadregionalnych (DR/replikacja).
Różnice w obsłudze są zamykane przez warunki i ficheflagi w modułach.
Dane są zlokalizowane: pojedyncze wiadra/DB według regionu (EU/TR/LATAM).

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

12) Obserwowalność i wpisy jako kod

Deski rozdzielcze, zasady ostrzegania (p95/p99, wskaźnik błędów, CPU/IO), monitory SLO.
Dzienniki dostępu/audytu (WORM), mierniki kosztów (według tagu/obszaru nazw).
Incydenty: powiadomienia o czacie, URL zakładek w adnotacjach zasobów.

13) FinOps: Wartość pod kontrolą

Infracost w PR + wpisy budżetowe.
Kontyngenty środowiskowe: klasa instancji/magazynu ograniczająca.
Automatyczna higiena: TTL dla zasobów dev, zasady retencji wiadra/dziennika.
Spot/Preemptible for non-critical tasks, reservation for Prod.

14) Procesy migracji/zmiany

„terraform importu” dla zasobów prawnych (bezpośrednio po - „plan ”/„ zastosowanie”).
„przeniesione ”/„ usunięte” bloki podczas refaktorowania w celu uniknięcia zniszczenia.
Zero-przestojów: podwójne walcowanie (niebiesko-zielone) dla konturów krytycznych (DB/balancery).
Krok po kroku PR: nowa grupa zasobów najpierw, następnie ruch, a następnie demontaż.

15) Bezpieczeństwo i zgodność

Najmniejszy przywilej: moduły tworzą tylko niezbędne prawa, nie korzystają "

KMS wszędzie: szyfrowanie woluminów/kopii zapasowych/tajemnic/stanów.
Terraform/IaC skanowanie w CI (SAST dla IaC).
Sekrety poza Git: Tylko tajne menedżerów; kontrola rotacji i dostępu.
Strefy PII: znaczniki/polityki dostępu, międzyregionalny zakaz wywozu.

16) Przykładowe szablony

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 kontrolna wykonania Terraform/IaC

1. Wybierz strukturę repozytorium (monorepos moduł + katalogi środowiskowe).
2. Skonfiguruj stan zdalny za pomocą blokad i szyfrowania (KMS).
3. Wprowadź GitOps-pipeline: fmt/validate/tflint/plan → review → apply.
4. Utwórz bibliotekę modułów (VPC, K8s, DB, kolejki, monitoring, CDN, sekrety).
5. Włącz skanowanie zasad-as-Code (OPA/Sentinel) i IaC w CI.
6. Organizuj sekrety przez menedżera, klucze - KMS, obroty.
7. Dodaj testy: Terratest dla modułów krytycznych, Infracost w PR.
8. Zdefiniuj SLO/wpisy i „monitorowanie jako kod”.
9. Ustanowienie kwot/budżetów i TTL dla zasobów innych niż krytyczne.
10. Planowanie migracji etapami (niebiesko-zielona/dwosilnikowa).

18) Antypattery

Ręczne „płatki śniegu” zasobów poza Terraform → dryf i wypadki, gdy „zastosowanie”.
Przechowywanie stanu lokalnie/bez zamków → wyścigi i utrata spójności.
Sekrety w Git/in '.tfvars' bez szyfrowania.
„Moduł Boga” dla setek zasobów → niemożność przetestowania/ponownego wykorzystania.
Bezpośrednie „zastosowanie” od laptopa do żywności bez PR i przeglądu planu.
Ignorowanie polityki-as-Code/skany → wycieki, publiczne wiadra IP.
Brak Infracost/budżety → nieprzewidywalny koszt.

Podsumowanie

Terraform/IaC daje platformie iGaming odtwarzalność, prędkość i kontrolowane bezpieczeństwo/koszt. Modułowa konstrukcja, rygorystyczny stan i GitOps, polityka bezpieczeństwa, autotezy i FinOps przekształcają infrastrukturę w niezawodny „rurociąg” - szybkie wydania bez przestojów, przewidywalne p99 i gotowość do turniejów szczytowych i wymagań regulacyjnych.