Предварительный просмотр и утверждение развертывания

5 мин

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

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

Операция "что, если"

Файл Bicep описывает состояние, в котором должна находиться среда Azure в конце развертывания. При отправке развертывания Azure Resource Manager изменяет среду Azure в соответствии с состоянием, описанным в файле Bicep.

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

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

Resource Manager предоставляет операцию "что если", которую можно выполнить в файле Bicep в задании рабочего процесса:

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

Действие arm-deploy поддерживает активацию операции what-if с помощью additionalArguments свойства:

jobs:
  preview:
     runs-on: ubuntu-latest
     needs: [lint, validate]
     steps: 
     - uses: azure/login@v1
       name: Sign in to Azure
       with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
     - uses: azure/arm-deploy@v1
       name: Run what-if
       with:
         failOnStdErr: false
         resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
         template: deploy/main.bicep
         parameters: >
           environmentType=${{ env.ENVIRONMENT_TYPE }}
         additionalArguments: --what-if

Выделенный код эквивалентен выполнению развертывания с помощью Azure CLI с включенным аргументом --what-if .

Операция "что, если" не вносит изменений в среду. Она описывает ресурсы, которые будут созданы, свойства ресурсов, которые будут обновлены, и ресурсы, которые будут удалены.

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

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

Дополнительные сведения о команде "что, если" см. в модуле Microsoft Learn Предварительный просмотр развертывания Azure с помощью команды "что, если".

Среды

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

Среду можно создать с помощью веб-интерфейса GitHub. Вы можете создавать среды при работе с общедоступным репозиторием GitHub или при использовании учетной записи GitHub Enterprise.

После создания среды вы можете ссылаться на нее в любых заданиях в рабочем процессе:

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: 'Lint Bicep template'
      run: az bicep build --file deploy/main.bicep

  validate:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - 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:
        deploymentName: ${{ github.run_number }}
        resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
        template: ./deploy/main.bicep
        parameters: environmentType=${{ env.ENVIRONMENT_TYPE }}
        deploymentMode: Validate

  deploy:
    runs-on: ubuntu-latest
    environment: MyAzureEnvironment
    needs: [lint, validate]
    steps:
    - uses: actions/checkout@v3
    - 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:
        deploymentName: ${{ github.run_number }}
        resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
        template: ./deploy/main.bicep
        parameters: environmentType=${{ env.ENVIRONMENT_TYPE }}

Примечание.

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

Правила защиты среды

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

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

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

Как работают правила защиты среды?

При связывании среды с шагом правила защиты среды оцениваются непосредственно перед началом шага.

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

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

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

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

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

Важность эффективных методов

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

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