Melhores práticas de implantação

Cada equipe de desenvolvimento tem requisitos exclusivos que podem dificultar a implementação de um pipeline de implantação eficiente em qualquer serviço de nuvem. Este artigo apresenta os três principais componentes da implantação para o Serviço de Aplicativo do Azure: origens da implantação, pipelines de build e mecanismos de implantação. Este artigo também aborda algumas melhores práticas e dicas para pilhas de linguagem específicas.

Componentes de implantação

Esta seção descreve os três componentes principais para implantação no Serviço de Aplicativo.

Fonte de implantação

A origem da implantação é o local do código do aplicativo. Para aplicativos de produção, a origem da implantação geralmente é um repositório hospedado pelo software de controle de versão, como o GitHub, o BitBucket ou o Azure Repos. Para cenários de desenvolvimento e teste, a origem da implantação pode ser um projeto em seu computador local.

Pipeline de build

Depois de decidir sobre a origem da implantação, a próxima etapa é escolher um pipeline de build. Um pipeline de build lê o código-fonte da origem da implantação e executa uma série de etapas para obter o aplicativo em um estado executável.

As etapas podem incluir compilar código, minificar HTML e JavaScript, executar testes e empacotar componentes. Os comandos específicos executados pelo pipeline de build dependem da pilha de linguagem. Você pode executar essas operações em um servidor de build, como o Azure Pipelines, ou localmente.

Mecanismo de implantação

O mecanismo de implantação é a ação usada para colocar seu aplicativo interno no diretório /home/site/wwwroot do seu aplicativo Web. O diretório /wwwroot é um local de armazenamento montado compartilhado por todas as instâncias do aplicativo Web. Quando o mecanismo de implantação coloca seu aplicativo nesse diretório, as instâncias recebem uma notificação para sincronizar os novos arquivos.

O Serviço de Aplicativo dá suporte às seguintes opções de implantação:

• Pontos de extremidade do Kudu: Kudu é a ferramenta de produtividade do desenvolvedor de software livre que é executada como um processo separado no Serviço de Windows App. Ela é executada como um segundo contêiner no Serviço de Aplicativo do Linux. O Kudu lida com implantações contínuas e fornece pontos de extremidade HTTP para implantação, como o zipdeploy/.
• FTP e WebDeploy: usando suas credenciais de site ou de usuário, é possível carregar arquivos via FTP ou WebDeploy. Esses mecanismos não passam pelo Kudu.

As ferramentas de implantação, como o Azure Pipelines, o Jenkins e os plugins de editor usam um desses mecanismos de implantação.

Usar slots de implantação

Sempre que possível, ao implantar um novo build de produção, use slots de implantação. Com uma camada de Plano do Serviço de Aplicativo Padrão ou melhor, você pode implantar seu aplicativo em um ambiente de preparo, validar suas alterações e fazer teste de aceitação do build. Quando estiver pronto, troque os slots de preparo e produção. A operação de troca ativa as instâncias de trabalho necessárias para corresponder à escala de produção, o que elimina o tempo de inatividade.

Código de implantação contínua

Se o projeto tiver branches designados para teste, garantia de qualidade e de preparo, cada um desses branches deverá ser implantado continuamente em um slot de preparo. Essa abordagem é conhecida como o design do Gitflow. Esse design permite que seus participantes avaliem e testem facilmente o branch implantado.

A implantação contínua nunca deve ser habilitada para o slot de produção. Em vez disso, seu branch de produção (geralmente a principal) deve ser implantado em um slot de não produção. Quando estiver pronto para liberar o branch de base, troque-o no slot de produção. A troca para produção, em vez da implantação na produção, evita o tempo de inatividade e permite reverter as alterações trocando novamente.

Contêineres de implantação contínua

Para contêineres personalizados do Docker ou de outros registros de contêiner, implante a imagem em um slot de preparo e troque para o de produção para evitar o tempo de inatividade. A automação é mais complexa do que a implantação de código. Você deve enviar a imagem por push para um registro de contêiner e atualizar a marca de imagem no aplicativo Web.

Para cada branch que você deseja implantar em um slot, configure a automação para executar essas tarefas em cada confirmação no branch.

1. Crie e marque a imagem. Como parte do pipeline de build, marque a imagem com a ID de git commit, o carimbo de data/hora ou outras informações de identificação. É melhor não usar a marca padrão mais recente. Caso contrário, é difícil fazer o rastreamento do código que está implantado no momento, o que torna a depuração muito mais difícil.
2. Envie por push a imagem marcada. Depois que a imagem é criada e marcada, o pipeline a envia por push para o registro de contêiner. Na próxima etapa, o slot de implantação efetua pull da imagem marcada do registro de contêiner.
3. Atualize o slot de implantação com a nova marca de imagem. Quando essa propriedade é atualizada, o site reinicia e puxa automaticamente a nova imagem de contêiner.

Este artigo contém exemplos para estruturas de automação comuns.

Usar o Azure DevOps

O Serviço de Aplicativo tem entrega contínua interna para contêineres por meio da Central de Implantação. Navegue até o seu aplicativo no portal do Azure. Em Implantação, selecione Centro de Implantação. Siga as instruções para selecionar o repositório e o branch. Essa abordagem configura um pipeline de lançamento e de build do DevOps para criar, marcar e implantar automaticamente o contêiner quando novas confirmações forem enviadas por push para o branch selecionado.

Usar o GitHub Actions

Você também pode automatizar a implantação de contêiner com o GitHub Actions. O arquivo de fluxo de trabalho cria e marca o contêiner com a ID de commit, enviar por push a um registro de contêiner e atualizar o aplicativo Web especificado com a nova marca de imagem.

on:
  push:
    branches:
    - <your-branch-name>

name: Linux_Container_Node_Workflow

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
    # checkout the repo
    - name: 'Checkout GitHub Action'
      uses: actions/checkout@main

    - uses: azure/docker-login@v1
      with:
        login-server: contoso.azurecr.io
        username: ${{ secrets.REGISTRY_USERNAME }}
        password: ${{ secrets.REGISTRY_PASSWORD }}

    - run: |
        docker build . -t contoso.azurecr.io/nodejssampleapp:${{ github.sha }}
        docker push contoso.azurecr.io/nodejssampleapp:${{ github.sha }} 

    - uses: azure/webapps-deploy@v2
      with:
        app-name: 'node-rnc'
        publish-profile: ${{ secrets.azureWebAppPublishProfile }}
        images: 'contoso.azurecr.io/nodejssampleapp:${{ github.sha }}'

Usar outros provedores de automação

As etapas listadas anteriormente se aplicam a outros utilitários de automação, como o CircleCI ou o Travis CI. No entanto, você precisa usar a CLI do Azure para atualizar os slots de implantação com as novas marcas de imagem na etapa final. Para usar a CLI do Azure em seu script de automação, gere uma Entidade de Serviço usando o comando a seguir.

az ad sp create-for-rbac --name "myServicePrincipal" --role contributor \
   --scopes /subscriptions/{subscription}/resourceGroups/{resource-group} \
   --sdk-auth

Em seu script, faça logon usando az login --service-principal e fornecendo as informações da entidade de segurança. Você pode usar az webapp config container set para definir o nome do contêiner, a marca, a URL do registro e a senha do registro. Para obter mais informações, consulte Como entrar na CLI do Azure na CI no CircleCI.

Considerações específicas de linguagens

Tenha em mente as seguintes considerações para implementações Java, Node e .NET.

Java

Use a API zipdeploy do Kudu para implantar aplicativos JAR. Use wardeploy para aplicativos WAR. Se você está usando o Jenkins, pode usar essas APIs diretamente na fase de implantação. Para obter mais informações, consulte Implantar no Serviço de Aplicativo do Azure com o Jenkins.

Nó

Por padrão, o Kudu executa as etapas de build para o seu aplicativo do Node (npm install). Se você está usando um serviço de build como o Azure DevOps, o build do Kudu é desnecessário. Para desabilitar o build do Kudu, crie uma configuração de aplicativo SCM_DO_BUILD_DURING_DEPLOYMENT com um valor de false.

.NET

Por padrão, o Kudu executa as etapas de build para o aplicativo .NET (dotnet build). Se você está usando um serviço de build como o Azure DevOps, o build do Kudu é desnecessário. Para desabilitar o build do Kudu, crie uma configuração de aplicativo SCM_DO_BUILD_DURING_DEPLOYMENT com um valor de false.

Outras considerações de implantação

Outras considerações incluem cache local e alta CPU ou memória.

Cache local

O conteúdo do Serviço de Aplicativo do Azure é armazenado no Armazenamento do Microsoft Azure e exibido de forma duradoura como um compartilhamento de conteúdo. No entanto, alguns aplicativos precisam apenas de um repositório de conteúdo somente leitura de alto desempenho que podem ser executados com alta disponibilidade. Esses aplicativos podem se beneficiar do uso do cache local. Para obter mais informações, consulte a visão geral do Cache Local do Serviço de Aplicativo do Azure.

Para evitar o tempo de inatividade, sempre use o cache local com slots de implantação. Para obter informações sobre como usar esses recursos juntos, consulte as Práticas recomendadas.

CPU ou memória altas

Se o Plano do Serviço de Aplicativo estiver usando mais de 90% da memória ou da CPU disponível, a máquina virtual subjacente poderá ter problemas para processar a implantação. Quando essa situação acontecer, escale verticalmente de maneira temporária a contagem de instâncias para executar a implantação. Depois que a implantação é concluída, retorne a contagem de instâncias para o valor anterior.

Para obter mais informações, visite Diagnóstico do Serviço de Aplicativo para as melhores práticas acionáveis específicas ao seu recurso.

1. Navegue até o seu aplicativo Web no portal do Azure.

2. Selecione Diagnosticar e resolver problemas no painel de navegação à esquerda que abre o Diagnóstico do Serviço de Aplicativo.

3. Escolha Disponibilidade e Desempenho ou explore outras opções, como Análise de Alto Uso de CPU.

   Exiba o estado atual do aplicativo em relação a essas práticas recomendadas.

Você também pode usar esse link para abrir diretamente o Diagnóstico do Serviço de Aplicativo para o recurso: https://portal.azure.com/?websitesextension_ext=asd.featurePath%3Ddetectors%2FParentAvailabilityAndPerformance#@microsoft.onmicrosoft.com/resource/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{siteName}/troubleshoot.

Conteúdo relacionado

• Referência de variáveis de ambiente e configurações de aplicativo