terraform-engineer - Модули и состояние Terraform

Когда звать

• Когда Terraform-код нужно разделить на модули с проверяемыми входами и выходами.
• Когда меняются backend состояния, версии провайдеров или ресурсы нескольких окружений.

Что предлагает Terraform Engineer

Terraform Engineer описывает инфраструктуру как код для AWS, Azure и GCP. Основные направления - повторно используемые модули, состояние, провайдеры и тестирование изменений. Версия проверенного SKILL.md - 1.1.0.

Скилл нужен, например, когда один каталог Terraform обслуживает несколько окружений и в нём перемешаны локальные значения, версии провайдеров и общие ресурсы. Автор предлагает сначала изучить действующий код и требования, затем определить интерфейсы модулей. Начинать с автоматического применения нового шаблона инструкция не предлагает.

Модули, backend и ограничения версий

В примере модуль разделён на main.tf, variables.tf и outputs.tf. Входные значения получают тип, описание и блок validation. Выходы показывают, какую информацию модуль возвращает вызывающему коду. Это позволяет обсуждать договорённость между модулями до создания облачных ресурсов.

Для состояния автор требует удалённый backend с блокировкой и шифрованием. Локальное состояние для рабочего окружения и отсутствие блокировки прямо запрещены. Вариант backend из примера нужно сопоставить с версией Terraform и правилами вашего проекта, а не переносить как универсальный рецепт.

Провайдеры должны иметь ограничения версий; смешивать произвольные версии нельзя. Инструкция также требует последовательные имена, теги ресурсов и документацию интерфейсов. Каталог .terraform не должен попадать в репозиторий.

План отделён от применения

После написания кода идут форматирование, terraform validate и tflint. Ошибки нужно исправить и повторить проверки. Следующий этап создаёт сохранённый план и краткое описание создаваемых, изменяемых и удаляемых ресурсов.

Пересоздание и удаление автор выделяет отдельно. Перед применением агент обязан показать итог плана и получить явное подтверждение. Если пользователь не принял разрушительные изменения, инструкция запрещает выполнять применение. Даже успешная проверка синтаксиса не заменяет этот разбор.

Раздел восстановления после ошибок рассматривает расхождение состояния с реальными ресурсами, сбой авторизации и зависимости модулей. Упомянутые там операции со state могут менять учёт ресурсов. Их наличие в тексте не делает их безопасным первым действием; причину расхождения нужно установить до исправления.

Как поставить первую задачу

Для начала можно попросить: «Разберите интерфейс одного существующего модуля. Добавьте недостающую валидацию входов, объясните ограничения провайдера и подготовьте план проверки без применения». Если облачный доступ не выдан, агент должен отделить локальную проверку от сетевой части.

Ожидаемый результат по исходнику - структура модуля, backend, конфигурация провайдера, пример tfvars и объяснение решений. Для реального изменения нужны фактический план и перечень последствий, а не только список новых .tf файлов.

Проверка карточки охватывает основной документ и MIT-лицензию на одном коммите. Установка, init, plan и apply нами не выполнялись; работа в Codex не проверена. Связь с общей доставкой приложения описывает DevOps Engineer.