Partilhar via


Melhores Práticas de Implementação

Nota

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

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

Para obter mais detalhes, consulte Nome de host padrão exclusivo para recurso do 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 no Serviço de Aplicativo: fontes de implantação, pipelines de compilação e mecanismos de implantação. Este artigo também aborda algumas práticas recomendadas e dicas para pilhas de idiomas específicos.

Componentes de implantação

Origem da implantação

Uma fonte de implantação é o local do código do aplicativo. Para aplicativos de produção, a fonte de implantação geralmente é um repositório hospedado por software de controle de versão, como GitHub, BitBucket ou Azure Repos. Para cenários de desenvolvimento e teste, a fonte de implantação pode ser um projeto em sua máquina local.

Pipeline de Compilação

Depois de decidir sobre uma fonte de implantação, sua próxima etapa é escolher um pipeline de compilação. Um pipeline de compilação lê seu código-fonte da fonte de implantação e executa uma série de etapas (como compilar código, reduzir HTML e JavaScript, executar testes e empacotar componentes) para colocar o aplicativo em um estado executável. Os comandos específicos executados pelo pipeline de compilação dependem da sua pilha de idiomas. Essas operações podem ser executadas em um servidor de compilação, como o Azure Pipelines, ou executadas localmente.

Mecanismo de implantação

O mecanismo de implantação é a ação usada para colocar seu aplicativo criado 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 seu aplicativo Web. Quando o mecanismo de implantação coloca seu aplicativo nesse diretório, suas instâncias recebem uma notificação para sincronizar os novos arquivos. O Serviço de Aplicativo oferece suporte aos seguintes mecanismos de implantação:

  • Pontos de extremidade Kudu: Kudu é a ferramenta de produtividade do desenvolvedor de código aberto que é executada como um processo separado no Serviço de Aplicativo do Windows e como um segundo contêiner no Serviço de Aplicativo Linux. O Kudu lida com implantações contínuas e fornece pontos de extremidade HTTP para implantação, como zipdeploy/.
  • FTP e WebDeploy: Usando seu site ou credenciais de usuário, você pode carregar arquivos via FTP ou WebDeploy. Esses mecanismos não passam pelo Kudu.

Ferramentas de implantação como Azure Pipelines, Jenkins e plug-ins de editor usam um desses mecanismos de implantação.

Usar slots de implantação

Sempre que possível, use slots de implantação ao implantar uma nova compilação de produção. Ao usar uma camada do Plano de Serviço de Aplicativo Padrão ou superior, você pode implantar seu aplicativo em um ambiente de preparação, validar suas alterações e fazer testes de fumaça. Quando estiver pronto, você pode trocar seus slots de preparação e produção. A operação de permuta aquece as instâncias de trabalho necessárias para corresponder à sua escala de produção, eliminando assim o tempo de inatividade.

Implante código continuamente

Se o seu projeto tiver ramificações designadas para teste, controle de qualidade e preparação, cada uma dessas ramificações deverá ser implantada continuamente em um slot de preparação. (Isto é conhecido como o Design do Gitflow.) Isso permite que as partes interessadas avaliem e testem facilmente a ramificação implantada.

A implantação contínua nunca deve ser habilitada para seu slot de produção. Em vez disso, sua ramificação de produção (geralmente principal) deve ser implantada em um slot que não seja de produção. Quando estiver pronto para liberar a ramificação base, troque-a para o slot de produção. A troca 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 as ramificações Dev, Preparo e Principal e os slots nos quais elas são implantadas.

Implante contêineres continuamente

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

Para cada ramificação que você deseja implantar em um slot, configure a automação para fazer o seguinte em cada confirmação na ramificação.

  1. Crie e marque a imagem. Como parte do pipeline de compilação, marque a imagem com o ID de confirmação do git, carimbo de data/hora ou outras informações identificáveis. É melhor não usar a tag padrão "mais recente". Caso contrário, é difícil rastrear qual código está implantado atualmente, o que torna a depuração muito mais difícil.
  2. Empurre a imagem marcada. Depois que a imagem é criada e marcada, o pipeline envia a imagem para nosso registro de contêiner. Na próxima etapa, o slot de implantação extrairá a imagem marcada do registro do contêiner.
  3. Atualize o slot de implantação com a nova tag de imagem. Quando essa propriedade é atualizada, o site será reiniciado automaticamente e puxará a nova imagem de contêiner.

Visual de utilização da ranhura

Há exemplos abaixo 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 do Centro 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 seu repositório e ramificação. Isso configurará um pipeline de compilação e liberação de DevOps para criar, marcar e implantar automaticamente seu contêiner quando novas confirmações forem enviadas por push para a ramificação selecionada.

Usar ações do GitHub

Você também pode automatizar sua implantação de contêiner com o GitHub Actions. O arquivo de fluxo de trabalho abaixo criará e marcará o contêiner com a ID de confirmação, enviá-lo-á por push para um registro de contêiner e atualizará o aplicativo Web especificado com a nova tag 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 CircleCI ou Travis CI. No entanto, você precisa usar a CLI do Azure para atualizar os slots de implantação com 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

No script, entre usando az login --service-principal, fornecendo as informações da entidade de segurança. Em seguida, 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 você construir seu processo de CI de contêiner.

Considerações específicas do idioma

Java

Use o Kudu zipdeploy/ API para implantar aplicativos JAR e wardeploy/ para aplicativos WAR. Se você estiver usando o Jenkins, poderá usar essas APIs diretamente na fase de implantação. Para mais informações, consulte este artigo.

Por padrão, o Kudu executa as etapas de compilação para seu aplicativo Node (npm install). Se você estiver usando um serviço de compilação, como o Azure DevOps, a compilação do Kudu será desnecessária. Para desativar a compilação 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 compilação para seu aplicativo .NET (dotnet build). Se você estiver usando um serviço de compilação, como o Azure DevOps, a compilação do Kudu será desnecessária. Para desativar a compilação 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 Azure e é exibido de maneira durável como um compartilhamento de conteúdo. No entanto, alguns aplicativos precisam apenas de um armazenamento de conteúdo somente leitura de alto desempenho que possam 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 em conjunto com slots de implantação para evitar tempo de inatividade. Consulte esta seção para obter informações sobre como usar esses recursos juntos.

CPU ou Memória Elevada

Se o seu Plano do Serviço de Aplicativo estiver usando mais de 90% da CPU ou memória disponível, a máquina virtual subjacente poderá ter problemas para processar sua implantação. Quando isso acontecer, aumente temporariamente a contagem de instâncias para executar a implantação. Quando a implantação for concluída, você poderá retornar a contagem de instâncias ao seu valor anterior.

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

  • Navegue até seu Aplicativo Web no portal do Azure.
  • Selecione Diagnosticar e resolver problemas na navegação à esquerda, que abre o Diagnóstico do Serviço de Aplicativo.
  • Escolha o bloco da página inicial Práticas recomendadas.
  • Selecione Práticas recomendadas para disponibilidade & desempenho ou práticas recomendadas para configuração ideal para exibir o estado atual do seu aplicativo em relação a essas práticas recomendadas.

Você também pode usar este link para abrir diretamente o Diagnóstico do Serviço de Aplicativo para seu 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