Тестирование ресурсов после развертывания

6 мин

Проверяя и просматривая развертывание Bicep, вы смогли создать уверенность в том, что файлы Bicep будут успешно развернуты. Но развертывание не является всей историей. После завершения развертывания также полезно убедиться, что развертывание работает, как ожидалось.

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

Выполнение тестов состояния и отрицательных тестов

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

Например, вы развертываете новый логический сервер SQL Azure с помощью рабочего процесса развертывания Bicep. Определение Bicep для сервера является допустимым, поэтому оно проходит задания анализа кода и предварительной проверки. Команда "что, если" показывает, что сервер будет создан, как вы и ожидаете. Развертывание также завершается успешно. Но в конце процесса развертывания вы можете не получить работающий и готовый к использованию сервер базы данных. Это может произойти по следующим причинам:

Правила брандмауэра не были настроены, чтобы разрешить сетевой трафик для доступа к серверу.
Вы включили проверку подлинности Microsoft Entra на сервере, если вы не должны иметь или наоборот.

Даже если вы просто развертываете базовые файлы Bicep, стоит проверить, что ресурсы действительно работают и соответствуют вашим требованиям. Ниже приведены примеры того, как можно применить этот принцип:

При развертывании веб-сайта попробуйте связаться с веб-приложением из рабочего процесса. Убедитесь, что рабочий процесс успешно подключен к веб-сайту и получает допустимый код ответа.
При развертывании сети доставки содержимого (CDN) попробуйте подключиться к ресурсу через CDN. Убедитесь, что рабочий процесс успешно подключен к CDN и получает допустимый код ответа.

Эти тесты иногда называют тестами проверки сборки. Тест состояния — это простая форма тестирования, предназначенная для выявления в развертывании серьезных проблем.

Примечание.

Некоторые ресурсы Azure не так легко доступны из средств выполнения, размещенных на GitHub. Для выполнения заданий тестирования состояния, если им необходим доступ к ресурсам через частные сети, может потребоваться использование локального средства выполнения.

Кроме того, рекомендуется выполнять отрицательное тестирование. Отрицательное тестирование помогает убедиться в отсутствии нежелательного поведения ресурсов. Например, при развертывании виртуальной машины рекомендуется использовать Бастион Azure для безопасного подключения к виртуальной машине. Вы можете добавить в рабочий процесс отрицательный тест, чтобы убедиться в отсутствии возможности прямого подключения к виртуальной машине с помощью подключения к удаленному рабочему столу или SSH.

Внимание

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

Запуск тестов из рабочих процессов GitHub

Существует множество способов выполнения тестов в рабочем процессе. В этом модуле мы используем Pester, средство с открытым кодом, которое запускает тесты, написанные с помощью PowerShell. Pester предустановлен на средства выполнения, размещенные на GitHub. Для использования его в шаге скрипта ничего делать не нужно.

Вы можете использовать другую платформу тестирования или даже выполнять тесты без средства тестирования. Еще одно средство тестирования, которое можно использовать, — инструмент PSRule для Azure, включающий предварительно созданные правила и тесты для Azure. Он может выполнять проверку шаблонов, а также запускать тесты для развернутых ресурсов Azure. Ссылка на PSRule представлена в сводке.

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

Результаты теста записываются в журнал рабочего процесса. GitHub Marketplace также содержит действия, отличные от Майкрософт, которые могут отображать и отслеживать результаты тестирования с течением времени.

Передача данных между заданиями

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

Файл Bicep развертывает ресурсы, поэтому может получить доступ к свойствам ресурса и опубликовать их как выходные данные развертывания. При запуске развертывания Bicep с помощью arm-deploy действия это действие сохраняет эти выходные данные развертывания Bicep в выходных данных шага. Затем это задание, содержащее действие arm-deploy, может опубликовать выходные данные шага как выходные данные задания. Задание ссылается на свойство шага id , для которого задано значение deploy:

deploy:
  runs-on: ubuntu-latest
  environment: Website
  needs: preview
  outputs:
    appServiceAppHostName: ${{ steps.deploy.outputs.appServiceAppHostName }}
  steps:
  - uses: actions/checkout@v3
  - uses: azure/login@v1
    name: Sign in to Azure
    with:
      client-id: ${{ secrets.AZURE_CLIENT_ID }}
      tenant-id: ${{ secrets.AZURE_TENANT_ID }}
      subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
  - uses: azure/arm-deploy@v1
    id: deploy
    name: Deploy website
    with:
      deploymentName: ${{ github.run_number }}
      resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
      template: ./deploy/main.bicep
      parameters: environmentType=${{ env.ENVIRONMENT_TYPE }}

Вы можете получить доступ к выходным данным задания в любом последующем задании, если оно зависит от задания, создающего выходные данные:

smoke-test:
  runs-on: ubuntu-latest
  needs: deploy
  steps:
  - uses: actions/checkout@v3
  - run: |
      $container = New-PesterContainer `
        -Path 'deploy/Website.Tests.ps1' `
        -Data @{ HostName = '${{needs.deploy.outputs.appServiceAppHostName}}' }
      Invoke-Pester `
        -Container $container `
        -CI
    name: Run smoke tests
    shell: pwsh

Кроме того, вы можете передавать выходные данные из скрипта рабочего процесса с помощью специального синтаксиса. Ссылка на дополнительные сведения приведена в сводке.

Другие типы тестов

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

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

Откат или накат

Предположим, ваш рабочий процесс успешно развертывает ресурсы, однако тесты завершаются сбоем. Что следует сделать?

Ранее в этом модуле вы узнали, что GitHub Actions позволяет создавать задания отката, которые выполняются в случае сбоя предыдущего задания. Этот подход можно использовать для создания задания отката, когда задание тестирования сообщает о непредвиденном результате. Вы также можете вручную откатить изменения или повторно запустить весь рабочий процесс, если вы думаете, что сбой был вызван временной проблемой, которая уже устранена.

Примечание.

При отправке развертывания в Azure Resource Manager можно запросить автоматическое повторное выполнение последнего успешного развертывания в случае сбоя. Для этого используйте параметр --rollback-on-error при отправке развертывания с помощью команды az deployment group create Azure CLI.

Например, в рабочий процесс можно добавить задание отката. Задание отката выполняется при сбое задания тестирования состояния:

rollback: 
  runs-on: ubuntu-latest
  needs: smoke-test
  if: ${{ always() && needs.smoke-test.result == 'failure' }}
  steps:
  - run: |
      echo "Performing rollback steps..."

Это задание зависит от задания тестирования состояния. Оно выполняется только в случае сбоя теста состояния. По умолчанию GitHub Actions останавливает рабочий процесс при сбое предыдущего задания. Условие if включает проверку always() для переопределения этого поведения. always() Без выражения задание отката пропускается при сбое предыдущего задания.

Выработать шаги для выполнения в задании отката зачастую оказывается нелегко. Как правило, развертывания Bicep являются сложными и не легко откатить изменения. Особенно сложно выполнить откат, если развертывание включает другие компоненты.

Например, представьте, что рабочий процесс развертывает файл Bicep, который определяет базу данных SQL Azure, а затем добавляет в базу данных некоторые данные. Следует ли удалять данные при откате развертывания? Следует ли удалять и базу данных? Сложно предсказать, каким образом может повлиять на выполняемую среду каждый сбой и каждый откат.

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

Совет