Terraform и IaC: управление инфраструктурой как кодом на AWS, GCP и Azure

Представьте, что вы можете развернуть целый продакшен-кластер из десятков серверов, балансировщиков и баз данных одной командой. Без консоли, без ручного кликанья, без риска человеческой ошибки. Именно это даёт инфраструктура как код (IaC), и Terraform — главный инструмент в этой экосистеме. В 2026 году, когда облачные среды стали стандартом де-факто, умение управлять ресурсами через код — не прихоть, а необходимость для любого DevOps-инженера.

Что такое Terraform и почему он стал стандартом IaC?

Terraform от HashiCorp — это open-source инструмент для декларативного описания инфраструктуры. В отличие от Ansible или Puppet, которые фокусируются на конфигурации уже запущенных серверов, Terraform управляет жизненным циклом самих ресурсов: создаёт, изменяет и удаляет их. Его главная «фишка» — провайдеры. Это плагины, которые позволяют взаимодействовать с API любого облака: AWS, Microsoft Azure, Google Cloud Platform, а также с локальными решениями вроде VMware или OpenStack.

Ключевая идея Terraform — декларативность. Вы пишете, какой должна быть инфраструктура (целевое состояние), а Terraform сам вычисляет, какие шаги нужны для перехода из текущего состояния в желаемое. Это кардинально отличается от императивного подхода, где вы описываете последовательность действий.

Terraform State: сердце управления инфраструктурой

Когда вы запускаете terraform apply, инструмент создаёт файл state (состояние). Это JSON-файл, который содержит маппинг между вашим кодом и реальными ресурсами в облаке. State — это «источник правды» (source of truth). Без него Terraform не знает, что уже создано, а что нужно удалить.

Почему state нужно хранить удалённо?

Если state хранится локально (на вашем ноутбуке), вы рискуете:
- Потерять его при поломке диска.
- Создать конфликт версий, если над инфраструктурой работает команда.
- Случайно удалить важный ресурс, запустив terraform destroy на старой версии state.

Рекомендуется использовать удалённые бэкенды: S3 (AWS) с DynamoDB для блокировок, GCS (GCP) или Azure Storage. Это обеспечивает централизованное хранение, версионирование и безопасность.

Провайдеры: AWS, GCP, Azure — как выбрать и настроить?

Terraform поддерживает сотни провайдеров. Для облачных гигантов настройка тривиальна:

Провайдер	Файл конфигурации	Аутентификация
AWS	`provider "aws" { region = "us-east-1" }`	Переменные окружения `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY` или IAM-роль
GCP	`provider "google" { project = "my-project" }`	Файл сервисного аккаунта `.json` или `GOOGLE_APPLICATION_CREDENTIALS`
Azure	`provider "azurerm" { features {} }`	Azure CLI или Service Principal

Пример мультиоблачной конфигурации:

provider "aws" {
  region = "eu-west-1"
}

provider "google" {
  project = "my-gcp-project"
  region  = "europe-west1"
}

resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
}

resource "google_compute_instance" "web" {
  name         = "web-server"
  machine_type = "e2-micro"
  zone         = "europe-west1-b"
}

Модули: переиспользование и масштабирование

Писать всю инфраструктуру в одном файле main.tf — плохая практика для продакшена. Модули позволяют группировать ресурсы в логические блоки и переиспользовать их. Например, модуль vpc может создавать виртуальную сеть, подсети и шлюзы, а модуль eks — кластер Kubernetes.

Пример структуры проекта:

infrastructure/
├── modules/
│   ├── vpc/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   └── outputs.tf
│   └── ec2/
│       ├── main.tf
│       └── variables.tf
├── environments/
│   ├── dev/
│   │   ├── main.tf
│   │   └── terraform.tfvars
│   └── prod/
│       ├── main.tf
│       └── terraform.tfvars
└── global/
    └── s3-backend.tf

Модули можно публиковать в Terraform Registry — это каталог готовых решений для популярных сервисов (балансировщики, базы данных, мониторинг).

Рабочий процесс: от разработки до продакшена

Профессиональный пайплайн с Terraform включает несколько этапов:

Локальная разработка — пишете код в IDE, запускаете terraform plan для просмотра изменений.
Code Review — пул-реквест в Git (GitHub/GitLab). На CI-этапе запускается terraform fmt (форматирование) и terraform validate (проверка синтаксиса).
Планирование — terraform plan генерирует отчёт о том, что изменится. Результат можно прикрепить к PR как комментарий.
Применение — после ревью и мержа запускается terraform apply в целевой среде (dev/staging/prod).
Проверка — мониторинг состояния ресурсов через terraform show или дашборды облака.

Для продакшена обязательно используйте terraform workspace или отдельные директории для сред, чтобы случайно не сломать рабочую инфраструктуру.

Типичные ошибки и как их избежать

Жёсткая привязка к state — никогда не редактируйте state вручную. Используйте terraform import для существующих ресурсов.
Забытые переменные — всегда задавайте значения через .tfvars или переменные окружения, а не хардкодьте в main.tf.
Отсутствие блокировок — если два человека одновременно запустят apply, state может повредиться. Используйте бэкенды с поддержкой блокировок (DynamoDB, Consul).
Игнорирование зависимостей — Terraform автоматически строит граф зависимостей, но если ресурсы связаны неявно (например, через имя), используйте depends_on.

Заключение

Terraform — это не просто инструмент, а философия инфраструктуры как кода. Он превращает хаотичное управление облачными ресурсами в предсказуемый, версионируемый и автоматизированный процесс. Освоив провайдеры, state и модули, вы сможете управлять инфраструктурой любого масштаба — от одного сервера до мультиоблачного кластера с сотнями компонентов.

Начните с малого: опишите одну виртуальную машину в AWS, а затем усложняйте конфигурацию. Помните: код, который работает локально, должен работать и в продакшене. Terraform — ваш ключ к этому порядку. Готовы попробовать?

Terraform и IaC: управление инфраструктурой как кодом на AWS, GCP и Azure