Развертывание файлов Bicep с помощью конвейера

  • 7 мин

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

Примечание.

Команды в этом уроке демонстрируют основные понятия. На этом этапе не выполняйте команды. Вскоре вы поупражняетесь с полученными знаниями.

Подключения к службе

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

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

Совет

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

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

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

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

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

Предупреждение

Может показаться, что проще сохранить учетные данные субъекта-службы в файле YAML и затем выполнить вход с помощью команды az login. Никогда не используйте этот метод для проверки подлинности субъекта-службы. Учетные данные хранятся в файле YAML в виде открытого текста. Все, кто имеет доступ к репозиторию, смогут просматривать и использовать эти учетные данные. Даже если вы ограничиваете доступ к организации и проекту Azure DevOps, каждый раз, когда кто-то клонирует репозиторий, файл YAML, содержащий учетные данные, будет перенесен на компьютер пользователя. Служебное подключение важно использовать всегда при работе с Azure из конвейера. Служебные подключения также предоставляют дополнительные функции управления безопасностью и доступом.

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

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

Развертывание файла Bicep с помощью задачи развертывания группы ресурсов Azure

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

- task: AzureResourceManagerTemplateDeployment@3
  inputs:
    connectedServiceName: 'MyServiceConnection'
    location: 'westus3'
    resourceGroupName: Example
    csmFile: deploy/main.bicep
    overrideParameters: >
        -parameterName parameterValue

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

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

  • connectedServiceName задает имя необходимого служебного подключения.
  • location является обязательным, даже если его значение не используется. Задача "Развертывание группы ресурсов Azure" также может создать группу ресурсов, но для этого она должна знать регион Azure, в котором будет создана группа ресурсов. В этом модуле вы укажет входное значение location, но не будете его использовать.
  • resourceGroupName обозначает имя группы ресурсов, в которую должен быть развернут файл Bicep.
  • overrideParameters содержит все значения параметров, которые будут переданы в файл Bicep при его развертывании.

При запуске задача использует служебное соединение для входа в Azure. К моменту, когда задача начинает выполнять указанное развертывание, она уже выполнила проверку подлинности. Вам не нужно выполнять az login.

Выполнение команд Azure CLI и Azure PowerShell

Две из наиболее полезных встроенных задач в Azure Pipelines — это задачи Azure CLI и Azure PowerShell. Эти задачи позволяют выполнить одну или несколько команд Azure CLI или PowerShell, соответственно.

В следующих модулях Microsoft Learn вы увидите, как команда Azure CLI помогает автоматизировать еще несколько частей процесса развертывания с использованием конвейера.

Переменные

Часто конвейеры содержат значения, которые необходимо хранить отдельно от файла YAML. Например, при развертывании файла Bicep в группе ресурсов необходимо указать имя группы ресурсов. При развертывании в разных средах имя группы ресурсов может различаться. Кроме того, может потребоваться указать параметры для файлов Bicep, включая секретные данные, такие как пароли сервера баз данных. Их не следует хранить в файле YAML конвейера или в другом месте в репозитории Git. Вместо этого для того, чтобы повысить безопасность и сделать определения конвейера пригодными для многократного использования, задействуйте переменные.

Создание переменной

Веб-интерфейс Azure Pipelines содержит редактор, с помощью которого можно создавать переменные для конвейера:

Снимок экрана: интерфейс Azure DevOps, на котором показано создание новой переменной.

Значение переменной Azure Pipelines можно задать в качестве секретного. Если значение переменной задано как секретное, вы не сможете просмотреть его после настройки. Azure Pipelines не раскрывает секретные значения в журналах конвейера.

Предупреждение

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

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

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

После создания переменной вы будете использовать для ссылки на нее в файле YAML конвейера специальный синтаксис:

- task: AzureResourceManagerTemplateDeployment@3
  inputs:
    connectedServiceName: $(ServiceConnectionName)
    location: $(DeploymentDefaultLocation)
    resourceGroupName: $(ResourceGroupName)
    csmFile: deploy/main.bicep
    overrideParameters: >
      -environmentType $(EnvironmentType)

Формат файла определения для конвейера включает специальный синтаксис $(VariableName). С помощью этого метода вы можете ссылаться на любую переменную, в том числе секретную.

Совет

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

Системные переменные

Azure Pipelines также поддерживает системные переменные. Они содержат предопределенную информацию, которая может потребоваться в конвейере, например: Ниже приведены некоторые системные переменные, которые можно использовать в конвейере.

  • Build.BuildNumber — это уникальный идентификатор для выполнения конвейера. Несмотря на свое имя, значение Build.BuildNumber часто является строкой, а не числом. Эту переменную можно использовать для именования развертывания Azure, чтобы можно было отследить выполнение конвейера, которое запустило развертывание.
  • Agent.BuildDirectory — это путь в файловой системе компьютера агента, где хранятся файлы выполнения конвейера. Эти сведения могут потребоваться, если нужно сослаться на файлы в агенте сборки.

Создание переменных в файле YAML конвейера

Помимо создания переменных в веб-интерфейсе Azure Pipelines, вы можете задавать их значения в файле YAML конвейера. Так можно делать, если у вас есть несекретные значения, которые можно хранить в репозитории и централизованно в одном файле, чтобы ссылаться на них в определении конвейера. Этот подход также позволяет отслеживать изменения переменной в системе управления версиями.

Чтобы задать переменную в файле YAML, добавьте раздел variables:

trigger: none

pool:
  vmImage: ubuntu-latest

variables:
  ServiceConnectionName: 'MyServiceConnection'
  EnvironmentType: 'Test'
  ResourceGroupName: 'MyResourceGroup'
  DeploymentDefaultLocation: 'westus3'

jobs:
- job:
  steps:
  - task: AzureResourceManagerTemplateDeployment@3
    inputs:
      connectedServiceName: $(ServiceConnectionName)
      location: $(DeploymentDefaultLocation)
      resourceGroupName: $(ResourceGroupName)
      csmFile: deploy/main.bicep
      overrideParameters: >
        -environmentType $(EnvironmentType)

В конвейере выше определены четыре переменные: ServiceConnectionName, EnvironmentType, ResourceGroupName и DeploymentDefaultLocation.

Далее в этом модуле вы узнаете, как в одном конвейере использовать переменные, определенные в разных местах.