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 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 utilizando o GitHub Actions

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

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

Dependendo do tipo de projeto, você obtém uma lista diferente de 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.

Se você concluir essa etapa usando as ferramentas internas do Git, o Visual Studio detectará a execução do fluxo de trabalho.

Definir os segredos do GitHub

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

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 avisará você 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 manual ao segredo, para que você possa concluir o processo por meio da página do repositório no Github.com.

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

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

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

   

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 dos Aplicativos de Contêiner do Azure existentes ou selecione Criar.

   

   Ao criar um, você verá esta 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êineres é 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. Consulte Ambientes do Aplicativos de Contêiner do Azure. Se você não souber o que é isso ou não tiver criado um antes, crie um para essa instância.

   

   Uma vez criada, a nova instância do 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 novo.

   

   Se optar por criar um, você 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, consulte Tipos de serviço do Registro de Contêiner do Azure.

   

   Uma vez criado, o novo registro é mostrado 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 do 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 utilizada, 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 mais tarde 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 no seu repositório do GitHub nos segredos do GitHub Actions. Verifique se há sinais amarelos de aviso. 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 do 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 é único, portanto, muitas vezes é necessário editar manualmente o arquivo YML do fluxo de trabalho gerado pelo Visual Studio para que ele seja executado com êxito. Para abri-lo, expanda o nó 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.

A seguir, mostramos 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 principal função do fluxo de trabalho é entrar nos serviços do Azure Functions com a autenticação correta e executar os comandos para criar e implantar o aplicativo.

Edição e teste do fluxo de trabalho

O procedimento acima gera um arquivo YML de fluxo de trabalho, mas normalmente é necessário revisá-lo e personalizá-lo antes que ele possa ser utilizado em 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 do fluxo de trabalho contém muitos elementos configuráveis, como as definições das 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 utilizando a sintaxe ${{ secrets.SECRET_NAME }}. Consulte Segredos do GitHub Actions.

Se seus projetos não estiverem localizados na raiz do repositório, será necessário alterar o fluxo de trabalho para especificar o caminho para encontrar 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

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

- 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 que o Visual Studio gera contém um gatilho que faz com que ele seja executado se for atualizado em uma ramificação especificada. 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 PRs (solicitações de pull). 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 utilizando 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 seu 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 compilação não funcionará como no Visual Studio. O Dockerfile padrão que o Visual Studio gera para um projeto demonstra esse problema. Considere as seguintes modificações no estágio de compilação se você tiver um Dockerfile desse tipo. Aqui está um exemplo em que um projeto estava 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 é anexado aqui para criar a pasta de compilação e, em vez de copiar apenas o arquivo do projeto, a pasta inteira é copiada. Em comparação com o Dockerfile padrão gerado pelo Visual Studio, a parte do arquivo do caminho no primeiro argumento do comando COPY foi removida, de modo que estamos copiando a pasta inteira em vez de apenas o arquivo do projeto. Sem essas alterações, essa fase produz um erro de 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 exige que os segredos corretos de nome de usuário e senha sejam configurados para o acesso ao Azure. O Visual Studio tenta fazer isso automaticamente quando você está criando os ativos do Azure ou na tela GitHub Actions no IDE do Microsoft Visual Studio. Você pode verificar os segredos no GitHub e verificar se eles existem, ou regenerá-los e adicioná-los novamente ao GitHub, se necessário, utilizando 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ê poderá acessar o registro de contêineres no portal do Microsoft Azure e obter o nome de usuário e a senha do registro de contêineres e utilizar 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 Aplicativos 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 tendo problemas para seu fluxo de trabalho, considere os seguintes recursos:

• Aplicativos de Contêiner do Azure no GitHub
• Aplicativos de Contêiner do Azure no StackOverflow

Quais tipos de projeto têm suporte?

• ASP.NET Core
• ASP.NET 5 e superior
• Funções do Azure

Quais serviços do Azure têm suporte?

• Aplicativos Web do Azure
• Funções do Azure
• Gerenciamento de API do Azure