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

  • 7 мин

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

Заметка

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

Ознакомьтесь с кодом

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

Чтобы проверить код, можно использовать действие actions/checkout@v3:

name: MyWorkflow

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
      with:
        path: repo

Обратите внимание, что рабочий процесс включает ключевое слово uses. Ключевое слово указывает, что вы хотите использовать предопределенное действие с именем actions/checkout.

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

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

Проверка подлинности в Azure

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

Совет

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

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

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

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

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

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

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

Вход в Azure

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

name: MyWorkflow

on: [workflow_dispatch]

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
      with:
        path: repo
    - uses: azure/login@v1
      with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

Действие azure/login требует предоставления трех частей информации для использования идентификации рабочей нагрузки: идентификатор приложения Microsoft Entra, идентификатор тенанта Microsoft Entra (каталога) и идентификатор подписки Azure, которую вы хотите использовать.

После выполнения этого действия средство выполнения будет проходить проверку подлинности и выполнять инструкции в среде Azure.

Разверните ваш Bicep-файл

После авторизации рабочего процесса в Azure он может использовать объект идентификации рабочей нагрузки для запуска развертывания Bicep. В GitHub Actions вы используете операцию azure/arm-deploy для инициирования развертывания Bicep.

Заметка

Существуют и другие способы развертывания Bicep-файлов из GitHub Actions. Например, можно использовать действие azure/CLI, а затем предоставить команды Azure CLI для запуска развертываний. Тем не менее, так как задача azure/arm-deploy специально предназначена для развертываний, вы будете использовать это в этом модуле.

Ниже приведен пример настройки шага для использования действия azure/arm-deploy:

name: MyWorkflow

on: [workflow_dispatch]

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
      with:
        path: repo
    - uses: azure/login@v1
      with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
    - uses: azure/arm-deploy@v1
      with:
        resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
        template: ./deploy/main.bicep
        parameters: environmentType=Test

Действие azure/arm-deploy принимает несколько параметров, в том числе:

  • resourceGroupName: имя группы ресурсов, в которой требуется развернуть ресурсы, определенные в файле Bicep.
  • template: путь к Bicep-файлу в репозитории. Путь относительно корневого каталога репозитория.
  • parameters. Указывает все значения параметров, предоставляемые во время развертывания. В этом примере мы предоставляем значение параметра environmentType.

Так как предыдущее действие azure/login уже зарегистрировало ваш рабочий процесс в Azure, шаг azure/arm-deploy выполняется на аутентифицированном агенте.

Переменные

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

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

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

env:
    AZURE_RESOURCEGROUP_NAME: gh-actions
    AZURE_WEBAPP_NAME: webapp-gh-actions

В предыдущем примере мы указываем две переменные среды.

Использование переменной в рабочем процессе

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

${{ env.AZURE_RESOURCEGROUP_NAME }}

Переменные среды по умолчанию

GitHub Actions также использует переменные среды по умолчанию. Переменные среды по умолчанию содержат предопределенные сведения, которые может потребоваться использовать в рабочем процессе. Ниже приведены некоторые переменные среды по умолчанию, которые можно использовать в рабочем процессе:

  • github.sha: идентификатор коммита Git, который активировал выполнение рабочего процесса.
  • github.run_number: уникальное число для каждого запуска определенного рабочего процесса в репозитории. Это число начинается с 1 для первого запуска рабочего процесса и увеличивается при каждом новом запуске. Вы можете использовать эту переменную для имени развертывания Azure, чтобы вернуться к конкретному запуску рабочего процесса, который его инициировал.

    Заметка

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

Секреты

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

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

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

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

Секреты можно создать с помощью веб-интерфейса GitHub. Чтобы ссылаться на значение секрета в рабочем процессе, используйте следующий синтаксис:

${{ secrets.NAME_OF_THE_SECRET }}

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

Совет

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

В этом модуле вы будете использовать секреты GitHub для хранения сведений, необходимых задаче azure/login для входа в Azure: подписки Microsoft Entra и идентификатора клиента и идентификатора регистрации приложения рабочей нагрузки.