Partilhar via

Melhores práticas de implementação

  • Artigo

Nota

A partir de 1º de junho de 2024, os aplicativos do Serviço de Aplicativo recém-criados poderão gerar um nome de host padrão exclusivo que use a convenção <app-name>-<random-hash>.<region>.azurewebsites.netde nomenclatura. Os nomes de aplicativos existentes permanecem inalterados. Por exemplo:

myapp-ds27dh7271aah175.westus-01.azurewebsites.net

Para obter mais informações, 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 do Azure: 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 implementação

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

Origem da implementaçã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 para colocar o aplicativo em um estado executável.

As etapas podem incluir a compilação de código, a redução de HTML e JavaScript, a execução de testes e o empacotamento de componentes. Os comandos específicos executados pelo pipeline de compilação dependem da sua pilha de idiomas. Você pode executar essas operações em um servidor de compilação, como o Azure Pipelines, ou 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. Ele é executado como um segundo contêiner no Linux App Service. 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, ao implantar uma nova compilação de produção, use slots de implantação. Com uma camada de 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, troque 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, o que elimina o tempo de inatividade.

Implante código continuamente

Se 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. Essa abordagem é conhecida como design Gitflow. Esse design 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. 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 executar essas tarefas em cada confirmação para a 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 no momento, o que torna a depuração mais difícil.
  2. Empurre a imagem marcada. Depois que a imagem é criada e marcada, o pipeline envia a imagem para o registro do contêiner. Na próxima etapa, o slot de implantação extrai 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 é reiniciado automaticamente e extrai a nova imagem de contêiner.

O diagrama mostra o uso visual do slot representando o Aplicativo Web, o Registro de Contêiner e as ramificações do repositório.

Este artigo contém 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 do Centro de Implantação. Navegue até seu aplicativo no portal do Azure. Em Implementação, selecione Centro de Implementação. Siga as instruções para selecionar seu repositório e ramificação. Essa abordagem configura um pipeline de compilação e lançamento de DevOps para criar, marcar e implantar automaticamente seu contêiner quando novas confirmações são 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 cria e marca o contêiner com a ID de confirmação, envia-o por push para um registro de contêiner e atualiza 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 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 principais. 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. Para obter mais informações, consulte Como entrar na CLI do Azure no Circle CI.

Considerações específicas do idioma

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

Java

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

Nó

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

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 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. Para obter mais informações, consulte Visão geral do Cache Local do Serviço de Aplicativo do Azure.

Nota

O cache local não é recomendado para sites de gerenciamento de conteúdo, como o WordPress.

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

Alta CPU ou memória

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 essa situação acontecer, aumente temporariamente a contagem de instâncias para executar a implantação. Após a conclusão da implantação, você pode retornar a contagem de instâncias ao seu valor anterior.

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

  1. Navegue até seu Aplicativo Web no portal do Azure.

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

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

    Exiba 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.

Conteúdos relacionados