terraform-style-guide

terraform-style-guide — официальный навык HashiCorp для генерации и ревью Terraform HCL по соглашениям Terraform. Его назначение — сделать конфигурацию предсказуемой для чтения, изменения и проверки: навык задаёт порядок работы с provider configuration, data sources, зависимыми resources и outputs, а изменяемые значения предлагает выносить в variables. Это не генератор конкретной инфраструктуры и не каталог готовых модулей: он задаёт правила оформления и последовательность подготовки конфигурации, тогда как состав ресурсов, облачный провайдер и архитектура остаются предметом задачи пользователя. В рекомендованной структуре отдельные файлы получают понятные роли: terraform.tf хранит требования к версии Terraform и провайдерам, providers.tf — настройки провайдеров, main.tf — основные data sources и resources, variables.tf — входные параметры, outputs.tf — выдаваемые атрибуты, locals.tf — локальные значения. Такой расклад полезен для нового модуля и для ревью существующего проекта, потому что позволяет быстро найти ограничения версий, входы, локальные вычисления и публичные результаты. Для небольшой конфигурации это всё равно ориентир, а не обязательный запрет на иной расклад файлов. Стиль кода строится на двух пробелах для каждого уровня вложенности, выравнивании знаков равенства у соседних аргументов и последовательности внутри блока: сначала meta-arguments, затем обычные аргументы, потом вложенные блоки, а lifecycle — в конце. Имена должны быть в нижнем регистре с подчёркиваниями, описывать сущность, использовать единственное число и не дублировать тип ресурса. Для единственного очевидного ресурса допускается имя main. Эти правила уменьшают визуальный шум и помогают сравнивать похожие блоки, но не меняют поведение провайдера. Для variables навык требует type и description; значения, которые должны быть настраиваемыми, не следует зашивать в resource. Для outputs требуется description. Для нескольких однотипных ресурсов предпочтителен for_each с именованным набором, а count оставляется для условного создания, например включения мониторинга. Секретные переменные должны иметь sensitive = true, а пароли и ключи нельзя помещать в открытый код или Terraform state без осознанной защиты. В требованиях версий используется явное ограничение; пример допускает актуальную major-версию провайдера и minor-версию Terraform, но lock-файл и ограничения модулей имеют приоритет. Операционная граница навыка особенно важна: он рекомендует не коммитить terraform.tfstate, резервную копию state, каталог .terraform, планы, а также tfvars с чувствительными значениями; конфигурации .tf и .terraform.lock.hcl, напротив, должны оставаться под версионным контролем. Перед коммитом предлагаются terraform fmt -recursive и terraform validate, а для дополнительных проверок названы tflint, checkov и tfsec. Эти команды проверяют формат, синтаксис и часть практик, но не доказывают, что выбранная инфраструктура безопасна или соответствует бизнес-требованиям. После генерации всё равно нужны планирование, ревью provider-specific ограничений и отдельная проверка секретов. Навык полезен при создании Terraform-модуля, нормализации существующих HCL-файлов и подготовке конфигурации к командному ревью. Он не обещает применить изменения, выбрать облачную архитектуру, заменить terraform plan или исправить несовместимость конкретного провайдера. Если lock-файл, модуль или политика проекта требуют другой версии, структуры или порядка, эти ограничения должны быть проверены отдельно; стиль HashiCorp остаётся проверяемым ориентиром, а не разрешением игнорировать фактический runtime и правила репозитория.