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 і готовність до пікових турнірів і регуляторних вимог.