Implantar seu aplicativo no Azure usando fluxos de trabalho do GitHub Actions criados pelo Visual Studio

A partir do Visual Studio 2019 versão 16.11, você pode criar novos fluxos de trabalho do GitHub Actions para projetos do .NET hospedados no GitHub.com.

Pré-requisitos

• Você deve estar conectado à sua conta do GitHub no Visual Studio.
• Uma conta do Azure. Se você não tiver uma conta do Azure, ative seus benefícios do Azure para assinantes do Visual Studio ou inscreva-se para uma avaliação gratuita.

Implantar um único projeto no Azure usando o GitHub Actions

No Gerenciador de Soluções, clique com o botão direito do mouse em seu projeto hospedado GitHub.com e escolha Publicar.

Na próxima tela, selecione Azure e escolha Avançar.

do Azure

Dependendo do tipo de projeto, você obtém uma lista diferente dos serviços do Azure para escolher. Escolha um dos serviços do Azure com suporte que atenda às suas necessidades.

Na etapa final do assistente, selecione CI/CD usando fluxos de trabalho do GitHub Actions (gera o arquivo yml) e escolha Concluir.

O Visual Studio gera um novo fluxo de trabalho do GitHub Actions e solicita que você o confirme e envie por push para GitHub.com.

por push

Se você concluir esta etapa usando as ferramentas internas do Git , o Visual Studio detectará o fluxo de trabalho.

Definindo os segredos do GitHub

Para que o fluxo de trabalho gerado seja implantado com êxito no Azure, ele pode exigir acesso a um perfil de publicação .

secreto do GitHub

Uma implantação bem-sucedida também pode exigir acesso a uma entidade de serviço.

Em todos os casos, o Visual Studio tenta definir o segredo do GitHub para você com o valor correto. Se falhar, ele lhe informará e lhe dará a oportunidade de tentar novamente.

Se ele não definir o segredo novamente, o Visual Studio lhe dará a oportunidade de obter acesso ao segredo manualmente, para que você possa concluir o processo por meio da página do repositório no GitHub.com.

Implantar vários projetos em Aplicativos de Contêiner do Azure usando o GitHub Actions

Essas etapas são apropriadas se você tiver mais de um projeto que usa contêineres do Docker e quiser implantá-los como um aplicativo multiprojeto. Você pode implantar aplicativos multiprojetos, como aqueles que implementam microsserviços para aplicativos de contêiner do Azure ou do AKS (Serviço de Kubernetes do Azure). Este artigo aborda os Aplicativos de Contêiner do Azure.

1. Clique com o botão direito do mouse no nó do GitHub Actions no Gerenciador de Soluções e escolha Novo fluxo de trabalho. O assistente de fluxo de trabalho do GitHub Actions é exibido.

   

2. Na tela de destino do fluxo de trabalho do GitHub Actions, escolha Ação.

3. Para o destino específico, escolha Aplicativos de Contêiner do Azure. O assistente avança para a tela Aplicativo de Contêiner.

   

4. Escolha um Aplicativo de Contêiner do Azure existente ou escolha Criar novo.

   

   Ao criar um novo, você verá essa tela. Ao testar ou aprender, geralmente é melhor criar um novo grupo de recursos para facilitar a exclusão de tudo mais tarde. Um Ambiente de Aplicativos de Contêiner é um limite seguro em torno de grupos de aplicativos de contêiner que compartilham a mesma rede virtual e registram logs no mesmo destino de registro. Confira Ambientes do Aplicativos de Contêiner do Azure. Se você não sabe o que é ou não criou um antes, crie um novo para essa instância.

   

   Depois de criada, a nova instância dos Aplicativos de Contêiner do Azure é mostrada.

   

5. Escolha Avançar para avançar para a tela Registro. Escolha um Registro de Contêiner do Azure existente ou crie um.

   

   Se você optar por criar um novo, verá esta tela. Forneça o grupo de recursos, a SKU e escolha a mesma região, se possível, como antes. Para obter informações sobre as SKUs do Registro de Contêiner do Azure, confira Tipos de serviço do Registro de Contêiner do Azure.

   

   Depois de criado, o novo registro é exibido na tela.

   

6. Os projetos implantáveis em sua solução são exibidos; escolha os projetos que você deseja implantar juntos na mesma instância dos Aplicativos de Contêiner do Azure.

   

7. Escolha Concluir. Você pode ver os comandos que estão sendo emitidos para criar os ativos no Azure e configurar a autenticação. Se algo falhar, observe a linha de comando usada, pois você pode tentar novamente na CLI. Não se preocupe muito se houver uma falha de autorização nessa fase. Você também pode configurar a autenticação posteriormente no Visual Studio.

8. Após a conclusão, a tela de resumo será exibida. A tela de resumo mostra as credenciais, que correspondem às entradas que o Visual Studio cria em seu repositório GitHub nos segredos do GitHub Actions. Verifique se há sinais de aviso amarelos. Se alguma das etapas de autenticação falhar durante o processo de criação, você terá a oportunidade de corrigir isso aqui clicando no link pelo sinal de aviso e seguindo algumas etapas.

9. Abra o arquivo de fluxo de trabalho para verificar o que o Visual Studio gerou. Embora o Visual Studio faça o possível para gerar um fluxo de trabalho para sua situação, cada aplicativo e repositório é exclusivo, portanto, você geralmente precisa editar manualmente o arquivo YML de fluxo de trabalho gerado pelo Visual Studio antes que ele seja executado com êxito. Para abri-lo, expanda o nó do GitHub Actions no Gerenciador de Soluções, clique com o botão direito do mouse no fluxo de trabalho que acabou de ser criado e escolha Editar.

O exemplo a seguir mostra um exemplo de um arquivo de fluxo de trabalho criado pelo Visual Studio para uma solução com dois projetos implantáveis, WebAPI e 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

A função principal do fluxo de trabalho é entrar nos serviços do Azure com a autenticação certa e executar os comandos para criar e implantar o aplicativo.

Editando e testando o fluxo de trabalho

O procedimento acima gera um arquivo YML de fluxo de trabalho, mas você normalmente precisa revisá-lo e personalizá-lo antes que ele possa ser usado para uma implantação. Talvez seja necessário consultar as diretrizes do GitHub sobre como escrever ações de fluxo de trabalho; consulte Sobre ações personalizadas. O arquivo de fluxo de trabalho contém muitos elementos configuráveis, como as configurações para as variáveis de ambiente e os nomes dos segredos. É possível ver referências aos locais dos seus Dockerfiles, o nome do seu Aplicativos de Contêiner do Azure, a ramificação no repositório que você utilizará para disparar as execuções do fluxo de trabalho e referências aos segredos no GitHub. Os segredos são referenciados usando a sintaxe ${{ secrets.SECRET_NAME }}. Confira Segredos do GitHub Actions.

Se seus projetos não estiverem localizados na raiz do repositório, você precisará alterar o fluxo de trabalho para especificar o caminho para localizar os Dockerfiles. Adicione variáveis de ambiente para os caminhos relativos ao Dockerfile em ambos os projetos.

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

Use os valores dessas variáveis de ambiente para o parâmetro file da seguinte maneira:

- 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 }}

Se você precisar fazer alterações no Dockerfile, faça e salve as alterações, confirme e envie por push para o repositório remoto. O fluxo de trabalho gerado pelo Visual Studio contém um gatilho que faz com que ele seja executado se atualizado em um branch especificado. Se estiver enviando para a ramificação working, ele deverá se parecer com o código a seguir:

on:
  push:
  branches:
  - working

Para testar as alterações, confirme-as e envie para a ramificação do repositório especificado no código do gatilho. Você não precisa criar uma solicitação de pull (PR). O fluxo de trabalho é executado desde que o gatilho push esteja definido para a ramificação correta.

Na guia Ações no seu repositório em GitHub.com, procure a execução do fluxo de trabalho. Você pode chegar lá diretamente usando um link na guia resumo do GitHub Actions no Visual Studio. No GitHub, você pode abrir a execução do fluxo de trabalho para exibir os logs.

Solução de problemas

As dicas de solução de problemas a seguir podem ser úteis se o fluxo de trabalho não for executado com êxito.

Problema: o estágio de compilação não foi compilado

Um problema que você pode encontrar no Dockerfile é que o estágio de build não funcionará como no Visual Studio. O Dockerfile padrão gerado pelo Visual Studio para um projeto demonstra esse problema. Considere as seguintes modificações no estágio de build se você tiver esse Dockerfile. Aqui está um exemplo em que um projeto foi localizado em docker/ComposeSample/WebApi em um repositório. O caminho completo é fornecido porque o contexto do Dockerfile no contêiner de compilação do fluxo de trabalho é definido como a raiz do repositório, mas no Visual Studio, ele é definido como a pasta acima da pasta do projeto. O sufixo _build é acrescentado aqui para criar a pasta de build e, em vez de apenas copiar o arquivo de projeto, a pasta inteira é copiada. Em comparação com o Dockerfile padrão gerado pelo Visual Studio, a parte do caminho referente ao arquivo no primeiro argumento do comando COPY foi removida para copiar toda a pasta em vez de apenas o arquivo de projeto. Sem essas alterações, esse estágio produz um erro do 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

Problema: credenciais de autenticação

O fluxo de trabalho requer que os segredos de nome de usuário e senha certos sejam configurados para acesso ao Azure. O Visual Studio tenta fazer isso automaticamente quando você está criando os ativos do Azure ou na tela do GitHub Actions no IDE do Microsoft Visual Studio. Você pode verificar os segredos no GitHub e verificar se eles estão lá ou regenere-os e adicioná-los novamente ao GitHub, se necessário, usando a seção Configurações no repositório. Verifique a ID dos segredos em relação ao que é referenciado em cada seção do fluxo de trabalho. Se necessário, você pode acessar o registro de contêiner no portal do Azure e obter o nome de usuário e a senha do registro de contêiner e usar esses valores para atualizar os segredos no GitHub.

Se tiver executado o comando az ad sp create-for-rbac para configurar uma entidade de serviço e obter uma ID de cliente, um segredo de cliente e uma ID de Locatário, adicione a ID do cliente e o segredo do cliente como segredos na seção Segredos do GitHub Actions para o seu repositório do GitHub. Você pode fornecer credenciais de logon do Azure na forma de um nome de usuário (ID do cliente para o aplicativo) e senha (segredo do cliente) para a autenticação do Aplicativo de Contêiner do Azure. Para fazer isso, substitua a etapa Azure login pelo código a seguir. Utilize seus próprios nomes de segredos do GitHub criados para a ID do cliente e o segredo do cliente, e use a ID do Locatário da saída do mesmo comando.

- 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

Se o Dockerfile funcionar corretamente e a autenticação estiver correta e você ainda estiver vendo problemas com seu fluxo de trabalho, considere os seguintes recursos:

• Aplicativos de Contêiner do Azure no GitHub
• Aplicativos de Contêiner do Azure no Stack Overflow

Quais tipos de projeto têm suporte?

• ASP.NET Core
• ASP.NET 5 e superior
• Azure Functions

Quais serviços do Azure têm suporte?

• Aplicativos Web do Azure
• Azure Functions
• Gerenciamento de API do Azure