Реализация тестов интеграции для проектов Terraform в Azure

2025-01-15

Terraform включает определение, предварительную версию и развертывание облачной инфраструктуры. С помощью Terraform вы создаете файлы конфигурации с помощью синтаксиса HCL. Синтаксис HCL позволяет указать поставщика облачных служб, таких как Azure, и элементы, составляющие облачную инфраструктуру. После создания файлов конфигурации вы создадите план выполнения , который позволяет предварительно просмотреть изменения инфраструктуры перед развертыванием. После проверки изменений примените план выполнения для развертывания инфраструктуры.

Тесты интеграции проверяют, что новое изменение кода не нарушает существующий код. В DevOps непрерывная интеграция (CI) означает процесс, который создает всю систему каждый раз, когда изменяется кодовая база, например, когда кто-то хочет объединить PR в репозиторий Git. В следующем списке приведены распространенные примеры тестов интеграции:

Средства анализа статического кода, такие как lint и средства форматирования.
Выполните проверку terraform , чтобы проверить синтаксис файла конфигурации.
Запустите terraform план , чтобы убедиться, что конфигурация будет работать должным образом.

В этой статье описано, как:

Ознакомьтесь с основами тестирования интеграции для проектов Terraform.
Используйте Azure DevOps для настройки конвейера непрерывной интеграции.
Запустите статический анализ кода в коде Terraform.
Запустите terraform validate, чтобы проверить файлы конфигурации Terraform на локальном компьютере.
Запустите terraform plan, чтобы проверить файлы конфигурации Terraform в контексте удаленных служб.
Используйте Azure Pipeline для автоматизации непрерывной интеграции.

1. Настройка среды

Подписка Azure. Если у вас нет подписки Azure, создайте бесплатную учетную запись перед началом работы.

Настройте Terraform: если вы еще не сделали этого, настройте Terraform с помощью одного из следующих параметров:

Организация и проект Azure DevOps: если у вас нет организации, создайте организацию Azure DevOps.
Расширение "Задачи сборки и выпуска Terraform":установите расширение задач сборки и выпуска Terraform в организацию Azure DevOps.
Предоставьте Azure DevOps доступ к подписке Azure: создайте подключение службы Azure с именем , чтобы разрешить Azure Pipelines подключаться к подпискам Azure.
Пример кода и ресурсов: Скачайте из GitHub проект интеграции тестирования. Каталог, в который вы скачиваете пример, называется примером каталога.

2. Проверка локальной конфигурации Terraform

Команда terraform validate выполняется из командной строки в каталоге, содержающем файлы Terraform. Эта команда является главной целью проверки синтаксиса.

В каталоге примера перейдите к каталогу src.
Запустите terraform init , чтобы инициализировать рабочий каталог.
```
terraform init
```
Выполните проверку terraform , чтобы проверить синтаксис файлов конфигурации.
```
terraform validate
```
Ключевые моменты:
- Появится сообщение о том, что конфигурация Terraform действительна.
Измените файл main.tf.
В строке 5 вставьте опечатку, которая делает синтаксис недействительным. Например, замените var.location на var.loaction
Сохраните файл.
Снова запустите проверку.
```
terraform validate
```
Ключевые моменты:
- Отображается сообщение об ошибке, указывающее строку кода в ошибке и описание ошибки.

Как видно, Terraform обнаружил проблему в синтаксисе кода конфигурации. Эта проблема предотвращает развертывание конфигурации.

Рекомендуется всегда запускать terraform validate для проверки ваших файлов Terraform, прежде чем отправлять их в систему управления версиями. Кроме того, этот уровень проверки должен быть частью конвейера непрерывной интеграции. Далее в этой статье мы рассмотрим, как настроить конвейер Azure для автоматической проверки.

3. Проверка конфигурации Terraform

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

Terraform — это декларативный язык означает, что вы объявляете то, что вы хотите в качестве конечного результата. Например, предположим, что у вас есть 10 виртуальных машин в группе ресурсов. Затем вы создадите файл Terraform, определяющий три виртуальные машины. Применение этого плана не увеличивает общее число до 13. Вместо этого Terraform удаляет семь виртуальных машин, так что у вас остаётся три. Выполнение terraform plan позволяет подтвердить потенциальные результаты применения плана выполнения, чтобы избежать сюрпризов.

Чтобы создать план выполнения Terraform, выполните команду terraform plan. Эта команда подключается к целевой подписке Azure, чтобы проверить, какая часть конфигурации уже развернута. Затем Terraform определяет необходимые изменения в соответствии с требованиями, указанными в файле Terraform. На этом этапе Terraform не развертывает ничего. Это говорит вам, что произойдет, если вы применяете план.

Если вы выполните действия, описанные в предыдущем разделе, выполните команду terraform plan:

terraform plan

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

По умолчанию Terraform сохраняет состояние в том же локальном каталоге, что и файл Terraform. Этот шаблон хорошо работает в сценариях с одним пользователем. Однако при работе нескольких пользователей с одинаковыми ресурсами Azure локальные файлы состояний могут выйти из синхронизации. Чтобы устранить эту проблему, Terraform поддерживает запись файлов состояния в удаленное хранилище данных (например, в службу хранилища Azure). В этом сценарии может быть проблематично запускать terraform plan на локальном компьютере и обращаться к удалённому компьютеру. В результате может потребоваться автоматизировать этот шаг проверки в рамках конвейера непрерывной интеграции.

4. Выполнение анализа статического кода

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

Следующие средства предоставляют статический анализ для файлов Terraform:

Статический анализ часто выполняется частью конвейера непрерывной интеграции. Эти тесты не требуют создания плана выполнения или развертывания. В результате они выполняются быстрее, чем другие тесты, и обычно выполняются сначала в процессе непрерывной интеграции.

5. Автоматизация тестов интеграции с помощью Azure Pipeline

Непрерывная интеграция включает тестирование всей системы при появлении изменений. В этом разделе вы увидите конфигурацию Azure Pipeline, используемую для реализации непрерывной интеграции.

С помощью выбранного редактора перейдите к локальному клону примера проекта Terraform на GitHub.
Откройте файл samples/integration-testing/src/azure-pipeline.yaml.
Прокрутите вниз до шага , где вы увидите стандартный набор шагов, используемых для выполнения различных процедур установки и проверки.
Просмотрите строку, которая гласит Шаг 1: выполните анализ статического кода Checkov. На этом шаге проект Checkov, упомянутый ранее, выполняет статический анализ кода в примере конфигурации Terraform.
```
- bash: $(terraformWorkingDirectory)/checkov.sh $(terraformWorkingDirectory)
  displayName: Checkov Static Code Analysis
```
Ключевые моменты:
- Этот скрипт отвечает за запуск Checkov в рабочей области Terraform, смонтированной внутри контейнера Docker. Агенты, управляемые корпорацией Майкрософт, включены в Docker. Запуск инструментов внутри контейнера Docker легче и исключает необходимость установки Checkov на агенте Azure Pipeline.
- Переменная $(terraformWorkingDirectory) определена в файле azure-pipeline.yaml.
Просмотрите строку, которая гласит: Шаг 2: установите Terraform на агенте Azure Pipelines. Расширение задачи сборки и выпуска Terraform , установленное ранее, содержит команду для установки Terraform на агенте под управлением Azure Pipeline. Эта задача выполняется на этом шаге.
```
- task: charleszipp.azure-pipelines-tasks-terraform.azure-pipelines-tasks-terraform-installer.TerraformInstaller@0
  displayName: 'Install Terraform'
  inputs:
    terraformVersion: $(terraformVersion)
```
Ключевые моменты:
- Версия Terraform для установки указывается с помощью переменной Azure Pipeline с именем terraformVersion и определена в файле azure-pipeline.yaml.
Просмотрите строку, в которой говорится Шаг 3: запустите Terraform init, чтобы инициализировать рабочую область. Теперь, когда Terraform установлен на агенте, каталог Terraform можно инициализировать.
```
- task: charleszipp.azure-pipelines-tasks-terraform.azure-pipelines-tasks-terraform-cli.TerraformCLI@0
  displayName: 'Run terraform init'
  inputs:
    command: init
    workingDirectory: $(terraformWorkingDirectory)
```
Ключевые моменты:
- Входные данные command указывают, какая команда Terraform будет выполняться.
- Входные данные workingDirectory указывают путь к каталогу Terraform.
- Переменная $(terraformWorkingDirectory) определена в файле azure-pipeline.yaml.
Просмотрите строку, которая гласит, Шаг 4: выполните команду Terraform validate для проверки синтаксиса HCL. После инициализации каталога проекта выполняется terraform validate для проверки конфигурации на сервере.
```
- task: charleszipp.azure-pipelines-tasks-terraform.azure-pipelines-tasks-terraform-cli.TerraformCLI@0
  displayName: 'Run terraform validate'
  inputs:
    command: validate
    workingDirectory: $(terraformWorkingDirectory)
```
Просмотрите строку, в которой написано Шаг 5: выполните план Terraform для проверки синтаксиса HCL. Как описано ранее, создание плана выполнения выполняется для проверки допустимости конфигурации Terraform перед развертыванием.
```
- task: charleszipp.azure-pipelines-tasks-terraform.azure-pipelines-tasks-terraform-cli.TerraformCLI@0
  displayName: 'Run terraform plan'
  inputs:
    command: plan
    workingDirectory: $(terraformWorkingDirectory)
    environmentServiceName: $(serviceConnection)
    commandOptions: -var location=$(azureLocation)
```
Ключевые моменты:
- Входные environmentServiceName данные ссылаются на имя подключения службы Azure, созданного в разделе "Настройка среды". Подключение позволяет Terraform получить доступ к подписке Azure.
- Входные данные commandOptions используются для передачи аргументов команде Terraform. В этом случае указывается расположение. Переменная $(azureLocation) определена ранее в ФАЙЛЕ YAML.

Импорт конвейера в Azure DevOps

Откройте проект Azure DevOps и перейдите в раздел Azure Pipelines.
Нажмите кнопку "Создать конвейер ".
Для параметра "Где находится ваш код?" , выберите GitHub (YAML).
На этом этапе может потребоваться авторизовать Azure DevOps для доступа к вашей организации. Для получения дополнительной информации по этой теме см. статью Создание репозиториев GitHub.
В списке репозиториев выберите форк репозитория, созданный в вашей организации на GitHub.
На шаге "Настройка конвейера" выберите запуск из существующего конвейера YAML.
При отображении страницы выбора существующего конвейера YAML укажите ветвь master и введите путь к конвейеру YAML: samples/integration-testing/src/azure-pipeline.yaml
Выберите "Продолжить", чтобы загрузить конвейер Azure YAML из GitHub.
Когда отображается страница YAML конвейера, выберите "Выполнить", чтобы создать и запустить конвейер вручную в первый раз.

Проверка результатов

Конвейер можно запустить вручную из пользовательского интерфейса Azure DevOps. Однако суть статьи заключается в том, чтобы показать автоматическую непрерывную интеграцию. Протестируйте процесс, закоммитив изменение в папке samples/integration-testing/src форкнутого репозитория. Это изменение автоматически активирует новый конвейер в ветви, в которой выполняется отправка кода.

Пайплайн, запущенный из GitHub