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以及高峰锦标赛和监管要求的准备。