Terraform и Infrastructure as Code
（部分： 技術和基礎設施）
簡短摘要
Terraform是用於可重現和可驗證的iGaming雲基礎架構創建的基本的IaC工具：VPC/子網，平衡器，DB/群集，隊列/總線，KMS/Secrets，Kubernetes群集，CDN和監視。成功取決於模塊化體系結構，嚴格的州和鎖定策略，GitOps發行方法，策略即代碼，自動測試和透明的FinOps。
1） iGaming的IaC原則
聲明性：基礎架構由代碼描述；沒有手動步驟。
相等性：重復的「應用」產生相同的結果。
環境分隔：「dev/stage/prod」 （dev/stage/prod）來自具有參數的單個代碼。
模塊組成：用於VPC，DB，隊列，K8s和監視的單個模塊目錄。
默認安全性：私有子網、mTLS、最低IAM權限。
可觀察性和成本：度量/Alerta/預算-也在Terraform下。
2）資料庫結構
Monorepo變體（示例）：
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/另一種選擇是模塊化回購（每個模塊的獨立存儲庫）+消費者。
3）基本模塊化（HCL示例）
VPC模塊（模塊/vpc/main。tf):
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 }模塊消耗（envs/prod/eu-west/main）。tf):
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）牛排管理（州）和鎖定
遠程後端（例如對象存儲）+鎖定（DynamoDB/Blob-lock）-防止「應用」競賽。
後端驗證和狀態加密（KMS）。
訪問規則：只有CI/CD和「infra owners」具有「應用」權利；開發人員是「計劃」。
- Workspaces適用於相似的環境（復制），
- 單獨的目錄-用於明確隔離的配置和不同的拓撲結構。
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）變量、秘密和敏感數據
variables.環境的tf +.tfvars；對於私有值，sensitive=true。
秘密不存儲在Git中。通過數據源或提供商使用Secret Manager/KMS中的應用程序。
默認加密：用於卷/備份/快照/數據庫。
旋轉：密鑰和密碼會自動輪換。
hcl variable "db_password" {
type = string sensitive = true
}
data "external_secret" "db_password" {
conceptual secret source name = "prod/payments/db_password"
}6） GitOps和CI/CD for Terraform
PR流通：「terraform fmt」 「init」 「validate」 「tflint」 「plan」，並從CI手動取樣 「apply」。
環境推廣：首先在「舞臺」中進行更改，然後在「prod」 中進行標記/merge。
徽標和文物：保存計劃和誹謗，文物-報告。
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 tfplan7) Policy-as-Code (OPA/Sentinel)
目的：自動消除不安全/昂貴的變化。
策略示例：- 資源加密是強制性的。
- 公共IP-僅通過例外列表。
- 限制周圍環境的實例/群集的大小。
- 必修標簽：「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測試
terraform validate-基本語法檢查。
tflint-樣式/反模式/提供程序。
Infracost-公關的初步成本估計。
Terratest-集成測試（Go）：擡起/檢查/拆除展位。
Kitchen-Terraform是具有資源不變性的模塊化測試。
Drift detection：只讀的周期性「計劃」和同步警報。
9）iGaming平臺的典型模塊
網絡
VPC/VNets/VPC-Peering，私有/公共安全套，路由，NAT/Firewall，安全組/NSG。
DNS/Failover: Route-политики, health-checks, latency-based routing.
數據
MySQL/PostgreSQL: Multi-AZ, PITR, `auto_minor_version_upgrade`.
Redis/Memcached：Multi-AZ，snapshot/TTL策略。
Data Lake/Lakehouse：垃圾箱，政策，表（目錄/轉移）。
ClickHouse/OLAP群集：硬化/復制、磁盤策略。
總線/隊列
Kafka/Pulsar/托管變體，ACL，重組，註冊表方案。
K8s
EKS/AKS/GKE с NodeGroups, taints/tolerations, IRSA/Workload Identity, Ingress/Service Mesh, autoscaling.
外部秘密，Prometheus/Grafana，Loki/ELK，證書管理器的集成。
Edge/CDN
CDN分布，積壓規則，WAF，機器人聯位。
10） Variables/Outputs/locals-實踐
可計算值（掩碼、名稱）的局部值。
outputs作為模塊API：最低要求。
命名資源：'<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） Multioblaco和地區
通過相同的模塊，不同的提供商進行抽象：'aws'，'azurerm'，'google'。
跨區域資源的Provider alias（DR/復制）。
服務差異通過條款和模塊中的拼寫來結束。
數據是本地化的：按區域劃分的單個垃圾箱/DB（EU/TR/LATAM）。
hcl provider "aws" { region = "eu-west-1" alias = "eu" }
provider "aws" { region = "sa-east-1" alias = "latam" }12）可觀察性和差異作為代碼
Dashbords，Alert規則（p95/p99，error-rate，CPU/IO），SLO監視器。
訪問/審核邏輯（WORM），成本指標（通過tag/namespace）。
事件： 聊天通知,runbooks URL在資源註釋.
13） FinOps： 控制成本
公關+預算差中的基礎設施。
環境配額：限制實例/倉庫類別。
自動衛生：用於開發資源的TTL，垃圾箱/博客回避政策。
用於非關鍵任務的Spot/Preemptible，用於prod的冗余。
14）遷移/更改過程
用於法律資源的「terraform import」（緊隨其後的是「計劃」/「應用」）。
重構時的「moved」/「removed」塊以避免破壞。
零時速變化：關鍵輪廓（DB/平衡器）的雙滾動（藍綠色）。
回合制PR：首先是新的資源組，然後是流量，然後是拆卸。
15）安全性和合規性
Least privilege： 模塊僅創建所需的權利,不使用。"
KMS無處不在：卷/備份/秘密/狀態加密。
CI中的Terraform/IaC掃描（IaC的SAST）。
Git以外的秘密：只有秘密經理；訪問輪換和審核。
PII區：標簽訪問政策，禁止區域間出口。
16）模式示例
與PITR的關系DB（想法）：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） Terraform/IaC實施支票
1.選擇存儲庫結構（模塊的單拷貝+環境目錄）。
2.使用鎖定和加密（KMS）配置遠程狀態。
3.輸入GitOps管道：fmt/validate/tflint/plan → review → apply。
4.形成模塊庫（VPC、K8s、DB、隊列、監視、CDN、秘密）。
5.在CI中包括Policy-as-Code （OPA/Sentinel）和IaC掃描。
6.通過經理組織秘密，密鑰是KMS，輪換。
7.添加測試：關鍵模塊的Terratest,公關中的Infracost。
8.定義SLO/Alerts和「監視為代碼」。
9.為非關鍵資源配置配額/預算和TTL。
10.分階段規劃遷移（藍綠色/雙軌）。
18）反模式
Terraform之外的手動「雪花」資源在「應用」時→漂移和事故。
在本地/沒有鎖定的情況下存儲狀態→比賽和失去一致性。
「.tfvars」中沒有加密的秘密。
數百個資源的「上帝模塊」→無法測試/重新使用。
直接從筆記本電腦的「應用」到沒有公關的插圖和評論計劃。
忽略策略即代碼/掃描→泄漏，公共IP/垃圾箱。
缺少Infracost/預算 →不可預測的成本。
結果
Terraform/IaC為iGaming平臺提供了可重復性，速度和可控的安全性/成本。模塊化設計，嚴格的州和GitOps，安全政策，自動測試和FinOps將基礎設施轉變為可靠的「管道」-快速發布而沒有市區，可預測的p99以及高峰錦標賽和監管要求的準備。