Постройте практические конвейеры Azure DevOps для шаблонов ARM

При поиске в Интернете вы найдете различные блоги, документацию и руководства по Azure DevOps. Все эти материалы являются ценными ресурсами, но редко кто-то проведет вас через реальный сценарий. Многие пропускают аспект безопасности, оставляя пароли в открытом виде для простоты или создают конечный продукт, который существенно ничего не делает. Давайте изменить это.

В этой статье/уроке вы узнаете от начала до конца, как построить реальный конвейер выпуска Azure DevOps, автоматизирующий инфраструктуру. Более конкретно, вы узнаете, как использовать Azure DevOps для создания непрерывного конвейера развертывания для создания виртуальных машин Azure.

К концу этого проекта у вас будет полностью функционирующий конвейер Azure. После коммита в одном репозитории GitHub он будет:

• Создавать временную группу ресурсов Azure
• Создавать виртуальную машину Azure с помощью шаблона ARM
• Настроить этот шаблон ARM в конвейере CI/CD
• При любом изменении шаблона запустить проверку шаблона
• Развернуть шаблон ARM в Azure
• Протестировать развернутую инфраструктуру
• Удалить все ресурсы Azure

Давайте приступим!

Обзор проекта

Этот проект будет разбит на шесть основных разделов. Они такие:

Подготовка ресурсов Azure

В этом разделе вы узнаете, как настроить все необходимые ресурсы в Azure. Здесь вы сделаете следующее:

• Создайте служебный принципал Azure для различных задач в конвейере
• Настройте хранилище ключей Azure с секретами, которые будут использоваться в конвейере
• Установите соответствующие политики доступа для развертывания ARM и использования конвейера

Подготовка Azure DevOps

После того как все ресурсы Azure настроены, пришло время подготовить Azure DevOps для вашего конвейера. В этом разделе вы:

• Установите задачу сборки Pester Test Runner в вашей организации Azure DevOps
• Создайте сервисные подключения, чтобы предоставить Azure DevOps необходимый доступ к ресурсам
• Создайте группу переменных Azure DevOps, связав хранилище ключей для доступа к секретам хранилища ключей Azure

Обзор скриптов/шаблонов

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

Создание конвейера

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

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

Демонстрация конвейера

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

Очистка

И, наконец, так как это просто демонстрация, вы получите доступ к скрипту для разбора всего, что было создано во время учебного пособия.

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

Если вам нужен скрипт со всеми командами Azure CLI, используемыми для создания этого конвейера, вы можете найти его в репозитории GitHub ServerAutomationDemo как demo.ps1.

Предварительные требования

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

• Организация Azure DevOps – ознакомьтесь с руководством Быстрый старт от Microsoft, чтобы узнать, как это сделать. В этой статье вы будете работать с проектом под названием ServerAutomationDemo.
• A GitHub repo – In this article, you’ll be learning from a GitHub repo called ServerAutomationDemo. Sorry, we’re not using Azure repos in this article.
• A GitHub personal access token – Be sure to create the token with the permissions of admin:repo_hook, all repo and all user options.

• Оболочка Cloud Shell или PowerShell 6+, если вы работаете локально – примеры могут работать в Windows PowerShell, но они не были протестированы. Все примеры будут выполняться локально через консоль PowerShell, но Cloud Shell также будет работать. Вы будете автоматизировать создание конвейера.
• Установленный Azure CLI (если вы работаете локально) – в этой статье вы узнаете, как выполнять задачи с помощью Azure CLI. Однако те же самые процедуры можно выполнить через портал Azure, PowerShell или Azure SDK.

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

Перед началом

В этом руководстве вам предстоит выполнить множество настроек. Прежде чем начать, убедитесь, что у вас под рукой есть следующие элементы.

• Имя подписки Azure, куда будут развертываться ресурсы – в примерах будет использоваться имя Adam the Automator.
• Идентификатор подписки
• Идентификатор арендатора Azure AD
• Имя организации DevOps – в примерах будет использоваться adbertram.
• Регион, в который вы размещаете ресурсы – в примерах будет использоваться eastus.
• Имя группы ресурсов Azure, в которую будет размещен временный секретный сейф – в примерах будет использоваться ServerAutomationDemo.
• A password to assign to the local administrator account on a deployed VM – the examples will use “I like azure.”.
• URL-адрес репозитория GitHub – в примерах будет использоваться https://github.com/adbertram/ServerAutomationDemo.

Вход в систему с помощью Azure CLI

Будьте готовы выполнять много работы с помощью Azure CLI в статье. Я люблю команды Azure PowerShell, но Azure CLI в настоящее время способен выполнять больше задач DevOps.

Ваша первая задача – перейти в консоль PowerShell 6+. После входа в консоль выполните аутентификацию в Azure с помощью команды az login. Эта команда откроет окно браузера и запросит вашу учетную запись.

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

az login
az account set --subscription 'Adam the Automator'

Подготовка ресурсов Azure

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

Установка расширения Azure CLI для DevOps

Вам понадобится способ сборки различных компонентов Azure DevOps с помощью Azure CLI. По умолчанию это не включено. Чтобы управлять Azure DevOps из Azure CLI, вам нужно установить расширение DevOps.

К счастью, установка расширения – всего лишь одна строка, как показано ниже.

az extension add --name azure-devops

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

az devops configure --defaults organization=https://dev.azure.com/adbertram

Создание группы ресурсов

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

az group create --location "eastus" --name "ServerAutomationDemo"

Создание служебного принципала Azure

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

$spIdUri = "http://ServerAutomationDemo"
$sp = az ad sp create-for-rbac --name $spIdUri | ConvertFrom-Json

На этом этапе было бы неплохо сохранить значение $sp.appId где-то. Когда вы перейдете к созданию конвейера позже, вам это понадобится!

Вы заметите некоторые команды PowerShell в примерах, например, ConvertFrom-Json. Поскольку Azure CLI возвращает только строки JSON, удобнее обращаться к свойствам, если они преобразованы в объект PowerShell.

Создание хранилища ключей

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

Для создания хранилища ключей используйте команду az keyvault create, как показано ниже. Эта команда создает хранилище ключей в ранее созданной группе ресурсов. Также обратите внимание на переключатель enabled-for-template-deployment. Это изменяет политику доступа к хранилищу ключей для разрешения будущему развертыванию ARM обращаться к хранилищу ключей.

az keyvault create --location $region --name "ServerAutomationDemo-KV" --resource-group "ServerAutomationDemo" --enabled-for-template-deployment true

Создание секретов хранилища ключей

Как только хранилище ключей создано, пришло время создать секреты. Для этой демонстрации создайте два секрета с именами ServerAutomationDemo-AppPw и StandardVmAdminPassword. Пароль AppPw – это пароль для служебного принципала. Пароль VM будет назначен учетной записи локального администратора на развернутой виртуальной машине.

az keyvault secret set --name "ServerAutomationDemo-AppPw" --value $sp.password --vault-name "ServerAutomationDemo-KV"
az keyvault secret set --name StandardVmAdminPassword --value "I like azure." --vault-name "ServerAutomationDemo-KV"

Обратите внимание, что в этом примере вы используете ранее определенные переменные PowerShell. Здесь вы предоставляете пароль служебного принципала ($sp.password), полученный ранее.

Разрешение доступа к хранилищу ключей для конвейера

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

az keyvault set-policy --name "ServerAutomationDemo-KV" --spn $spIdUri --secret-permissions get list

Подготовка Azure DevOps

Теперь все готово для подготовки ресурсов Azure. Пора выполнить некоторую предварительную работу в Azure DevOps.

Установка расширения Pester

Первое, что нужно сделать, это установить расширение Azure DevOps PesterRunner. Конвейер будет выполнять два набора тестов Pester, чтобы убедиться в успешном развертывании VM ARM. Один из самых простых способов запуска тестов Pester – это использовать расширение PesterRunner.

Установите расширение с помощью следующей команды.

az devops extension install --extension-id PesterRunner --publisher-id Pester

Создание проекта Azure DevOps

Сейчас пришло время создать проект, в котором будет создан конвейер. Создание конвейера Azure DevOps – это легкость с Azure CLI. Просто выполните нижеприведенные команды, чтобы создать проект и установить его по умолчанию.

az devops project create --name "ServerAutomationDemo"
az devops configure --defaults project=ServerAutomationDemo

Создание сервисных подключений

Вашему конвейеру необходимо аутентифицироваться для взаимодействия с двумя службами – ARM и вашим репозиторием GitHub. Для этого необходимо создать два сервисных подключения.

Сначала создайте конечную точку сервиса ARM. Нижеприведенная команда запросит пароль служебного принципала. Обязательно сначала отобразите его в консоли и скопируйте его в буфер обмена.

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

## Запустите $sp.password и скопируйте его в буфер обмена
$sp.Password

## создайте конечную точку сервиса
az devops service-endpoint azurerm create --azure-rm-service-principal-id $sp.appId --azure-rm-subscription-id "YOURSUBSCRIPTIONIDHERE" --azure-rm-subscription-name 'Adam the Automator' --azure-rm-tenant-id $tenantId --name 'ARM'

Затем создайте сервисное подключение для GitHub. Поскольку конвейер будет запускаться с помощью коммита Git, ему нужно будет иметь возможность читать репозиторий.

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

$gitHubServiceEndpoint = az devops service-endpoint github create --github-url 'https://github.com/adbertram/ServerAutomationDemo' --name 'GitHub' | ConvertFrom-Json

## вставьте токен GitHub при запросе

Создание группы переменных

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

Сначала создайте группу переменных, как показано ниже.

az pipelines variable-group create --name "ServerAutomationDemo" --authorize true --variables foo=bar

Обратите внимание на переменную foo=bar? Она не используется, но для создания группы переменных требуется одна переменная.

Связывание Группы Переменных с Хранилищем Ключей

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

Перейдите в проект Azure DevOps и нажмите на Библиотека. Затем вы должны увидеть группу переменных ServerAutomationDemo, как показано ниже. Нажмите на группу переменных ServerAutomationDemo.

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

После подтверждения выберите соединение службы ARM и созданное ранее хранилище ключей ServerAutomationDemo-KV, как показано ниже. Нажмите Добавить.

Теперь отметьте оба созданных ранее секрета, как показано ниже, и нажмите OK и Сохранить, чтобы сохранить изменения.

Обзор Файлов Проекта

Если вы дошли до этого момента, поздравляю! Теперь вы готовы начать создавать конвейер. Но подождите… еще есть!

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

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

• azure-pipelines.yml – Финальный YAML-конвейер
• connect-azure.ps1 – Сценарий PowerShell для аутентификации в подписке Azure
• server.infrastructure.tests.ps1 – Простой тест Pester для подтверждения правильной конфигурации ВМ
• server.json – Шаблон Azure ARM для развертывания ВМ
• server.parameters.json – Шаблон параметров Azure ARM, предоставляющий значения параметров шаблона ARM.

Не забудьте заменить идентификатор вашей подписки и имя секретного хранилища для секретного хранилища IT в файле server.parameters.json.

• server.templates.tests.ps1 – Тесты “юнит” Pester для подтверждения корректности шаблона ARM

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

Создание конвейера

Предполагая, что вы клонировали мой репозиторий на GitHub или создали свой собственный, пришло время создать конвейер! Для этого выполните команду az pipelines create. Нижеприведенная команда создает конвейер с именем ServerAutomationDemo, используя предоставленный репозиторий на GitHub в качестве триггера. Он будет смотреть на ветку master и использовать ранее созданное соединение с службой.

az pipelines create --name "ServerAutomationDemo" --repository "https://github.com/adbertram/ServerAutomationDemo" --branch master --service-connection $gitHubServiceEndpoint.id --skip-run

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

Обзор конвейера YAML

На этом этапе ваш конвейер готов к запуску, но перед этим важно понять конвейер YAML. Взгляните на файл azure-pipelines.yml. Этот файл представляет собой конвейер при использовании функции многоэтапного конвейера YAML.

Давайте разберем различные компоненты, составляющие этот конвейер YAML.

Триггер

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

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

trigger:
  branches:
    include:
      - master
  paths:
    include:
      - server.json
      - server.parameters.json

Бассейн

Для каждой сборки требуется агент. Каждому агенту сборки необходимо работать на ВМ. В этом случае ВМ использует образ ВМ ubuntu-latest. Этот образ является образом по умолчанию, который был определен при создании сборки. Он не был изменен из-за “простоты” этого конвейера.

pool:
  vmImage: "ubuntu-latest"  

Переменные

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

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

Помните ли вы в разделе Создание служебного принципала Azure вам напоминали сохранить значение $sp.appId где-то? Именно здесь вам это понадобится. Присвойте значение идентификатора приложения этого служебного принципала переменной application_id, как показано ниже.

variables:
    - group: ServerAutomationDemo
    - name: azure_resource_group_name
      value: "ServerProvisionTesting-$(Build.BuildId)"
    - name: subscription_id
      value: "XXXXXXXXXXXXX"
    - name: application_id
      value: "XXXXXXXXXXXXX"
    - name: tenant_id
      value: "XXXXXXXXXXXX"

Обратите внимание на значение переменной azure_resource_group_name. Внутри этого значения вы увидите $(Build.BuildId). Это системная переменная, представляющая идентификатор сборки текущей задачи. В этом контексте она используется для обеспечения уникальности временной группы ресурсов, созданной.

Задачи предварительной обработки PowerShell

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

Первая задача вызывает сценарий с именем connect-azure.ps1, который существует в репозитории GitHub. Эта задача аутентифицирует подписку Azure для последующего выполнения команд Azure PowerShell.

Эта задача подключения Azure PowerShell вызывает сценарий и передает значение секрета из хранилища ключей (ServerAutomationDemo-AppPw) и переменные конвейера subscription_id, application_id и tenant_id.

Вторая задача выполняет код PowerShell встроенный, что означает, что сценарий не существует заранее. Вместо этого код PowerShell определен в YAML конвейера, используя значение переменной конвейера azure_resource_group_name.

- task: PowerShell@2
  inputs:
    filePath: "connect-azure.ps1"
    arguments: '-ServicePrincipalPassword "$(ServerAutomationDemo-AppPw)" -SubscriptionId $(subscription_id) -ApplicationId $(application_id) -TenantId $(tenant_id)'
- task: PowerShell@2
  inputs:
    targetType: "inline"
    script: New-AzResourceGroup -Name $(azure_resource_group_name) -Location eastus -Force

Шаблон теста Pester

Затем у нас есть первый тест Pester. В конвейере CI/CD, таком как этот, важно иметь несколько различных уровней тестирования. Если бы вы создавали конвейер для программного проекта, вы могли бы создать различные модульные тесты.

Поскольку этот примерный конвейер построен вокруг развертывания одного виртуального компьютера ARM, первые тесты “юнит” будут направлены на проверку корректности шаблона JSON. В файле server.templates.tests.ps1 вы можете добавить столько различных тестов непосредственно в файл шаблона ARM, сколько вам потребуется.

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

Задача PesterRunner отправляет результаты тестов в XML-файл, который затем будет использован на следующем этапе конвейера.

- task: Pester@0
  inputs:
    scriptFolder: "@{Path='$(System.DefaultWorkingDirectory)/server.template.tests.ps1'; Parameters=@{ResourceGroupName='$(azure_resource_group_name)'}}"
    resultsFile: "$(System.DefaultWorkingDirectory)/server.template.tests.XML"
    usePSCore: true
    run32Bit: False

Развертывание виртуального компьютера ARM

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

Обратите внимание на атрибут deploymentOutputs: arm_output. На следующем этапе задача должна подключиться к развернутому виртуальному компьютеру. Хороший способ получить DNS-имя или IP-адрес этого виртуального компьютера – вернуть его через развертывание ARM. Опция deploymentOutputs создает переменную конвейера, на которую можно ссылаться в других задачах.

- task: AzureResourceManagerTemplateDeployment@3
  inputs:
    deploymentScope: "Resource Group"
    azureResourceManagerConnection: "ARM"
    subscriptionId: "1427e7fb-a488-4ec5-be44-30ac10ca2e95"
    action: "Create Or Update Resource Group"
    resourceGroupName: $(azure_resource_group_name)
    location: "East US"
    templateLocation: "Linked artifact"
    csmFile: "server.json"
    csmParametersFile: "server.parameters.json"
    deploymentMode: "Incremental"
    deploymentOutputs: "arm_output"

Тест “Приемочные испытания” Pester

После развертывания виртуального компьютера необходимо убедиться, что это было сделано правильно с помощью “интеграционного” или “приемочного” теста. Эта задача PesterRunner вызывает Pester и запускает еще один набор тестов, связанных с инфраструктурой, чтобы гарантировать успешное развертывание виртуального компьютера.

Обратите внимание, что мы передаем значение вывода развертывания ARM через параметр ArmDeploymentJsonOutput. Файл тестового сценария Pester имеет определенный параметр, который принимает это значение и считывает DNS-имя хоста виртуальной машины.

 - task: Pester@0
    inputs:
      scriptFolder: "@{Path='$(System.DefaultWorkingDirectory)/server.infrastructure.tests.ps1'; Parameters=@{ArmDeploymentJsonOutput='$(arm_output)'}}"
      resultsFile: "$(System.DefaultWorkingDirectory)/server.infrastructure.tests.XML"
      usePSCore: true
      run32Bit: False

Вы можете видеть ниже, как выглядит PowerShell-скрипт server.infrastructure.tests.ps1. Обратите внимание, что он считывает DNS-имя хоста ВМ для выполнения простой проверки открытого порта.

$ArmDeploymentOutput = $ArmDeploymentJsonOutput | convertfrom-json

## Запуск тестов
describe 'Network Connnectivity' {
    it 'the VM has RDP/3389 open' {
        Test-Connection -TCPPort 3389 -TargetName $ArmDeploymentOutput.hostname.value -Quiet | should -Be $true
    }
}

Очистка теста “Приемка”

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

- task: PowerShell@2
  inputs:
    targetType: "inline"
    script: Get-AzResourceGroup -Name $(azure_resource_group_name) | Remove-AzResourceGroup -Force

Публикация теста Pester

И, наконец, мы подошли к последнему набору задач. В Azure Pipelines есть задача с именем Опубликовать результаты тестов. Эта задача читает XML-файл на агенте сборки и отображает результаты тестов в Azure DevOps. Это удобный способ легко увидеть результаты всех выполненных тестов.

- task: PublishTestResults@2
  inputs:
    testResultsFormat: "NUnit"
    testResultsFiles: "$(System.DefaultWorkingDirectory)/server.infrastructure.tests.XML"
    failTaskOnFailedTests: true

- task: PublishTestResults@2
  inputs:
    testResultsFormat: "NUnit"
    testResultsFiles: "$(System.DefaultWorkingDirectory)/server.template.tests.XML"
    failTaskOnFailedTests: true

Использование конвейера Azure DevOps

Наконец, мы готовы запустить конвейер и посмотреть, как он работает. В веб-интерфейсе Azure DevOps убедитесь, что вы находитесь в проекте ServerAutomationDemo. Здесь щелкните Конвейеры, а затем вы должны увидеть конвейер ServerAutomationDemo.

Один из способов запустить конвейер – нажать на три точки в самом правом углу, как показано ниже. Затем щелкните Запустить конвейер. Это запустит автоматизированное волшебство.

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

Очистка

После того как вы поиграли с конвейером и выполнили все здесь, вам следует убрать беспорядок. В конце концов, это было всего лишь учебное пособие, а не задача для производства!

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

$spId = ((az ad sp list --all | ConvertFrom-Json) | ? { '<https://ServerAutomationDemo>' -in $_.serviceprincipalnames }).objectId
az ad sp delete --id $spId

## Удалить группу ресурсов
az group delete --name "ServerAutomationDemo" --yes --no-wait

## удалить проект
$projectId = ((az devops project list | convertfrom-json).value | where { $_.name -eq 'ServerAutomationDemo' }).id
az devops project delete --id $projectId --yes

Итог

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

Теперь выходите и начинайте автоматизировать больше!