Terraform в команде

ОБЯЗАТЕЛЬНО

Разработчику Архитектору Инженеру

---

Terraform в команде

Один разработчик может держать Terraform на ноутбуке. В компании добавляются review, compliance, on-call и разные cadence у приложения и инфраструктуры. Ниже — процессы, которые обычно вводят после первых успешных модулей.

---

Внедрение IaC

Переход с ручной консоли — инвестиция: новые навыки у ops, новые инструменты у dev, сдвиг мышления («сначала PR, потом apply»). Убеждать менеджмент лучше болью, которую IaC снимает (простои при деплое, drift staging/prod, часы на восстановление), а не списком «Terraform декларативный».

Практичный старт:

• один некритичный сервис или sandbox VPC;
• постепенное перенесение стеков в live/ (структура);
• обучение на практическом пути.

Иногда IaC не окупается (короткий прототип, один сисадмин) — это нормальный вывод из аудита, а не провал.

---

Золотое правило Terraform

Окружение	plan	apply
Dev / sandbox	Локально	Локально допустим
Staging	CI на каждый PR	CI после approve, или Atlantis
Production	CI, артефакт plan	Только pipeline после merge; локальный apply запрещён

Дополнительно:

• весь HCL в Git, state в remote backend с lock;
• никаких «быстрых правок» в AWS Console для ресурсов под Terraform — только через код (drift);
• версии Terraform, провайдеров и модулей зафиксированы (.terraform.lock.hcl).

---

Два пайплайна — приложение и инфраструктура

App repo:     push → build → test → deploy image → K8s/VM
Infra repo:   PR → validate → plan (comment) → approve → apply

Разбор:

• Приложение меняется часто (десятки раз в день); VPC/RDS/IAM — реже, но ошибка дороже.
• Infra PR ревьюят SRE/архитектор; app PR — feature team.
• App deploy может читать outputs infra (subnet IDs, RDS endpoint) через remote state или service discovery.

---

Code review для HCL

Чек-лист ревьюера:

• diff plan — только ожидаемые изменения, нет mass destroy;
• секреты не в коде, sensitive на outputs;
• prevent_destroy на state bucket, prod DB;
• новые модули — pin version, документированы variables;
• IAM — least privilege (211.md).

Стиль: terraform fmt, осмысленные имена ресурсов, мелкие модули (промышленный уровень — composable modules).

---

Atlantis, Terraform Cloud, GitHub Actions

Atlantis — bot в PR: комментарий atlantis plan / atlantis apply, lock на директорию, audit trail.

HCP Terraform / Terraform Cloud — remote run, policy (Sentinel/OPA), run triggers между workspace.

GitHub Actions — минимальный workflow:

on:
  pull_request:
    paths: ['live/**']
jobs:
  plan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: hashicorp/setup-terraform@v3
      - run: terraform init
        working-directory: live/stage/services/webserver-cluster
      - run: terraform plan -no-color -input=false
        working-directory: live/stage/services/webserver-cluster

Apply в prod — отдельный workflow workflow_dispatch или push в main с environment protection rules.

---

Реалистичные сроки prod-инфраструктуры

Ориентиры для опытной команды (идеальный случай):

Тип	Пример	Срок
Managed сервис	RDS	1–2 недели
Stateless app на ASG	Node-кластер	2–4 недели
Stateful self-hosted	Elasticsearch на ASG	2–4 месяца
Полная архитектура	app + сеть + мониторинг + security	6–36 месяцев

Terraform ускоряет повторяемость, но не отменяет проектирование HA, backup и runbook.

---

См. также

• Тестирование Terraform — gate перед prod apply.
• Git и GitFlow — GitOps и ветки.
• Инфраструктура как код — классы инструментов.
• GitHub Actions — полные workflow.