Melhores práticas de implantação

Artigo
06/04/2024

Observação

A partir de 1º de junho de 2024, todos os aplicativos recém-criados do Serviço de Aplicativo terão a opção de gerar um nome do host padrão exclusivo usando a convenção de nomenclatura <app-name>-<random-hash>.<region>.azurewebsites.net. Os nomes de aplicativos existentes permanecerão inalterados.

Exemplo: myapp-ds27dh7271aah175.westus-01.azurewebsites.net

Para obter mais detalhes, consulte Nome do Host Padrão Exclusivo para o Recurso Serviço de Aplicativo.

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

Origem da 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 (como compilar código, minificar HTML e JavaScript, executar testes e empacotar componentes) para obter o aplicativo em um status executável. Os comandos específicos executados pelo pipeline de build dependem da pilha de linguagem. Essas operações podem ser executadas em um servidor de build, como Azure Pipelines, ou executadas 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 Kudu: o Kudu é a ferramenta de produtividade para desenvolvedores de software livre que é executada como um processo separado no Serviço de Aplicativo do Windows e 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, use os slots de implantação ao implantar um novo build de produção. Ao usar 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, você poderá trocar os slots de preparação e produção. A operação de troca ativa as instâncias de trabalho necessárias para corresponder à escala de produção, eliminando assim 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. (Isso é conhecido como o Design do Gitflow). Ele permite que os stakeholders 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. Trocar para produção, em vez de implantar na produção, evita o tempo de inatividade e permite reverter as alterações trocando novamente.

Diagrama que mostra o fluxo entre o branch principal, o de desenvolvimento e o de preparo e os slots nos quais eles são implantados.

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, pois você deve enviar por push a imagem para um registro de contêiner e atualizar a marca de imagem no webapp.

Para cada branch que você deseja implantar em um slot, configure a automação para fazer os passos a seguir em cada commit com o branch.

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.
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 vai efetuar pull da imagem marcada do registro de contêiner.
Atualize o slot de implantação com a nova marca de imagem. Quando essa propriedade for atualizada, o site vai reiniciar automaticamente e efetuar pull da nova imagem de contêiner.

Objeto visual de uso do slot

Abaixo há exemplos de 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é seu aplicativo no portal do Azure e selecione Centro de Implantação em Implantação. Siga as instruções para selecionar o repositório e o branch. Isso vai configurar 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 abaixo vai criar e marcar 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. Abaixo estão alguns links úteis para construir o processo de CI de contêiner.

Como entrar na CLI do Azure no Circle CI

Considerações específicas a linguagens

Java

Use a API zipdeploy/ do Kudu para implantar aplicativos JAR e a 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 este artigo.

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

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. O cache local não é recomendado para sites de gerenciamento de conteúdo, como o WordPress.

Sempre use o cache local junto com os slots de implantação para evitar o tempo de inatividade. Consulte esta seção para obter informações sobre como usar esses recursos juntos.

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 isso acontece, escale verticalmente de maneira temporária a contagem de instâncias para executar a implantação. Depois que a implantação for concluída, retorne a contagem de instâncias para o valor anterior.

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

Navegue até o seu aplicativo Web no portal do Azure.
Selecione Diagnosticar e resolver problemas no painel de navegação à esquerda, o que abre o Diagnóstico do Serviço de Aplicativo.
Escolha a peça da página inicial de Melhores Práticas.
Selecione Melhores Práticas para Disponibilidade e Desempenho ou Melhores Práticas para a Configuração Ideal para exibir o status atual do aplicativo em relação a essas melhores práticas.

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.

Mais recursos

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

Compartilhar via