Terraform и другие инструменты IaC давно стали стандартом, но рутина остаётся: писать модули, разбирать план перед apply, ловить дрейф, ревьюить состояние. LLM уже умеет снимать часть этой нагрузки — если давать ей правильные промты и проверять результат. В этой подборке — проверенные запросы, которые превращают языковую модель в помощника инфраструктурного инженера. Для каждого промта: пример входа, что ожидать на выходе, где LLM ошибается и как это отловить через terraform validate и plan.
1. Генерация переиспользуемого модуля с variables и outputs
Промт:
Ты — инженер по инфраструктуре. Сгенерируй переиспользуемый Terraform-модуль для [ресурс, например, AWS S3 bucket с версионированием и шифрованием]. Требования:
- Все настраиваемые параметры вынеси в variables с типами, описаниями и default (где безопасно).
- Обязательно добавь outputs для ключевых атрибутов (id, arn).
- Используй последнюю стабильную версию провайдера (укажи в required_providers).
- Внутри модуля не должно быть хардкода имён — только через переменные.
- Приведи пример вызова модуля из корневого конфига.
Пример входа: ресурс — AWS S3 bucket с версионированием, шифрованием и блокировкой публичного доступа.
Что ожидать: модель выдаст main.tf, variables.tf, outputs.tf и пример вызова. Проверьте, что версия провайдера актуальна (LLM может предложить устаревшую), а аргументы соответствуют документации. Например, для S3 bucket в AWS провайдере версии 5.x блок server_side_encryption_configuration имеет определённую структуру — модель может перепутать вложенность.
Где ошибается: выдумывает несуществующие аргументы (например, bucket_key_enabled внутри rule без указания алгоритма) или использует устаревший синтаксис. Всегда прогоняйте terraform validate и terraform plan в тестовом окружении.
2. Чтение и объяснение terraform plan перед apply
Промт:
Проанализируй вывод terraform plan (json или текстовый). Объясни, какие изменения будут применены, какие ресурсы будут созданы, изменены или удалены. Особое внимание удели ресурсам, которые будут уничтожены (destroy) или заменены (replace). Для каждого изменения укажи, какие атрибуты меняются и почему это может быть опасно. Предложи, как избежать разрушительных действий, если они нежелательны.
Пример входа: текстовый вывод terraform plan с изменениями в AWS EC2 (изменение типа инстанса с t3.micro на t3.small) и RDS (изменение параметра backup_retention_period).
Что ожидать: модель разберёт план, выделит, что изменение типа EC2 может потребовать замены (если не включён stop перед изменением), а для RDS — параметр применяется без простоя. Также предупредит о возможных простоях.
Где ошибается: может неверно интерпретировать флаг forces replacement или пропустить зависимые ресурсы. Всегда сверяйтесь с официальной документацией по конкретному ресурсу.
3. Поиск дрейфа между стейтом и реальной инфраструктурой
Промт:
У меня есть вывод terraform plan, который показывает изменения, хотя я не менял конфигурацию. Помоги определить, какие ресурсы «уплыли» (drift). Проанализируй план и скажи, какие атрибуты были изменены вне Terraform, и как их можно вернуть в управляемое состояние. Предложи шаги: либо принять изменения (terraform apply), либо откатить (terraform apply -refresh-only и затем plan).
Пример входа: план показывает, что у AWS Security Group изменилось правило ingress (добавлен порт 8080), хотя в коде его нет.
Что ожидать: модель укажет, что кто-то вручную добавил правило, и предложит два пути: импортировать изменение в код (добавить правило в конфиг) или удалить его через apply. Также напомнит про terraform refresh для обновления стейта.
Где ошибается: может предложить terraform apply без предварительного plan после refresh, что рискованно. Всегда выполняйте terraform plan после любых манипуляций со стейтом.
4. Ревью state-файла и бэкенда
Промт:
Проверь конфигурацию Terraform backend (например, S3 + DynamoDB для блокировок). Убедись, что:
- Бэкенд настроен с шифрованием и блокировкой.
- Нет хардкода чувствительных данных.
- Версия Terraform и провайдеров зафиксирована.
Предложи улучшения по безопасности и надёжности.
Пример входа: фрагмент backend.tf с S3-бакетом без шифрования и без DynamoDB для блокировок.
Что ожидать: модель укажет на отсутствие encrypt = true, dynamodb_table и kms_key_id, предложит добавить. Также может посоветовать включить версионирование бакета для защиты от удаления стейта.
Где ошибается: может перепутать параметры бэкенда для разных облаков. Всегда сверяйтесь с документацией по вашему бэкенду.
encrypt = true и настроен dynamodb_table — без этого параллельные запуски могут повредить стейт.
5. Миграция с ручных ресурсов на модули
Промт:
У меня есть набор ресурсов, созданных вручную в Terraform (без модулей). Помоги преобразовать их в переиспользуемый модуль. Разбей на модули по логическим группам (сеть, вычисления, база данных). Для каждого модуля определи variables и outputs. Предложи структуру каталогов и пример вызова.
Пример входа: конфигурация с EC2, RDS, VPC, Security Group в одном файле.
Что ожидать: модель предложит разбить на модули network, compute, database, с соответствующими переменными (CIDR, тип инстанса, версия БД). Также покажет, как использовать module блоки с передачей параметров.
Где ошибается: может не учесть зависимости между модулями (например, Security Group должен ссылаться на VPC ID из модуля network). Проверьте, что outputs одного модуля используются как inputs другого.
6. Безопасная настройка remote state и блокировок
Промт:
Настрой remote state для Terraform с использованием [облако, например, AWS S3 + DynamoDB]. Обеспечь:
- Шифрование состояния (SSE).
- Блокировку через DynamoDB.
- Версионирование бакета для отката.
- Ограничение доступа (IAM политика).
Напиши необходимые Terraform-ресурсы для создания бакета и таблицы, а также конфигурацию backend.
Пример входа: AWS, требуется remote state с блокировкой.
Что ожидать: модель создаст S3 bucket с server_side_encryption_configuration, включит версионирование, создаст DynamoDB таблицу с LockID, напишет политику IAM. Также предоставит блок backend "s3" с параметрами.
Где ошибается: может забыть про dynamodb_table в backend или указать неверное имя атрибута. Проверьте, что в таблице DynamoDB первичный ключ — LockID (строка).
7. Генерация политик безопасности (Security Groups, IAM)
Промт:
Сгенерируй Terraform-код для AWS Security Group, который разрешает входящий трафик только с определённых IP-адресов и портов. Параметры (CIDR, порты) вынеси в variables. Добавь описание правил. Убедись, что нет правила allow all.
Пример входа: нужно разрешить SSH (22) с офисного IP 203.0.113.0/24 и HTTP (80) со всего мира.
Что ожидать: модель создаст aws_security_group с ingress-правилами, где для SSH указан конкретный CIDR, а для HTTP — 0.0.0.0/0. Также добавит egress по умолчанию.
Где ошибается: может использовать устаревший синтаксис с отдельными ресурсами aws_security_group_rule вместо встроенных блоков ingress. В новых версиях провайдера рекомендуется использовать aws_vpc_security_group_ingress_rule. Уточните у модели актуальный подход.
8. Валидация и тестирование модулей
Промт:
Напиши для Terraform-модуля тесты с использованием Terratest (Go) или встроенного terraform test (если версия >=1.6). Проверь, что модуль создаёт ресурсы с ожидаемыми атрибутами. Добавь примеры тестов для валидации входных переменных.
Пример входа: модуль S3 bucket.
Что ожидать: модель сгенерирует файл main_test.go с использованием Terratest, где будет создаваться бакет, проверяться его существование и атрибуты (версионирование, шифрование). Либо напишет .tftest.hcl для terraform test.
Где ошибается: может использовать устаревшие функции Terratest или не учесть зависимости. Проверьте, что тесты запускаются в изолированном окружении и не конфликтуют с реальными ресурсами.
terraform test встроен в Terraform начиная с версии 1.6 и не требует Go. Terratest мощнее, но требует написания кода на Go. LLM может предложить Terratest по умолчанию — уточните, какой подход вам ближе.
9. Автоматическое исправление ошибок в плане
Промт:
После запуска terraform plan я получил ошибку: [текст ошибки]. Проанализируй причину и предложи исправление в конфигурации. Учти, что ошибка может быть связана с версией провайдера или синтаксисом. Дай конкретные шаги и исправленный фрагмент кода.
Пример входа: ошибка Error: Unsupported argument для аргумента bucket_key_enabled в ресурсе aws_s3_bucket_server_side_encryption_configuration.
Что ожидать: модель объяснит, что аргумент должен находиться внутри блока rule и применяться к apply_server_side_encryption_by_default, а также что для использования bucket_key_enabled нужен KMS-ключ. Предложит исправленный код.
Где ошибается: может предложить неверный путь к аргументу. Всегда проверяйте документацию провайдера.
10. Генерация README для модуля
Промт:
Сгенерируй README.md для Terraform-модуля [название]. Опиши назначение, входные переменные (с типами и default), выходные значения, пример использования. Добавь раздел с требованиями к версии Terraform и провайдеров.
Пример входа: модуль для AWS RDS с параметрами.
Что ожидать: модель создаст структурированный README с таблицами переменных и outputs, примером вызова. Убедитесь, что описание соответствует реальному коду — LLM может придумать несуществующие переменные.
Где ошибается: может включить в README переменные, которых нет в коде, или наоборот. Проверьте соответствие с variables.tf и outputs.tf.
11. Аудит безопасности Terraform-кода
Промт:
Проведи аудит безопасности Terraform-конфигурации. Найди потенциальные уязвимости: открытые security groups, отсутствие шифрования, избыточные IAM-права, хардкод секретов. Предложи исправления с примерами кода.
Пример входа: конфигурация с S3 bucket без шифрования и с публичным доступом.
Что ожидать: модель укажет на отсутствие server_side_encryption_configuration, наличие acl = "public-read", предложит добавить блокировку публичного доступа и шифрование. Также может порекомендовать использовать aws_s3_bucket_public_access_block.
Где ошибается: может пропустить неочевидные проблемы, например, отсутствие логирования. Дополнительно используйте инструменты вроде tfsec или checkov.
12. Оптимизация затрат через анализ плана
Промт:
Проанализируй terraform plan и предложи, как снизить затраты на инфраструктуру. Обрати внимание на неиспользуемые ресурсы, избыточные мощности, устаревшие типы инстансов. Дай рекомендации по изменению конфигурации.
Пример входа: план с EC2 типа m5.2xlarge, который простаивает (низкая нагрузка).
Что ожидать: модель предложит уменьшить тип до m5.large или использовать auto-scaling, также может указать на неиспользуемые EBS volumes.
Где ошибается: может не учесть требования к производительности. Всегда проверяйте рекомендации с мониторингом.
Где LLM экономит время, а где apply всё равно руками
LLM отлично справляется с генерацией шаблонного кода, объяснением плана и поиском дрейфа. Но окончательное решение о применении изменений всегда за инженером. Модель может пропустить тонкие зависимости, неверно интерпретировать версии провайдеров или предложить небезопасное действие. Поэтому цепочка «промт → генерация → terraform validate → terraform plan → ручное ревью → apply» остаётся золотым стандартом.
Используйте эти промты как ускоритель, но не как замену критическому мышлению. Инфраструктура не прощает ошибок, и ответственность за apply лежит на вас.
Для смежных тем по автоматизации и работе с LLM загляните в статьи AI-автоматизация и агенты: как не утонуть в хайпе и Промты для Go-микросервисов.