Публикация кода Bicep из рабочего процесса развертывания

Завершено

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

Спецификации шаблонов и модули

Bicep позволяет с легкостью использовать код повторно. Ниже приведены два распространенных подхода к повторному использованию кода Bicep в развертываниях:

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

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

Проверка повторного использования кода в рабочем процессе

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

Рекомендуется выполнить анализ кода Bicep. Анализатор кода обнаруживает синтаксические проблемы и предупреждает вас, если вы не следуете рекомендациям.

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

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

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

Совет

Мы рекомендуем проверить код Bicep с помощью GitHub Actions для получения дополнительных сведений о тестировании файлов Bicep в автоматизированном рабочем процессе.

Проверка подлинности и авторизация

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

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

Совет

При публикации модуля в реестр идентификатор рабочей нагрузки, выполняющий развертывание, скорее всего, не требует большого количества разрешений. Если в реестре используется авторизация Microsoft Entra, удостоверение рабочей нагрузки требует только разрешения AcrPush для реестра.

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

Публикация спецификаций шаблонов и модулей из рабочего процесса

При публикации спецификации шаблона с собственного компьютера с помощью Azure CLI вы используете следующую команду:

az ts create \
  --name StorageWithoutSAS \
  --location westus3 \
  --display-name "Storage account with SAS disabled" \
  --description "This template spec creates a storage account, which is preconfigured to disable SAS authentication." \
  --version 1 \
  --template-file main.bicep

Эту команду Azure CLI можно преобразовать в этап GitHub Actions:

- name: Publish template spec
  uses: azure/cli@v1
  with:
    inlineScript: |
      az ts create \
        --name StorageWithoutSAS \
        --location westus3 \
        --display-name "Storage account with SAS disabled" \
        --description "This template spec creates a storage account, which is preconfigured to disable SAS authentication." \
        --version 1 \
        --template-file main.bicep

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

Аналогичным образом при публикации модуля Bicep с собственного компьютера с помощью Azure CLI вы используете следующую команду:

az bicep publish \
   --file module.bicep \
   --target 'br:toycompany.azurecr.io/mymodules/myqueue:2'

Эту команду Azure CLI можно преобразовать в этап GitHub Actions.

- name: Publish Bicep module
  uses: azure/cli@v1
  with:
    inlineScript: |
      az bicep publish \
        --file module.bicep \
        --target 'br:toycompany.azurecr.io/mymodules/myqueue:2'

Совет

В этом примере имя узла реестра Bicep (toycompany.azurecr.io) внедряется в определение этапа рабочего процесса. Однако делать это не рекомендуется. Для задания параметров конфигурации можно использовать переменные среды, как показано ниже. Вы увидите, как это работает позже в этом модуле обучения Microsoft Learn.

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

Использование спецификации модуля или шаблона

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

Например, вы развертываете спецификацию шаблона или файл Bicep в группе ресурсов с помощью команды Azure CLI az deployment group create или командлета New-AzResourceGroupDeployment в Azure PowerShell.