Terraform и Infrastructure as Code

(Раздел: Технологии и Инфраструктура)

Краткое резюме

Terraform — базовый инструмент IaC для воспроизводимого и проверяемого создания облачной инфраструктуры iGaming: VPC/подсети, Балансировщики, БД/кластеры, очереди/шины, KMS/Secrets, Kubernetes-кластеры, CDN и мониторинг. Успех держится на модульной архитектуре, строгой политике стейта и блокировок, GitOps-подходе к релизам, Policy-as-Code, автоматизированном тестировании и прозрачном FinOps.

1) Принципы IaC для iGaming

Декларативность: инфраструктура описана кодом; ручных шагов нет.
Идемпотентность: повторный `apply` дает одинаковый результат.
Разделение окружений: `dev/stage/prod` из единого кода с параметрами.
Композиция модулей: единый каталог модулей для VPC, БД, очередей, K8s, мониторинга.
Безопасность по умолчанию: приватные подсети, mTLS, минимальные IAM-права.
Наблюдаемость и стоимость: метрики/алерты/бюджеты — тоже под Terraform.

2) Структура репозитория

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-пример)

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) Управление стейтом (state) и блокировки

Удаленный backend (например, объектное хранилище) + блокировки (DynamoDB/Blob-lock) — предотвращают гонки `apply`.
Версионирование бэкенда и шифрование стейта (KMS).
Правила доступа: только CI/CD и «infra owners» имеют права `apply`; разработчики — `plan`.

• 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 через data-source или провайдер.
Шифрование по умолчанию: для томов/бэкапов/снапшотов/баз данных.
Rotation: ключи и пароли автоматически ротируются.

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 для Terraform

PR-флоу: `terraform fmt` → `init` → `validate` → `tflint` → `plan` с выводом в PR → ручной approve → `apply` из CI.
Промоушен окружений: изменения сначала в `stage`, затем тег/мердж в `prod`.
Логи и артефакты: сохранение плана и диффа, артефакт-отчет.

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)

Цель: автоматическое отклонение небезопасных/дорогих изменений.

• Шифрование ресурсов обязательно.
• Публичные 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 — предварительная оценка стоимости в PR.
Terratest — интеграционные тесты (Go): поднять/проверить/снести стенд.
Kitchen-Terraform — модульные тесты с инвариантами ресурсов.
Drift-детект: периодический `plan` в read-only и оповещение при рассинхроне.

9) Типовые модули для iGaming-платформы

Сеть

VPC/VNets/VPC-Peering, приватные/публичные сабнеты, маршрутизация, NAT/Firewall, Security Groups/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/managed-варианты, ACL, ретеншн, схем-реестр.

K8s

EKS/AKS/GKE с NodeGroups, taints/tolerations, IRSA/Workload Identity, Ingress/Service Mesh, autoscaling.
Интеграция External Secrets, Prometheus/Grafana, Loki/ELK, cert-manager.

Edge/CDN

CDN-дистрибуции, правила кеширования, WAF, митигации ботов.

10) Variables/Outputs/locals — практика

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) Мультиоблако и регионы

Абстракция через одинаковые модули, разные провайдеры: `aws`, `azurerm`, `google`.
Provider alias для кросс-региональных ресурсов (DR/репликации).
Различия сервисов закрываются условиями и фичефлагами в модулях.
Данные локализуются: отдельные бакеты/БД по регионам (EU/TR/LATAM).

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

12) Наблюдаемость и алерты как код

Дашборды, правила алертов (p95/p99, error-rate, CPU/IO), SLO-мониторы.
Логи доступа/аудита (WORM), метрики стоимости (by tag/namespace).
Инциденты: чат-уведомления, runbooks URLs в аннотациях ресурсов.

13) FinOps: стоимость под контролем

Infracost в PR + бюджетные алерты.
Квоты по окружениям: ограничение классов инстансов/склада.
Авто-гигиена: TTL для dev-ресурсов, политики ретенции бакетов/логов.
Spot/Preemptible для некритичных задач, резервирование для прод.

14) Процессы миграций/изменений

`terraform import` для легаси-ресурсов (сразу после — `plan`/`apply`).
`moved`/`removed` блоки при рефакторинге, чтобы избежать разрушений.
Zero-downtime изменения: двойная раскатка (blue-green) для критичных контуров (БД/балансировщики).
Пошаговые PR: сначала новая ресурсная группа, затем трафик, затем демонтаж.

15) Безопасность и соответствие

Least privilege: модули создают только нужные права, не используют ``.
KMS everywhere: шифрование томов/бэкапов/секретов/стейта.
Скан Terraform/IaC в CI (SAST для IaC).
Секреты вне Git: только менеджеры секретов; ротация и аудит доступа.
PII-зоны: тэги/политики доступа, запрет межрегионального экспорта.

16) Примеры шаблонов

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. Настройте remote state с блокировками и шифрованием (KMS).
3. Введите GitOps-пайплайн: fmt/validate/tflint/plan → review → apply.
4. Сформируйте библиотеку модулей (VPC, K8s, БД, очереди, мониторинг, CDN, секреты).
5. Включите Policy-as-Code (OPA/Sentinel) и сканы IaC в CI.
6. Организуйте секреты через менеджер, ключи — KMS, ротации.
7. Добавьте тесты: Terratest для критичных модулей, Infracost в PR.
8. Определите SLO/алерты и «мониторинг как код».
9. Настройте квоты/бюджеты и TTL для некритичных ресурсов.
10. Планируйте миграции поэтапно (blue-green/двухрельсово).

18) Антипаттерны

Ручные «снежинки» ресурсов вне Terraform → дрейф и аварии при `apply`.
Хранение стейта локально/без блокировок → гонки и потеря консистентности.
Секреты в Git/в `.tfvars` без шифрования.
«God-модуль» на сотни ресурсов → невозможность тестировать/переиспользовать.
Прямой `apply` с ноутбука в прод без PR и план-ревью.
Игнорирование Policy-as-Code/сканов → утечки, публичные IP/бакеты.
Отсутствие Infracost/бюджетов → непредсказуемая стоимость.

Итоги

Terraform/IaC дает iGaming-платформе воспроизводимость, скорость и контролируемую безопасность/стоимость. Модульный дизайн, строгий стейт и GitOps, политики безопасности, автотесты и FinOps превращают инфраструктуру в надежный «конвейер» — быстрые релизы без даунтайма, предсказуемый p99 и готовность к пиковым турнирам и регуляторным требованиям.