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 (Аутентификация и авторизация в CI/CD-средах).

Стиль — 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.

Terraform в команде