Terraform на AWS: провайдеры, state и remote backend

Провайдеры: HCL поверх API любого облака

С CloudFormation и CDK ты познакомился в предыдущем уроке — это AWS-нативные инструменты, где AWS парсит твой шаблон и отслеживает стек за тебя. Terraform от HashiCorp делает другую ставку: один инструмент, один язык (HCL, HashiCorp Configuration Language) на все облака. Мост к каждой платформе — провайдер, плагин, который маппит HCL-блоки ресурсов на вызовы API конкретного вендора. Провайдер aws превращает блок aws_instance в вызовы EC2 RunInstances; провайдер cloudflare или google делает то же для своих API. Один конфиг может объявлять ресурсы сразу через несколько провайдеров — в этом весь смысл: мульти-облачное или мульти-вендорное хозяйство, описанное одним языком и одним workflow.

Ты объявляешь провайдер и ресурс, и это и есть единица работы. Блок ниже фиксирует версию AWS-провайдера, задаёт регион и просит бакет:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

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

resource "aws_s3_bucket" "assets" {
  bucket = "acme-prod-assets"
  tags   = { Team = "platform" }
}

Ограничение версии ~> 5.0 значит больше, чем кажется: провайдеры выкатывают ломающие изменения, и незафиксированный провайдер может переписать половину твоего plan после несвязанного апгрейда. Фиксируй его так же, как фиксируешь transform в CloudFormation.

State: то, что CloudFormation прячет, а Terraform отдаёт тебе

Вот определяющее различие уровня senior. Когда ты делаешь apply, Terraform пишет state-файл, который записывает связки между объектами в реальном облаке и инстансами ресурсов в твоём конфиге — фактические ID ресурсов, атрибуты и метаданные зависимостей. На следующем запуске Terraform читает этот state, обновляет (refresh) его против живого API, чтобы обнаружить drift (реальный мир расходится с тем, во что верит state), вычисляет разницу с твоим конфигом и планирует только дельту. State и есть память Terraform; без него инструмент не отличит «create» от «update».

У CloudFormation такая же память, но AWS держит её на своей стороне, и ты её не трогаешь. Terraform делает её файлом, за который ты отвечаешь, — и у этой ответственности острые края:

• Локальный state опасен для команд. terraform.tfstate на одном ноутбуке нельзя расшарить, он теряется, если ноутбук умрёт, и ничего не сериализует — двое не могут безопасно работать вместе.
• State может содержать секреты. Пароль RDS или сгенерированный ключ попадает в state открытым текстом. Коммит state в git его утекает; backend обязан шифровать его в покое.
• Никогда не правь state руками. Это производный индекс, а не исходник. Ручная правка рассинхронизирует его с реальностью; используй сабкоманды terraform state или terraform import, чтобы взять существующий ресурс под управление.

Все три правила сводятся к одному принципу: относись к state как к общей, зашифрованной, блокируемой базе данных — потому что именно этим он и является. Пропусти любое из них, и ты на один параллельный apply или на один git push от утечки учёток или потери ресурсов.

Remote backend и state locking

Фикс для всех опасностей state — remote backend. S3-backend хранит объект state в S3-бакете (bucket + key + region), чтобы вся команда читала и писала одну общую долговечную копию, и шифрует этот state в покое. Вторая половина — state locking: перед изменением state Terraform берёт lock, так что параллельный apply обязан ждать, а не гнаться. Исторически ты задавал таблицу DynamoDB (partition key с именем LockID) через dynamodb_table; этот путь ещё работает, но теперь deprecated в пользу S3-native locking — задай use_lockfile = true, и Terraform пишет объект tflock рядом со state для координации, без отдельной таблицы.

terraform {
  backend "s3" {
    bucket       = "acme-tf-state"
    key          = "prod/network/terraform.tfstate"
    region       = "eu-central-1"
    encrypt      = true
    use_lockfile = true
  }
}

С этим гонка из Hook невозможна: apply второго инженера блокируется на локе, пока первый не закончит и не отпустит его. Это та конфигурация, которую команда «чтобы было проще» пропустила.

Чтение plan и модули

terraform plan — это предохранитель, и чтение его — навык уровня senior. Он печатает diff с четырьмя действиями: + создать, - удалить, ~ обновить на месте и -/+ replace — удалить, затем создать заново. Последний символ — опасный. Поле, которое нельзя изменить на месте (переименование идентификатора БД, смена неизменяемого атрибута), вынуждает replace, а replace базы данных значит, что её уничтожают и создают свежую пустую. Plan говорит тебе об этом простым текстом — -/+ destroy and then create replacement — и инженер, который применяет, не прочитав, теряет данные. Всегда читай plan перед apply; это и есть вся причина, по которой plan — отдельная команда.

terraform init        # скачать провайдеры, настроить backend
terraform plan        # обновить state, показать diff create/update/replace/destroy
terraform apply       # взять lock, выполнить, записать state обратно

Последний строительный блок — модули, переиспользуемые параметризованные наборы ресурсов, подтягиваемые из публичного реестра или локального пути, чтобы ты написал VPC один раз и вызывал его по окружениям, а не копипастил HCL. Модули — то, как кодовая база Terraform остаётся DRY на масштабе.