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 de Ações do GitHub para projetos .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 se inscrever para uma avaliação gratuita.

Implantar um único projeto no Azure usando as Ações do GitHub

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

Na tela seguinte, selecione Azure e escolha Avançar.

Dependendo do seu 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 as ações do GitHub (gera um arquivo yml) e, em seguida, escolha Concluir.

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

Se concluir esta etapa utilizando as ferramentas internas do Git , o Visual Studio detetará a execução do 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 .

Uma implantação bem-sucedida também pode exigir acesso a um service principal .

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

desaparecido

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

Implantar vários projetos em Aplicativos de Contêiner do Azure usando as Ações do GitHub

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 multiprojeto, como aqueles que implementam microsserviços para Aplicativos de Contêiner do Azure ou Serviço Kubernetes do Azure (AKS). Este artigo aborda os Aplicativos de Contêiner do Azure.

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

   

2. Na tela de destino do Fluxo de Trabalho de Ações do GitHub, escolha Azure.

3. Para o destino específico, escolha Aplicativos de Contêiner do Azure. O assistente avança para o ecrã Container App.

   

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

   

   Quando cria um novo, verá este ecrã. 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 gravam logs no mesmo destino de log. Consulte ambientes de Aplicativos de Contêiner do Azure. Se você não sabe o que é isso ou não criou um antes, crie um novo para este exemplo.

   

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

   

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

   

   Se optar por criar um novo, verá este ecrã. Forneça o grupo de recursos, SKU, e escolha a mesma região, se possível, como antes. Para obter informações sobre as SKUs do Azure Container Registry, consulte camadas de serviço do Azure Container Registry.

   

   Uma vez criado, o novo registo mostra-se 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 Azure Container Apps.

   

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, porque você pode tentar novamente a partir da CLI. Não te preocupes demasiado se ocorrer uma falha de autorização nesta fase. Você também pode configurar a autenticação posteriormente no Visual Studio.

8. Quando terminar, 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 do GitHub sob os segredos de Ações do GitHub. Verifique se existem sinais de aviso amarelos. Se alguma das etapas de autenticação falhou durante o processo de criação, você tem 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 seu melhor para gerar um fluxo de trabalho para sua situação, cada aplicativo e repositório é exclusivo, portanto, muitas vezes você precisa editar manualmente o arquivo YML do fluxo de trabalho gerado pelo Visual Studio antes que ele seja executado com êxito. Para abri-lo, expanda o nó Ações do GitHub 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 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 principal função do fluxo de trabalho é entrar nos serviços do Azure com a autenticação correta 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 orientações 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 nomes dos segredos. Você pode ver referências aos locais de seus Dockerfiles, o nome do seu aplicativo de contêiner do Azure, a ramificação no repositório que você usará 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 }}. Consulte os segredos das Ações do GitHub .

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 que o Visual Studio gera contém um gatilho que faz com que ele seja executado se atualizado em uma ramificação especificada. Se você estiver empurrando para a ramificação working, ela deve ser semelhante ao código a seguir:

on:
  push:
  branches:
  - working

Para testar as alterações, confirme-as e faça push para a ramificação do repositório especificado no código de gatilho. Não é necessário criar um pull request (PR). O fluxo de trabalho é executado desde que o gatilho push esteja configurado para a ramificação correta.

Na guia Ações no repositório em GitHub.com, procure a execução do fluxo de trabalho. Você pode chegar lá diretamente usando um link na guia de resumo de ações do GitHub no Visual Studio. No GitHub, você pode abrir o fluxo de trabalho executado 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: a fase de compilação não executa

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 tiver um Dockerfile deste tipo. Aqui está um exemplo em que um projeto foi localizado em docker/ComposeSample/WebApi em um repo. O caminho completo é fornecido porque o contexto 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 apenas copiar o arquivo de projeto, toda a pasta é copiada. Comparado com o Dockerfile padrão gerado pelo Visual Studio, a parte do caminho do arquivo no primeiro argumento do comando COPY foi removida para que estejamos a copiar toda a pasta em vez de apenas o arquivo de projeto. Sem essas alterações, esse estágio produz um erro 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 corretos de nome de usuário e senha sejam configurados para acesso ao Azure. O Visual Studio tenta fazer isso automaticamente quando você está criando os ativos do Azure ou na tela Ações do GitHub no IDE do Microsoft Visual Studio. Você pode verificar os segredos no GitHub e certificar-se de que eles estão lá, ou regenerá-los e adicioná-los novamente ao GitHub, se necessário, usando a seção Configurações no repositório. Verifique o ID dos segredos em relação ao que é referenciado em cada seção do fluxo de trabalho. Se necessário, você pode ir para o registro de contêiner no portal do Azure e obter o nome de usuário e a senha para o registro de contêiner e usar esses valores para atualizar os segredos no GitHub.

Se executaste o comando az ad sp create-for-rbac para configurar um principal de serviço e obter um ID de cliente, segredo de cliente e ID de locatário, adiciona o ID de cliente e o segredo de cliente como segredos na seção dos segredos das Ações do GitHub para o teu 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 os seus próprios nomes secretos do GitHub que criou para o identificador do cliente, o segredo do cliente, e utilize o identificador do locatário a partir 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

Que tipos de projetos são suportados?

• ASP.NET Núcleo
• ASP.NET 5 e superior
• Azure Functions

Quais serviços do Azure são suportados?

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