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

6 мин

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

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

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

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

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

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

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

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

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

Примечание.

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

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

Внимание

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

Выполнение тестов в Azure Pipelines

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

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

Передача данных между шагами и этапами

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

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

Во-первых, необходимо опубликовать выходную переменную для этапа конвейера. Чтобы вывести переменную, вы напишете специально отформатированную строку в журнал конвейера, который Azure Pipelines знает, как понять. В следующем примере переменной myVariable присваивается значение myValue.

echo "##vso[task.setvariable variable=myVariable;isOutput=true]myValue"

Azure Pipelines считывает и интерпретирует строку из журнала конвейера и открывает к значению переменной доступ как к выходным данным. Это значение можно объединить с дополнительными сценариями для публикации значения выходных данных развертывания Bicep в качестве выходной переменной для этапа конвейера. Эти сценарии будут реализованы в следующем упражнении.

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

- stage: SmokeTest
  jobs:
  - job: SmokeTest
    variables:
      myVariable: $[ stageDependencies.DeployStage.DeployJob.outputs['DeployJob.DeployStep.myVariable'] ]

Теперь все шаги в задании тестирования проверки сборки могут обращаться к значению myVariable так же, как и к любой другой переменной, с помощью синтаксиса $(myVariable). В следующем упражнении вы будете использовать переменную.

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

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

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

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

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

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

Примечание.

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

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

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

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

Совет