Terraform и Infrastructure as Code

(Abschnitt: Technologie und Infrastruktur)

Kurze Zusammenfassung

Terraform ist das grundlegende IaC-Tool für den reproduzierbaren und überprüfbaren Aufbau einer iGaming Cloud-Infrastruktur: VPC/Subnetze, Balancer, DB/Cluster, Warteschlangen/Busse, KMS/Secrets, Kubernetes-Cluster, CDN und Monitoring. Der Erfolg beruht auf einer modularen Architektur, einer strikten Politik von Staten und Sperren, einem GitOps-Ansatz für Veröffentlichungen, Policy-as-Code, automatisierten Tests und transparenten FinOps.

1) IaC-Prinzipien für iGaming

Deklarativität: Die Infrastruktur wird durch einen Code beschrieben; manuelle Schritte gibt es nicht.
Idempotenz: Ein wiederholtes' apply 'ergibt das gleiche Ergebnis.
Trennung von Umgebungen: 'dev/stage/prod' aus einem einzigen Code mit Parametern.
Modulkomposition: Einheitlicher Modulkatalog für VPC, DB, Warteschlangen, K8s, Überwachung.
Standard-Sicherheit: private Subnetze, mTLS, minimale IAM-Rechte.
Beobachtbarkeit und Kosten: Metriken/Alerts/Budgets - auch unter Terraform.

2) Repository-Struktur

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/

Die Alternative ist ein modulares Repo (ein separates Repository für jedes Modul) + Verbraucher.

3) Grundlegende Modularität (HCL-Beispiel)

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) Betriebsführung (Zustand) und Sperren

Remote Backend (z.B. Objektspeicher) + Sperren (DynamoDB/Blob-Lock) - verhindern 'apply' Rennen.
Backend-Versionierung und State-Verschlüsselung (KMS).
Zugangsregeln: Nur CI/CD und „infra owners“ haben „apply“ Rechte; Entwickler - „plan“.

• Workspaces sind praktisch für ähnliche Umgebungen (Replikation),
• Separate Kataloge - für klar isolierte Konfigurationen und unterschiedliche Topologien.

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) Variablen, Geheimnisse und sensible Daten

variables. tf + .tfvars für Umgebungen; sensitive = true für private Werte.
Geheimnisse werden nicht in Git gespeichert. Nutzen Sie die Consumption aus dem Secret Manager/KMS über die Datenquelle oder den Provider.
Standardverschlüsselung: für Volumes/Backups/Snapshots/Datenbanken.
Rotation: Schlüssel und Passwörter werden automatisch rotiert.

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

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

6) GitOps und CI/CD für Terraform

PR-Flow: 'terraform fmt' → 'init' → 'validate' → 'tflint' → 'plan' mit Ausgabe in PR → manueller approve → 'apply' von CI.
Förderung von Umgebungen: Änderungen zuerst in 'stage', dann tag/merge in 'prod'.
Protokolle und Artefakte: Plan und Diffus beibehalten, Artefakt-Bericht.

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)

Das Ziel: unsichere/teure Änderungen automatisch ablehnen.

• Die Verschlüsselung von Ressourcen ist obligatorisch.
• Öffentliche IPs - nur über die Ausschlussliste.
• Begrenzung der Größe von Instanzen/Clustern nach Umgebung.
• Erforderliche Tags: 'env', 'owner', 'cost _ center'.

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

8) IaC-Prüfung

terraform validate - Grundlegende Überprüfung der Syntax.
tflint - Stil/Anti-Pattern/anbieterspezifisch.
Infracost ist eine vorläufige Kostenschätzung in der PR.
Terratest - Integrationstests (Go): Anheben/Prüfen/Abreißen des Standes.
Kitchen-Terraform - Unit-Tests mit Ressourcen-Invarianten.
Drift-Detail: Periodischer 'Plan' im Read-Only und Alarmierung bei Russynchron.

9) Typische Module für die iGaming-Plattform

Netz

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

Daten

MySQL/PostgreSQL: Multi-AZ, PITR, `auto_minor_version_upgrade`.
Redis/Memcached: Multi-AZ, Snapshot/TTL-Richtlinien.
Data Lake/Lakehouse: Baquets, Policies, Tables (Katalog/Metastore).
ClickHouse/OLAP-Cluster: Sharding/Replikation, festplattenbasierte Richtlinien.

Busse/Warteschlangen

Kafka/Pulsar/verwaltete-Varianten, ACL, Retention, Schemata-Register.

K8s

EKS/AKS/GKE с NodeGroups, taints/tolerations, IRSA/Workload Identity, Ingress/Service Mesh, autoscaling.
Integration von External Secrets, Prometheus/Grafana, Loki/ELK, cert-manager.

Edge/CDN

CDN-Verteilung, Caching-Regeln, WAF, Bot-Mitigationen.

10) Variables/Outputs/locals - Praxis

locals für berechnete Werte (Masken, Namen).
Ausgaben als Modul-API: Minimum erforderlich.
Ressourcen benennen:'<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 und Regionen

Abstraktion durch gleiche Module, verschiedene Anbieter: 'aws', 'azurerm', 'google'.
Provider alias für regionalübergreifende Ressourcen (DR/Replikation).
Die Unterschiede der Dienste werden durch Bedingungen und Ficheflags in den Modulen geschlossen.
Daten werden lokalisiert: Einzelne Baketen/DBs nach Region (EU/TR/LATAM).

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

12) Beobachtbarkeit und Warnungen als Code

Dashboards, Alert-Regeln (p95/p99, Fehlerrate, CPU/IO), SLO-Monitore.
Zugriffs-/Auditprotokolle (WORM), Kostenmetriken (nach Tag/Namespace).
Vorfälle: Chat-Benachrichtigungen, Runbooks URLs in Ressourcenanmerkungen.

13) FinOps: Kosten unter Kontrolle

Infracost in PR + Budget Alerts.
Umfeldkontingente: Einschränkung der Instanz-/Lagerklassen.
Auto-Hygiene: TTL für dev-Ressourcen, Backet/Log Retention Policy.
Spot/Preemptible für unkritische Aufgaben, Redundanz für Prod.

14) Migrations-/Veränderungsprozesse

„terraform import“ für Legasi-Ressourcen (unmittelbar nach „plan “/„ apply“).
'bewegt '/' entfernt' Blöcke beim Refactoring, um Zerstörung zu vermeiden.
Zero-Downtime-Änderungen: Doppelrollen (blau-grün) für kritische Konturen (OBD/Balancer).
Schritt-für-Schritt-PR: erst neue Ressourcengruppe, dann Verkehr, dann Abbau.

15) Sicherheit und Compliance

Least privilege: Module erstellen nur die Rechte, die Sie benötigen, nicht verwenden ".
KMS everywhere: Verschlüsselung von Volumes/Backups/Secrets/State.
Scan Terraform/IaC in CI (SAST für IaC).
Geheimnisse außerhalb von Git: Nur Manager von Geheimnissen; Rotation und Prüfung des Zugangs.
PII-Zonen: Tags/Zugangsrichtlinien, Verbot interregionaler Exporte.

16) Musterbeispiele

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) Checkliste zur Umsetzung von Terraform/IaC

1. Wählen Sie die Repository-Struktur (Monorepos von Modulen + Umgebungsverzeichnisse).
2. Konfigurieren Sie den Remote State mit Sperren und Verschlüsselung (KMS).
3. Geben Sie GitOps-Pipeline ein: fmt/validate/tflint/plan → review → apply.
4. Bilden Sie eine Bibliothek von Modulen (VPC, K8s, DB, Warteschlangen, Überwachung, CDN, Geheimnisse).
5. Aktivieren Sie Policy-as-Code (OPA/Sentinel) und IaC-Scans im CI.
6. Organisieren Sie Geheimnisse durch Manager, Schlüssel - KMS, Rotation.
7. Tests hinzufügen: Terratest für kritische Module, Infracost in PR.
8. Definieren Sie SLO/Alerts und „Überwachung als Code“.
9. Richten Sie Kontingente/Budgets und TTLs für nicht kritische Ressourcen ein.
10. Planen Sie die Migrationen stufenweise (blau-grün/zweischienig).

18) Antipatterns

Manuelle „Schneeflocken“ Ressourcen außerhalb Terraform → Drift und Crash bei 'apply'.
Lagerung der State lokal/ohne Blockaden → Rennen und Verlust der Konsistenz.
Geheimnisse in Git/in '.tfvars' ohne Verschlüsselung.
Das „God-Modul“ für Hunderte von Ressourcen → die Unfähigkeit zu testen/neu zu verwenden.
Direkte' apply 'von Laptop zu Prod ohne PR und Plan Revue.
Ignorieren von Policy-as-Code/Scans → Lecks, öffentlichen IPs/Baketten.
Das Fehlen von Infracost/Budgets → unvorhersehbare Kosten.

Ergebnisse

Terraform/IaC gibt der iGaming-Plattform Reproduzierbarkeit, Geschwindigkeit und kontrollierte Sicherheit/Kosten. Modulares Design, strenge State- und GitOps, Sicherheitsrichtlinien, Autotests und FinOps machen die Infrastruktur zu einer robusten „Pipeline“ - schnelle Releases ohne Downtime, vorhersehbare p99 und Bereitschaft für Spitzenturniere und regulatorische Anforderungen.