Bootstrapping (chicken-and-egg)
Тема дорожной карты · Terraform
Паттерн Bootstrap в Terraform решает проблему курицы и яйца в IaC: прежде чем terraform init сможет хранить состояние в S3-бакете с DynamoDB-блокировкой, эти AWS-ресурсы сами должны существовать — а для их создания обычно нужен Terraform. Паттерн Bootstrap решает это с помощью минимальной, отдельно управляемой «bootstrap»-конфигурации (часто небольшой shell-скрипт или выделенный корневой модуль Terraform с локальным состоянием), которая создаёт только ресурсы remote-state бэкенда — S3-бакет, DynamoDB-таблицу, KMS-ключ и IAM-роли — один раз при первоначальной настройке аккаунта. После выполнения bootstrap-конфигурации все последующие модули Terraform настраивают свои блоки backend "s3" на использование созданного бакета, обеспечивая полный remote-state, блокировку состояния и шифрование для всех конфигураций рабочих нагрузок в окружениях AWS, Azure, GCP и Kubernetes. Паттерн Bootstrap, как правило, автоматизируется как одноразовый шаг в конвейерах вендинга аккаунтов (AWS Control Tower, Landing Zone Accelerator) и защищается строгими IAM-политиками и политиками S3-бакета, предотвращающими случайный terraform destroy инфраструктуры состояния. Документирование и версионирование конфигурации паттерна Bootstrap Terraform вместе с кодовой базой IaC организации гарантирует, что сценарии аварийного восстановления — пересоздание региона или аккаунта с нуля — имеют задокументированную, воспроизводимую отправную точку.
Как это работает
Bootstrapping (chicken-and-egg) покрывает for_each с map для стабильной идентичности, dynamic-блоки для повторяющегося nested-конфига, lifecycle { create_before_destroy = true / prevent_destroy / ignore_changes }, depends_on для явного порядка, terraform_data (замена null_resource), replace_triggered_by. Главный паттерн power-user — композиция модулей: маленькие сфокусированные модули + тонкий root-конфиг, их связывающий. Не злоупотребляйте meta-аргументами — они стоят читаемости.
Когда применять
create_before_destroy — для ресурсов, которые не можете позволить себе быть down (load balancer, DNS-записи). prevent_destroy — на БД (terraform destroy не должен случайно удалить prod-данные — сделайте шумно). ignore_changes — только для полей, управляемых вне Terraform (auto-scaling desired_capacity — классика). Для сложных flow — генерируйте Terraform через CDK for Terraform (CDKTF) вместо хака HCL.
Типичные ошибки
Ловушки Bootstrapping (chicken-and-egg): lifecycle-блоки прячут реальный drift (не видите изменение, потому что игнорите); циклический depends_on; злоупотребление null_resource для "выполнить скрипт" (реальные provisioner — осторожно, или вынесите логику вне Terraform); глубоко вложенные dynamic-блоки, нечитаемые через 3 месяца.