Тестирование Terraform кода

Тестирование Terraform кода

Terraform настолько хорош и для него написано так много различных провайдеров, что он подходит не только для Infrastructure as a Code (IaC), но и также для управления конфигурацией. Например, с помощью провайдера для работы с Zabbix, можно почти полностью управлять сервисом мониторинга, а с помощью провайдера для Azure DevOps, можно перенести управление CI/CD-утилитой в код!

В итоге, конфигурации Terraform увеличиваются в размерах, используют множество разных трюков, что становится необходимым следить за файлами в режиме автоматизации, т.е. тестировать Terraform-код на ошибки и стиль.

Что имеем?

Вобщем, на данный момент я знаю два наиболее популярных метода для тестирования Terraform-кода:

  • terraform validate - нативный, родной подход, который проверяет написанную конфигурацию, НО БЕЗ ОБРАЩЕНИЯ в какие-либо другие системы.
  • tflint - сторонняя утилита, которая делает примерно то же, самое, что и первый пункт плюс:
    • проверка на ошибки при работе с облачными сервисами (например, действительно ли существует тот сайз виртуального сервера, который вы собираете создать)
    • проверка на лишние переменные
    • проверка на соблюдение какого-то бест-практис

Несмотря на то, что вроде как, по описанию, tflint должен покрывать функционал terraform validate, иногда последний находит ошибки, которые не обнаружил первый.

Ниже я опишу, как этими доступными вариантами пользоваться и их особенности, известные мне.

Пользуемся terraform validate

Это команда родного исполняемого файла terraform, что подразумевает, что она поддерживает все текущие возможности языка HCL. Удобство ее также в том, что у вас нет необходимости устанавливать\обновлять никакие другие файлы - все уже есть в бинарнике terraform!

Вот основной функционал, предоставляемый командой terraform validate:

  1. Проверка синтаксиса: Команда проверяет файлы конфигурации на наличие синтаксических ошибок. Если в файлах обнаружены ошибки, команда вернет сообщения об ошибках с указанием строк и местонахождения проблемы.

  2. Проверка наличия обязательных аргументов: проверяет, что все обязательные аргументы для ресурсов и модулей заданы правильно. Это включает в себя проверку наличия и корректности указанных переменных и атрибутов.

  3. Проверка ссылок на ресурсы и модули: также убеждается, что все ссылки на ресурсы и модули в файлах конфигурации существуют и имеют правильные имена.

  4. Проверка использования переменных и выражений: Команда может проверить использование переменных и выражений в файлах конфигурации на предмет корректности их использования и соответствия ожидаемым типам данных.

  5. Проверка наличия провайдеров: проверяет, что все используемые провайдеры (например, AWS, Azure и др.) указаны и доступны.

  6. Предупреждения о совместимости версий провайдеров: В некоторых случаях команда может предупредить о совместимости версий провайдеров, чтобы предотвратить потенциальные проблемы при применении изменений.

  7. Проверка модулей: Если вы используете модули в своей конфигурации, команда terraform validate также проверит синтаксис и правильность использования модулей.

Прежде чем запускать terraform validate, необходимо скачать модули и провайдеры, которые используются в конфигурации. Это можно сделать с помощью terraform init. Далее просто запускаем там же terraform validate - и все, готово.

terraform validate

Минус у этого подхода очевиднен - команда не знает, какие значения допустимы для разных провайдеров, поэтому и не проверяет эти значения.

Пользуемся tflint

Утилита tflint имеет похожий функционал, но кроме проверки кода, поиска ошибок в синтаксисе, она умеет делать следующие вещи:

  1. Проверка синтаксиса и стиля: выполняет проверку на синтаксические ошибки в файлах конфигурации Terraform. Он также предупреждает о нарушениях стиля кодирования согласно рекомендациям и стандартам Terraform.

  2. Проверка лучших практик: включает в себя набор правил, которые помогают выявить потенциальные проблемы и нарушения лучших практик при написании кода инфраструктуры. Это может включать в себя некорректное использование ресурсов, переменных окружения, оформление и т. д.

  3. Поддержка кастомных правил: Вы можете определить собственные правила для анализа кода, чтобы соответствовать особенностям вашего проекта или организации.

  4. Поддержка различных провайдеров: поддерживает проверку кода для различных провайдеров Terraform, что позволяет вам анализировать конфигурации для разных облачных платформ.

  5. Отчеты и форматирование: может выводить результаты анализа в различных форматах, таких как текстовый вывод, JSON или Checkstyle XML, что упрощает интеграцию с различными инструментами и системами управления ошибками.

Чтобы запустить команду, надо сделать следующие шаги:

  • Во-первых, конечно, скачать бинарник и добавить путь к нему в переменную PATH.
  • Далее создать файл конфигурации .tflint.hcl в той же папке, что и terraform-код. Вот пример, который я использую в своей работе:
config {
  format = "default"
  module = true
}

plugin "terraform" {
  enabled = true
  preset  = "recommended"
}

# ====================================================

plugin "azurerm" {
    enabled = true
    version = "0.24.0"
    source  = "github.com/terraform-linters/tflint-ruleset-azurerm"
}

Обратите внимание на строку 13 - можно подключать различные плагины, по необходимости. Разработчики предоставляет вот такие плагины:

Потом, как обычно, terraform init и, наконец, две команды по очереди:

  • tflint --init, чтобы скачать плагины
  • tflint, чтобы запустить тесты

tflint

У вас может быть ситуация (как у меня), что некоторые переменные в модулях или конфигурации я использую не всегда. А правило terraform_unused_declarations выдает ошибку и блокирует скрипты автоматизации. Для таких случаев у tflint есть специальный синтаксис для исключения какого-либо правила для строки:

# tflint-ignore: terraform_unused_declarations
variable "dev_be_storage_account_name" { type = string }

Заключение

Пожалуй, это все. Надеюсь, это будет полезным для вас.

Тестирование Terraform кода является важной практикой из-за нескольких причин:

  1. Уверенность в изменениях: При разработке вы вносите изменения в код для добавления новых ресурсов, изменения параметров и т.д. Тестирование позволяет убедиться, что каждое изменение не нарушает существующую инфраструктуру и взаимодействие между компонентами.

  2. Отслеживание зависимостей: Terraform ресурсы могут иметь много зависимостей. Тестирование помогает убедиться, что изменения в одной части кода не нарушают работу других частей инфраструктуры.

  3. Автоматизация и скорость: Автоматизированные тесты могут быстро и надежно проверять код на наличие ошибок. Это позволяет быстро выявлять и исправлять проблемы, экономя время, и обеспечивает стабильность процесса развертывания.

Terraform (ru)

  • Просмотров: 711
Добавить комментарий

Related Articles