Развертывание приложения в Azure с помощью рабочих процессов GitHub Actions, созданных Visual Studio

Статья
08/23/2023

Начиная с Visual Studio 2019 версии 16.11, можно создать рабочие процессы GitHub Actions для проектов .NET, размещенных на GitHub.com.

Необходимые условия

Необходимо войти в учетную запись GitHub в Visual Studio.
Учетная запись Azure. Если у вас нет учетной записи Azure, активируйте преимущества Azure для подписчиков Visual Studio или зарегистрируйтесь для получения бесплатной пробной версии.

Развертывание одного проекта в Azure с помощью GitHub Actions

В проводнике решений щелкните правой кнопкой мыши проект, размещенный на GitHub.com, и выберите Опубликовать.

щелкните правой кнопкой мыши > Опубликовать

На следующем экране выберите Azure и нажмите кнопку Далее.

выберите Azure

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

выберите соответствующую службу Azure для проекта

На последнем шаге мастера выберите CI/CD с помощью рабочих процессов GitHub Actions (создает файл yml), а затем нажмите кнопку Готово.

CI/CD с использованием рабочих процессов GitHub Actions (создаёт файл yml)

Visual Studio создает новый рабочий процесс GitHub Actions и просит зафиксировать его и отправить его в GitHub.com.

коммит и отправка

Если выполнить этот шаг с помощью встроенных средств Git , Visual Studio обнаружит выполнение рабочего процесса.

рабочий процесс запущен

Настройка секретов GitHub

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

один секрет GitHub

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

два секрета GitHub

Во всех случаях Visual Studio пытается задать секретную переменную GitHub с корректным значением. Если он завершается ошибкой, он сообщит вам и даст вам возможность повторить попытку.

секрет GitHub отсутствует

Если не удается снова задать секрет, Visual Studio предоставляет возможность получить доступ к секрету вручную, чтобы можно было выполнить процесс на странице репозитория на GitHub.com.

задать отсутствующий секрет GitHub

Развертывание нескольких проектов в приложениях контейнеров Azure с помощью GitHub Actions

Эти действия подходят, если у вас есть несколько проектов, использующих контейнеры Docker, и вы хотите развернуть их в качестве многопроектного приложения. Можно развернуть многопроектные приложения, такие как микрослужбы для приложений контейнеров Azure или Службы Azure Kubernetes (AKS). В этой статье рассматриваются приложения контейнеров Azure.

Щелкните правой кнопкой мыши на узле GitHub Actions в Проводнике решений и выберите Создать рабочий процесс. Появится мастер настройки рабочего процесса GitHub Actions.
На целевом экране рабочего процесса GitHub Actions выберите Azure.
Для конкретного целевого объекта выберите приложения контейнеров Azure. Мастер переходит на экран приложения контейнера.
Выберите существующее приложение контейнера Azure или выберите Создать новое.

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

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

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

После создания новый реестр отображается на экране.
В решении отображаются проекты, которые можно развернуть; выберите проекты, которые нужно развернуть вместе в одном экземпляре приложений Azure Container Apps.
Нажмите кнопку Готово. Вы увидите команды, выданные для создания ресурсов в Azure и настройки проверки подлинности. Если что-либо не удается, обратите внимание на используемую командную строку, так как ее можно повторить из интерфейса командной строки. Не беспокойтесь слишком много, если на этом этапе происходит сбой авторизации. Вы также можете настроить проверку подлинности позже в Visual Studio.
По завершении появится экран сводки. На экране сводки отображаются учетные данные, соответствующие записям, создаваемым Visual Studio в репозитории GitHub в секретах GitHub Actions. Проверьте наличие всех желтых признаков предупреждения. Если любой из шагов проверки подлинности произошел сбой во время процесса создания, у вас есть возможность исправить это здесь, щелкнув ссылку на знак предупреждения и выполнив несколько действий.
Откройте файл рабочего процесса, чтобы проверить, что создано Visual Studio. Хотя Visual Studio делает все возможное, чтобы создать рабочий процесс для вашей ситуации, каждое приложение и репозиторий уникально, поэтому вам часто приходится вручную редактировать файл YML рабочего процесса, созданный Visual Studio, прежде чем он будет успешно запущен. Чтобы открыть его, разверните узел GitHub Actions в Проводнике решений, щелкните правой кнопкой мыши рабочий процесс, который только что был создан, и выберите Изменить.

Ниже показан пример файла рабочего процесса, созданного Visual Studio для решения с двумя развертываемыми проектами, WebAPI и WebFrontEnd.

on:
push:
  branches:
  - main
env:
CONTAINER_REGISTRY_LOGIN_SERVER: registry20230810121555.azurecr.io
CONTAINER_APP_NAME: containerapp20230810121017
CONTAINER_APP_RESOURCE_GROUP_NAME: webfrontend-container-app-1234
CONTAINER_APP_CONTAINER_NAME: containerapp
jobs:
WebApi_buildImageAndDeploy:
  runs-on: ubuntu-latest
  steps:
  - name: Checkout source code
    uses: actions/checkout@v3
  - name: Set up Docker Buildx
    uses: docker/setup-buildx-action@v2
  - name: Login to Docker registry
    uses: docker/login-action@v2
    with:
      registry: ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }}
      username: ${{ secrets.registry20230810121555_USERNAME_6891 }}
      password: ${{ secrets.registry20230810121555_PASSWORD_6891 }}
  - name: Build and push Docker image to Azure container registry
    uses: docker/build-push-action@v4
    with:
      push: true
      tags: ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }}/webapi:${{ github.sha }}
      file: WebApi\Dockerfile
  - name: Azure login
    uses: azure/login@v1
    with:
      creds: ${{ secrets.containerapp20230810121017_SPN }}
  - name: Deploy to Azure container app
    uses: azure/CLI@v1
    with:
      inlineScript: >-
        az config set extension.use_dynamic_install=yes_without_prompt
        az containerapp registry set --name ${{ env.CONTAINER_APP_NAME }} --resource-group ${{ env.CONTAINER_APP_RESOURCE_GROUP_NAME }} --server ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }} --username ${{ secrets.registry20230810121555_USERNAME_2047 }} --password ${{ secrets.registry20230810121555_PASSWORD_2047 }}
        az containerapp update --name ${{ env.CONTAINER_APP_NAME }} --container-name ${{ env.CONTAINER_APP_CONTAINER_NAME }} --resource-group ${{ env.CONTAINER_APP_RESOURCE_GROUP_NAME }} --image ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }}/webapi:${{ github.sha }}
  - name: Azure logout
    run: az logout
WebFrontEnd_buildImageAndDeploy:
  runs-on: ubuntu-latest
  needs: WebApi_buildImageAndDeploy
  steps:
  - name: Checkout source code
    uses: actions/checkout@v3
  - name: Set up Docker Buildx
    uses: docker/setup-buildx-action@v2
  - name: Login to Docker registry
    uses: docker/login-action@v2
    with:
      registry: ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }}
      username: ${{ secrets.registry20230810121555_USERNAME_2047 }}
      password: ${{ secrets.registry20230810121555_PASSWORD_2047 }}
  - name: Build and push Docker image to Azure container registry
    uses: docker/build-push-action@v4
    with:
      push: true
      tags: ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }}/webfrontend:${{ github.sha }}
      file: WebFrontEnd\Dockerfile
  - name: Azure login
    uses: azure/login@v1
    with:
      creds: ${{ secrets.containerapp20230810121017_SPN }}
  - name: Deploy to Azure container app
    uses: azure/CLI@v1
    with:
      inlineScript: >-
        az config set extension.use_dynamic_install=yes_without_prompt
        az containerapp registry set --name ${{ env.CONTAINER_APP_NAME }} --resource-group ${{ env.CONTAINER_APP_RESOURCE_GROUP_NAME }} --server ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }} --username ${{ secrets.registry20230810121555_USERNAME_2047 }} --password ${{ secrets.registry20230810121555_PASSWORD_2047 }}
        az containerapp update --name ${{ env.CONTAINER_APP_NAME }} --container-name ${{ env.CONTAINER_APP_CONTAINER_NAME }} --resource-group ${{ env.CONTAINER_APP_RESOURCE_GROUP_NAME }} --image ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }}/webfrontend:${{ github.sha }}
  - name: Azure logout
    run: az logout

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

Редактирование и тестирование рабочего процесса

В приведенной выше процедуре создается файл YML рабочего процесса, но, как правило, необходимо просмотреть и настроить его, прежде чем его можно будет использовать для развертывания. Возможно, вам потребуется обратиться к руководству GitHub по написанию рабочих действий; см. о пользовательских действиях. Файл рабочего процесса содержит множество настраиваемых элементов, таких как параметры переменных среды и имена секретов. Вы можете увидеть ссылки на местоположения ваших файлов Docker, имя вашего приложения-контейнера Azure, ветку в репозитории, которую вы будете использовать для запуска выполнения рабочего процесса, и ссылки на секреты в GitHub. На секреты ссылаются с помощью синтаксиса ${{ secrets.SECRET_NAME }}. См. секреты GitHub Actions.

Если проекты не находятся в корне репозитория, необходимо изменить рабочий процесс, чтобы указать путь для поиска Dockerfiles. Добавьте переменные среды для относительных путей к файлу Dockerfile в обоих проектах.

DOCKER_FILEPATH_WEBAPI: docker/ComposeSample/WebApi/Dockerfile
DOCKER_FILEPATH_WEBFRONTEND: docker/ComposeSample/WebFrontend/Dockerfile

Используйте значения этих переменных среды для параметра file следующим образом:

- name: Build and push Docker image to Azure container registry
  uses: docker/build-push-action@v4
  with:
    push: true
    tags: ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }}/webfrontend:${{ github.sha }}
    file: ${{ env.DOCKER_FILEPATH_WEBFRONTEND }}

Если необходимо внести изменения в Dockerfile, внесите и сохраните изменения, зафиксируйте и отправьте его в удаленный репозиторий. Рабочий процесс, создаваемый Visual Studio, содержит триггер, который приводит к его выполнению при обновлении в указанной ветви. Если вы отправляете в ветвь working, она должна выглядеть следующим образом:

on:
  push:
  branches:
  - working

Чтобы проверить изменения, зафиксируйте их и отправьте в ветвь репозитория, указанного в коде триггера. Вам не нужно создавать pull request (PR). Рабочий процесс выполняется до тех пор, пока триггер push установлен в правой ветви.

На вкладке Действия вашего репозитория на GitHub.com найдите запуск рабочего процесса. Вы можете получить его непосредственно с помощью ссылки на вкладке сводки GitHub Actions в Visual Studio. В GitHub можно открыть рабочий процесс для просмотра журналов.

Устранение неполадок

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

Проблема. Этап сборки не выполняет сборку

Одна из проблем, с которыми вы можете столкнуться в Dockerfile, заключается в том, что этап сборки не будет работать так, как это делает в Visual Studio. Файл Dockerfile по умолчанию, создаваемый Visual Studio для проекта, демонстрирует эту проблему. Если у вас есть файл «Dockerfile», рассмотрите следующие изменения на этапе сборки. Ниже приведен пример, в котором проект был расположен в docker/ComposeSample/WebApi в репозитории. Полный путь предоставляется, потому что контекст Dockerfile в контейнере сборки рабочего процесса установлен на корневой каталог репозитория, но в Visual Studio он задается на каталог, расположенный выше папки проекта. Суффикс _build добавляется здесь, чтобы создать папку сборки, а не просто копировать файл проекта, вся папка копируется. По сравнению с файлом Dockerfile по умолчанию, созданным Visual Studio, файловая часть пути в первом аргументе команды COPY была удалена, чтобы мы скопировали всю папку, а не только файл проекта. Без этих изменений на этом этапе возникает ошибка MSBuild.

FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
WORKDIR /src
COPY ["docker/ComposeSample/WebApi/", "WebApi_build/"]
RUN dotnet restore "WebApi_build/WebApi.csproj"
COPY . .
WORKDIR "/src/WebApi_build"
RUN dotnet build "WebApi.csproj" -c Release -o /app/build

Проблема: аутентификационные данные

Рабочий процесс требует настройки правильных секретов имени пользователя и пароля для доступа к Azure. Visual Studio пытается сделать это автоматически при создании ресурсов Azure или на экране GitHub Actions в интегрированной среде разработки Microsoft Visual Studio. Вы можете проверить секреты в GitHub и убедиться, что они есть, или повторно создать их и добавить их еще раз в GitHub при необходимости с помощью раздела "Параметры" в репозитории. Проверьте идентификатор секретов, на который ссылается каждый раздел рабочего процесса. При необходимости можно перейти в реестр контейнеров на портале Azure и получить имя пользователя и пароль для реестра контейнеров и использовать эти значения для обновления секретов в GitHub.

Если вы выполнили команду az ad sp create-for-rbac, чтобы настроить служебный субъект и получить идентификатор клиента, секрет клиента и идентификатор арендатора, добавьте идентификатор клиента и секрет клиента в качестве секретов в разделе секреты GitHub Actions для вашего репозитория GitHub. Учетные данные для входа Azure можно указать в виде имени пользователя (идентификатор клиента для приложения) и пароля (секрет клиента) для проверки подлинности приложения контейнеров Azure. Для этого замените шаг Azure login следующим кодом. Используйте собственные имена секретов GitHub, которые вы создали для идентификатора клиента и секрета клиента, а также используйте идентификатор арендатора из выходных данных выполнения той же команды.

- name: Azure login
  uses: azure/CLI@v1
  with:
    inlineScript: |
      az login --service-principal -u ${{ secrets.GITHUB_SECRETID_FOR_USERNAME }} -p ${{ secrets.GITHUB_SECRETID_FOR_PASSWORD }} --tenant {your tenant ID}
      az account list

Если Dockerfile работает правильно, и проверка подлинности правильна, и вы по-прежнему видите проблемы с рабочим процессом, рассмотрите следующие ресурсы:

Какие типы проектов поддерживаются?

ASP.NET Core
ASP.NET 5 и более поздних версий
Функции Azure

Какие службы Azure поддерживаются?

Веб-приложения Azure
Функции Azure
Управление API Azure

Поделиться через