OpenTofu 1.13 получит встроенный линтинг для проверки IaC-конфигураций
OpenTofu расширяет инструменты контроля Infrastructure as Code: в версии 1.13 проект планирует представить экспериментальную поддержку встроенного линтинга. Новая функция будет работать непосредственно в основном сценарии OpenTofu и поможет выявлять потенциальные ошибки и недочёты ещё до применения изменений в инфраструктуре.
OpenTofu развивается как свободная общественная альтернатива Terraform. В отличие от внешних анализаторов, встроенный механизм сможет использовать сведения, которые система получает во время выполнения команд `plan` и `apply`. На этом этапе OpenTofu вычисляет выражения и взаимодействует с провайдерами, поэтому некоторые проверки становятся возможными только после получения дополнительной информации о планируемых изменениях.
Экспериментальный режим появится в OpenTofu 1.13 и будет включаться новым параметром командной строки `-lint`. Опция будет доступна для команд `validate`, `plan` и `apply`. Например, чтобы активировать все доступные правила, можно выполнить:
```bash
tofu plan -lint=all
```
При необходимости пользователь сможет включить не весь набор, а только отдельные проверки. Для этого названия правил указываются через запятую. Такой подход позволит адаптировать анализ под конкретный проект, не перегружая вывод предупреждениями, которые не имеют практического значения для выбранной конфигурации.
Подробнее о возможностях нового механизма рассказывается в материале о встроенном линтинге OpenTofu 1.13. На первом этапе разработчики добавили четыре правила. Они охватывают типичные проблемы в переменных и локальных значениях конфигурации.
Правило `core:no-type-variable` сообщает о входных переменных, для которых не задан тип. Явное объявление типа делает конфигурацию более предсказуемой, упрощает сопровождение и помогает раньше обнаруживать ошибочные значения. Особенно важно это для командных проектов, где инфраструктурный код поддерживают несколько специалистов.
Проверка `core:count-instead-enabled` обращает внимание на ситуации, когда для условного включения ресурса используется устаревающий подход с `count`, хотя задачу можно решить с помощью более современной возможности `enabled`. Такое предупреждение не обязательно означает критическую ошибку, но указывает на возможность сделать код понятнее и привести его к актуальным практикам OpenTofu.
Оставшиеся два правила связаны с неиспользуемыми элементами. `core:unused-variable` находит объявленные входные переменные, которые нигде не применяются. Аналогичную задачу для локальных значений выполняет `core:unused-local`. Удаление таких фрагментов помогает уменьшить объём конфигурации, устранить путаницу и снизить риск ошибочного использования устаревших параметров.
Пока функция имеет экспериментальный статус, поэтому её поведение и набор проверок могут измениться до финального выпуска. Перед включением линтинга в рабочих контурах организациям стоит протестировать его на копии конфигураций и оценить, насколько новые предупреждения соответствуют внутренним правилам разработки.
Потенциал проекта значительно шире четырёх стартовых проверок. Разработчики рассматривают возможность создавать пользовательские правила и политики на языке, близком к синтаксису конфигураций OpenTofu. Это позволит компаниям формализовать собственные требования: стандарты именования, обязательные параметры безопасности, ограничения на типы ресурсов и правила работы с окружениями.
Отдельное направление связано с интеграцией проверок в плагины провайдеров. Благодаря этому правила смогут получать дополнительные сведения о ресурсах и анализировать сценарии, которые невозможно корректно оценить только по исходному тексту конфигурации. Например, провайдер потенциально сможет проверять параметры конкретного облачного сервиса или предупреждать о небезопасных настройках.
Также обсуждается разделение правил на блокирующие и неблокирующие. В первом случае нарушение будет останавливать выполнение операции, а во втором OpenTofu ограничится предупреждением. Такой механизм пригодится для постепенного внедрения политик: сначала команда сможет собирать статистику по нарушениям, а затем сделать наиболее важные требования обязательными.
Ещё одной перспективной возможностью станут переиспользуемые наборы правил, распространяемые по аналогии с модулями OpenTofu. Команды смогут подготовить единый ruleset для разных проектов, а затем применять его в CI/CD, тестовых средах и рабочих пайплайнах. Это упростит унификацию инфраструктурного кода в крупных организациях.
Тем, кто только начинает работать с технологией, пригодится OpenTofu обучение с практикой написания модулей, переменных и политик. Для действующих проектов востребованы OpenTofu консультация и OpenTofu внедрение, особенно если инфраструктура уже использует Terraform-совместимые конфигурации и требует аккуратной миграции. Перед переходом также может понадобиться OpenTofu аудит инфраструктуры: он помогает выявить неиспользуемые ресурсы, слабые места в структуре кода и потенциальные проблемы совместимости.
После выхода стабильной версии пользователи смогут OpenTofu 1.13 скачать из официальных каналов проекта и проверить линтинг на собственных конфигурациях. Однако для production-среды разумнее дождаться подтверждения стабильности функции и заранее встроить проверки в процесс ревью и автоматического тестирования. В таком случае встроенный линтер станет не просто дополнительной командой, а частью единой системы контроля качества инфраструктурного кода.
