3.8.3 · блок 3
Terraform в команде и CI
Terraform в команде и CI
Зачем это нужно
Terraform на laptop одного админа не масштабируется. Remote state, state locking, plan в CI, policy-as-code, разделение dev/stage/prod — без этого IaC превращается в страшилку: два apply одновременно, corrupt state, prod изменён без review. ML-команда зависит от стабильной платформы — понимание этого конвейера помогает не «просить открыть порт», а оформить изменение через правильный MR.
Основные идеи
Remote backend. State в S3/MinIO/GCS + lock (DynamoDB, native S3 lock, Consul). Два apply не бегут параллельно — второй ждёт lock или падает с ошибкой.
Branch → environment.
| Ветка / каталог | Окружение | Apply |
|-----------------|-----------|-------|
| `environments/dev` | dev | auto on merge |
| `environments/prod` | prod | manual approval |
Альтернатива: один код + разные *.tfvars + Terraform Cloud workspaces.
CI pipeline stages (типично).
1. terraform fmt -check — форматирование
2. terraform validate — синтаксис
3. terraform plan — diff артефакт
4. (optional) policy check — OPA/Sentinel/Checkov: «запрещён public S3»
5. terraform apply — только protected branch + approval
Plan в MR comment. Reviewer видит: «+1 bucket, ~1 security group» без доступа к облаку. ML engineer может проверить, что создаётся bucket ml-capstone-2026, а не prod models.
Secrets в Terraform. Не хардкодить в .tf:
- CI variables (masked)
- Vault / cloud secret manager data source
-varиз секретного хранилища в runtime apply
IAM least privilege. CI service account Terraform: права только на нужные resource types. Prod apply — отдельная role с MFA/approval.
Drift detection. Scheduled terraform plan nightly — alert если кластер изменён вручную. Связь с GitOps: Argo лечит K8s drift внутри кластера; Terraform — drift вне или node-level infra.
Destroy policy. terraform destroy на prod — запрещён или требует ticket. prevent_destroy на критичных resource.
Связь с MDP stack. Terraform поднимает: кластер, LB, DNS, MinIO tenant, возможно установку Argo CD bootstrap. Helm charts для Longhorn/Istio — следующий слой (Helm provider или Argo Application из Terraform — pattern «cluster bootstrap»).
Как это выглядит на практике
Пример GitHub Actions / Jenkins stage (псевдо):
steps:
- run: terraform init -backend-config=backend-dev.hcl
- run: terraform plan -var-file=dev.tfvars -out=plan.tfplan
- run: terraform show -no-color plan.tfplan > plan.txt
# upload plan.txt as MR artifact
Apply job:
when: branch == main && manual_approval
steps:
- run: terraform apply -auto-approve plan.tfplan
Rollback infra. Terraform не «undo» как git revert автоматически — откат = новый commit с прежними values + apply. Для stateful ресурсов snapshot до change.
Запрос от ML-команды (правильный путь).
1. Issue: «нужен bucket ml-team-alpha-datasets, lifecycle 90 days»
2. Platform MR в modules/s3-bucket + dev.tfvars / prod.tfvars
3. Plan review → apply → output endpoint в документации team
Неправильный путь: создать bucket в MinIO UI и не занести в Terraform. Terraform обычно не удаляет ресурсы, которых нет в его state; реальные риски — drift, конфликт имён при следующем apply и дублирование неуправляемой инфраструктуры. Импортируйте ресурс в state или оформите его декларативно в Terraform.
Observability IaC. Логи apply в Loki; метрики duration apply; alert на failed apply prod.
Что сделать после занятия
- [ ] Найдите в CI платформы (или учебного repo) job с
terraform planи опишите триггер apply. - [ ] Объясните, зачем state lock при параллельных MR двух команд.
- [ ] Сформулируйте один запрос к platform через Terraform MR (bucket, quota, DNS) для своего capstone.