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

Начиная с 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, которые соответствуют вашим потребностям.

На последнем этапе мастера выберите CI/CD с использованием рабочих процессов GitHub Actions (создание файла YML) и нажмите Готово.

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

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

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

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

Успешное развертывание также может потребовать доступа к субъекту-службе.

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

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

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

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

1. Щелкните правой кнопкой мыши узел GitHub Actions в Обозреватель решений и выберите новый рабочий процесс. Откроется мастер рабочего процесса GitHub Actions.

   

2. На целевом экране рабочего процесса GitHub Actions выберите Azure.

3. Для конкретного целевого объекта выберите "Приложения контейнеров Azure". Мастер переходит на экран приложения контейнера.

   

4. Выберите существующее приложение контейнера Azure или нажмите кнопку "Создать".

   

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

   

   После создания отображается новый экземпляр приложений контейнеров Azure.

   

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

   

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

   

   После создания новый реестр отображается на экране.

   

6. Отображаются развернутые проекты в решении; выберите проекты, которые нужно развернуть вместе в одном экземпляре приложений контейнеров Azure.

   

7. Нажмите кнопку Готово. Вы увидите команды, выданные для создания ресурсов в Azure и настройки проверки подлинности. Если что-либо не удается, обратите внимание на используемую командную строку, так как ее можно повторить из интерфейса командной строки. Не беспокойтесь слишком много, если на этом этапе происходит сбой авторизации. Вы также можете настроить проверку подлинности позже в Visual Studio.

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

9. Откройте файл рабочего процесса, чтобы проверка созданного 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 по написанию действий рабочего процесса; См. сведения о пользовательских действиях. Файл рабочего процесса содержит множество настраиваемых элементов, таких как параметры переменных среды и имена секретов. Ссылки на расположения Dockerfiles, имя приложения контейнера 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

Чтобы проверить изменения, зафиксируйте их и отправьте в ветвь репозитория, указанного в коде триггера. Вам не нужно создавать запрос на вытягивание (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 работает правильно, и проверка подлинности правильна, и вы по-прежнему видите проблемы с рабочим процессом, рассмотрите следующие ресурсы:

• Приложения контейнеров Azure на GitHub
• Приложения контейнеров Azure в StackOverflow

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

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

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

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