Введение
Terraform — стандарт де-факто для управления инфраструктурой как кодом (IaC). Но даже опытные инженеры тратят часы на написание однотипных конфигураций, отладку state-файлов и проектирование мультиоблачных решений. AI-ассистенты (ChatGPT, Claude, Gemini) могут сократить это время на 40–60%, если правильно формулировать запросы.
В этой подборке — 14 готовых к копированию промтов для Terraform. Каждый решает конкретную задачу: от создания модулей до работы с remote state и multi-cloud. Вставьте промт в AI, подставьте свои параметры — и получите рабочий код или архитектурную рекомендацию.
1. Генерация базового модуля VPC
Задача: Быстро создать модуль для VPC с подсетями, шлюзами и таблицами маршрутизации.
Промт:
Создай модуль Terraform для VPC в AWS с именем "my-vpc".
Модуль должен:
- принимать переменные: vpc_cidr (default "10.0.0.0/16"), environment (default "dev"), public_subnet_cidrs (list), private_subnet_cidrs (list)
- создавать VPC, Internet Gateway, NAT Gateway, public и private подсети, таблицы маршрутизации
- выводить id VPC и списки id подсетей (публичных и приватных)
- использовать теги для окружения
Предоставь код для файлов: main.tf, variables.tf, outputs.tf
Пример использования:
После выполнения промта AI вернёт три файла. Вы копируете их в папку modules/vpc/ и вызываете модуль в root-конфигурации:
module "vpc" {
source = "./modules/vpc"
vpc_cidr = "10.1.0.0/16"
environment = "production"
public_subnet_cidrs = ["10.1.1.0/24", "10.1.2.0/24"]
private_subnet_cidrs = ["10.1.10.0/24", "10.1.20.0/24"]
}
Почему это работает: Модульная структура — золотой стандарт IaC. Промт явно указывает переменные, ресурсы и outputs, что исключает неоднозначность.
2. Сценарий миграции state из локального в S3
Задача: Перенести state-файл из локальной директории в удалённый бэкенд S3 с DynamoDB для блокировок.
Промт:
Напиши пошаговую инструкцию и Terraform-код для миграции state из локального backend в S3 backend.
Условия:
- bucket name: "my-terraform-state-bucket"
- dynamodb table: "terraform-locks"
- key: "prod/terraform.tfstate"
- region: eu-central-1
- текущий terraform.tfstate находится в корне проекта
Включи:
1. Создание S3 bucket и DynamoDB table (если ещё не созданы) через отдельный apply
2. Обновление backend.tf
3. Команду terraform init с флагом -migrate-state
4. Проверку, что state перенесён
Пример использования: AI выдаёт последовательность действий. Выполняете шаги — state оказывается в S3 с защитой от параллельных изменений.
3. Сравнение resource и data source для AWS S3 bucket
Задача: Понять разницу между resource (управление объектом) и data source (чтение существующего).
Промт:
Приведи два примера Terraform для AWS S3:
1. Создание нового bucket с resource "aws_s3_bucket" (включи versioning и encryption).
2. Получение данных о существующем bucket через data "aws_s3_bucket" (прочитай ARN и region).
Для каждого объясни:
- когда использовать
- какой эффект на apply/plan
- пример outputs
Пример ответа AI: resource создаёт ресурс и требует destroy при удалении; data source только читает, не изменяет инфраструктуру. Это критично для окружений, где bucket создан вне Terraform.
4. Шаблон for_each vs count для одинаковых ресурсов
Задача: Сгенерировать несколько IAM пользователей с разными ключами.
Промт:
Сравни использование count и for_each для создания трёх IAM users с именами ["alice", "bob", "carol"].
Покажи:
- код с count + element()
- код с for_each + each.value
- какой подход предпочтительнее, если после apply нужно удалить среднего пользователя
- влияние на state (порядковый номер vs ключ)
Практический совет: for_each надёжнее, так как элемент идентифицируется по ключу, а не индексу. Если удалить элемент из списка с count, все последующие ресурсы будут пересозданы.
5. Multi-cloud: создание VM в AWS и GCP в одном workspace
Задача: Развернуть однотипные инстансы в AWS (EC2) и GCP (Compute Engine) с cross-reference их IP.
Промт:
Создай Terraform-конфигурацию для multi-cloud:
- провайдеры: aws (us-east-1), google (us-central1)
- создай EC2 t3.micro с тегом "app=frontend"
- создай GCP e2-micro с тегом "app=frontend"
- выведи публичные IP обеих машин
- убедись, что между ними нет конфликта имён (используй count или for_each с облачной меткой)
Пример результата: После terraform apply в одном state-файле лежат ресурсы из двух облаков. Это основа для гибридных сценариев.
6. Динамические блоки для security group rules
Задача: Настроить правила security group из переменной-списка.
Промт:
Напиши Terraform код для AWS security group, который принимает список rules в переменной:
variable "ingress_rules" {
type = list(object({
from_port = number
to_port = number
protocol = string
cidr_blocks = list(string)
}))
}
Используй динамический блок dynamic "ingress" для создания правил.
Добавь пример вызова с тремя правилами: SSH (22), HTTP (80), HTTPS (443).
Зачем это нужно: Динамические блоки позволяют параметризовать сложные ресурсы без дублирования кода. Один модуль можно использовать для разных окружений.
7. Работа с Terraform Workspaces для окружений
Задача: Реализовать разные конфигурации для dev/staging/prod через workspaces.
Промт:
Объясни и покажи кодом, как использовать terraform.workspace для выбора разных значений переменных (instance_type, subnet_cidr, tags).
Пример:
- workspace "dev" -> t3.micro, CIDR 10.0.1.0/24
- workspace "staging" -> t3.small, CIDR 10.0.2.0/24
- workspace "prod" -> t3.large, CIDR 10.0.3.0/24
Используй lookup или condition.
Добавь: как создавать workspace, как переключаться, как применить.
Результат: Одна конфигурация, три окружения. State изолирован по workspace.
8. Pre-commit hook для форматирования Terraform
Задача: Автоматизировать проверку кода перед коммитом.
Промт:
Настрой pre-commit hooks для Terraform репозитория:
- terraform fmt (проверка форматирования)
- tflint (линтер)
- checkov (безопасность)
- terraform validate (синтаксис)
Предоставь содержимое файла .pre-commit-config.yaml и инструкцию по установке (pip install pre-commit).
Поясни, какой hook блокирует коммит, а какой только предупреждает.
Практика: После настройки каждый коммит будет прогонять код через основные проверки. Это снижает количество ошибок в CI/CD.
9. Terraform test framework (HCL-тесты)
Задача: Написать тест для проверки, что VPC создаётся с правильным CIDR.
Промт:
Используя Terraform Test Framework (v1.6+), напиши тест для модуля VPC.
Допустим модуль vpc создаёт ресурс aws_vpc.main с cidr_block = var.vpc_cidr.
Тест должен:
- создать экземпляр модуля с cidr "10.99.0.0/16"
- проверить, что vpc.cidr_block == "10.99.0.0/16"
- очистить ресурсы после теста (destroy)
Предоставь код файла tests/vpc_test.tftest.hcl и команду для запуска.
Зачем: Тесты позволяют проверить модули до развёртывания в реальном окружении. Это особенно важно для shared модулей.
10. Terraform moved блок для рефакторинга state
Задача: Переименовать ресурс без пересоздания.
Промт:
Покажи пример использования блока moved в Terraform 1.8+ для переименования ресурса.
Было:
resource "aws_s3_bucket" "old_name" { bucket = "my-bucket" }
Стало:
resource "aws_s3_bucket" "new_name" { bucket = “my-bucket” }
Напиши полную конфигурацию с moved, объясни, что произойдёт при plan и apply.
Дополнительно покажи, как перенести несколько ресурсов с помощью for_each.
Пример ответа: AI показывает блок moved: moved { from = aws_s3_bucket.old_name; to = aws_s3_bucket.new_name }. После apply state обновится без destroy/create.
11. Terraform Cloud API для запуска run
Задача: Автоматизировать запуск плана/применения из CI/CD.
Промт:
Напиши bash-скрипт, который использует Terraform Cloud API для создания run.
- принимает переменные: workspace_id, token, message
- создаёт run с типом "apply"
- ожидает завершения (проверяет статус каждые 5 секунд)
- выводит логи или ошибки
- не использует внешние зависимости, только curl и jq
Применение: CI/CD-пайплайн может вызвать этот скрипт для безопасного удалённого применения инфраструктуры.
12. Интеграция с Vault для динамических секретов
Задача: Получить временный токен для AWS из HashiCorp Vault и использовать его в Terraform.
Промт:
Покажи, как настроить Terraform провайдер для Vault и получить динамический AWS IAM-токен.
Шаги:
1. Сконфигурировать провайдер vault с адресом и токеном (переменные VAULT_ADDR, VAULT_TOKEN)
2. Через data "vault_aws_access_credentials" получить временный ключ
3. Использовать этот ключ в провайдере aws (передай в alias)
4. Создать S3 bucket с этим временным токеном
Предоставь полный код с пояснениями.
Безопасность: Временные токены живут час, что снижает риск утечки долгосрочных ключей.
13. Sentinel policy для запрета публичных S3 bucket
Задача: Написать политику, блокирующую создание S3 bucket с публичным доступом.
Промт:
Напиши Sentinel policy (HCL-формат) для Terraform Cloud, которая:
- проверяет все ресурсы типа aws_s3_bucket_public_access_block
- запрещает, если block_public_acls = false или block_public_policy = false
- выводит сообщение: "S3 bucket must have public access blocked"
- разрешает override тегом "allow_public"
Предоставь код политики и пример настройки в проекте (sentinel.hcl).
Цель: Enforce security best practices на уровне организации.
14. Локальный провайдер и mocked ресурсы для тестов
Задача: Сэмулировать ресурсы без настоящего облака.
Промт:
Объясни, как использовать локальный HashiCorp провайдер (terraform.io/builtin/local) или mock-провайдер (hashicorp/null) для тестирования модулей.
Покажи пример, где модуль создаёт null_resource с триггером, а затем проверяет его через output.
Также опиши, какой провайдер лучше использовать для unit-тестов без реальных API.
Когда нужно: При разработке модулей без доступа к облаку, или в CI/CD, где не хочется тратить ресурсы.
Заключение
Эти 14 промтов покрывают ключевые сценарии работы с Terraform: от написания модулей до сложной multi-cloud архитектуры. Используя AI-ассистентов с такими запросами, вы сокращаете время на рутину и сосредотачиваетесь на архитектуре. Сохраните подборку в закладки — она сэкономит часы гуглинга.
Хотите больше? Загляните в блог Asibiont — там разбираем реальные кейсы IaC и автоматизации. А если нужна помощь с инфраструктурой — пишите, поможем настроить Terraform под ваш проект.
Комментарии