Terraform — это инструмент инфраструктуры как кода (Infrastructure as Code). С его помощью инфраструктуру (виртуальные машины, сеть, хранилища, DNS, managed-сервисы и т. п.) описывают в виде текстовых конфигураций, хранят в системе контроля версий и автоматически приводят облако к описанному состоянию. Это даёт воспроизводимость, прозрачность изменений и возможность ревью/автоматизации развёртываний.

Основные концепты и как это работает

• HCL (конфигурации) — читаемый язык для описания provider, resource, variable, output, модулей и т.д.

• Providers — плагины, через которые Terraform общается с API облаков и сервисов.

• Resources — объекты, которыми управляет Terraform (vm, subnet, bucket и т. п.).

• State (terraform.tfstate) — локальное или удалённое представление текущего состояния созданных ресурсов; Terraform использует state, чтобы вычислить разницу между текущим и желаемым состоянием.

• Plan & Apply — terraform plan показывает, какие изменения будут, terraform apply применяет их. Двухшаговый процесс предотвращает непреднамеренные изменения.

• Modules — переиспользуемые блоки конфигурации для вынесения повторяющейся логики.

• Workspaces — удобный способ держать несколько инстансов окружений (dev/stage/prod) в рамках одной конфигурации (иногда заменяют на отдельные state/backends).

Полезные команды (коротко)

• terraform init — инициализация провайдеров и бекенда.

• terraform fmt — приведение кода к единому стилю.

• terraform validate — базовая проверка конфигурации.

• terraform plan — предпросмотр изменений.

• terraform apply — применение изменений.

• terraform destroy — удаление управляемых ресурсов.

• terraform import — импорт существующих ресурсов в state.

Практики и архитектура для команды

• Remote state + locking: храните state в удалённом бекенде (S3, GCS, Terraform Cloud и т.д.) с блокировкой, чтобы команда не портила состояние.

• Версионирование провайдеров и Terraform: фиксируйте версии, чтобы избежать сюрпризов при апдейтах.

• Модули и разделение на слои: network, infra, apps — каждый слой отдельным модулем/репозиторием.

• CI/CD: в PR запускать terraform fmt/validate/plan, apply делать через контролируемый pipeline после ревью. Инструменты типа Atlantis/Run-in-remote помогают безопасно автоматизировать apply.

• Secrets: не храните секреты в tfstate и переменных; интегрируйте secret-manager или Vault, используйте ссылки/данные, а не жёсткие значения.

• Малые изменения: делайте атомарные PR — проще ревью и легче откатить.

Подводные камни и ограничения

• State содержит реальные идентификаторы и иногда чувствительные данные — доступ к нему должно быть строго контролируемо.

• Drift: ручные изменения в консоли приводят к рассинхрону; регулярно делать terraform plan и устранять drifts.

• Provisioners и побочные скрипты: использовать осторожно — они ломают идемпотентность; лучше готовить образы (Packer) или конфигурировать через конфиг-менеджер.

• Сложность в больших-monorepo: требуется дисциплина модулей, remote state и orchestration (Terragrunt/Automation wrappers помогают).

Дополнительные возможности

• Data sources — получение данных от провайдеров для использования в конфиге.

• Lifecycle — управление порядком создания/удаления, предотвращение удаления (prevent_destroy).

• For_each / count / depends_on — выражения для динамического создания ресурсов.

• Integrations: Terraform легко вписывается в GitOps/CI, его можно сочетать с инструментами для policy-as-code, image baking и автоматического тестирования инфраструктуры.