Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
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 boas práticas e dicas para conjuntos específicos de linguagens de programação.
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 da aplicação. 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 construção
Depois de decidir sobre uma fonte de implantação, a sua próxima etapa é escolher uma linha 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 do seu stack de linguagens. 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 para desenvolvedores de código aberto que se executa como um processo separado no Windows App Service. Ele é executado como um segundo contêiner no Linux App Service. Kudu lida com desdobramentos contínuos e fornece endpoints 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 implementação
Sempre que possível, ao implantar uma nova compilação de produção, use slots de implementaçã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 substituição aquece as instâncias de trabalho necessárias para corresponder à sua escala de produção, eliminando 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. Esta abordagem permite que as suas partes interessadas avaliem e testem facilmente a versão implementada. Para informações sobre estratégias de ramificação, consulte Desenvolvimento Baseado em Troncos ou comparar fluxos de trabalho Git.
A implantação contínua nunca deve ser ativada para o seu espaço 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. Substituir para produção, em vez de implementar na produção, evita interrupção e permite reverter as alterações substituindo novamente.
Implante contêineres continuamente
Para contentores personalizados do Docker ou de outros registos de contentores, implante a imagem em um intervalo de preparação e faça a transição para produção para evitar tempo de paragem. 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 o tag da imagem na aplicação web.
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.
- 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.
- Coloque 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.
- Atualize o slot de implantação com a nova etiqueta de imagem. Quando essa propriedade é atualizada, o site é reiniciado automaticamente e extrai a nova imagem de contêiner.
Este artigo contém exemplos de estruturas de automação comuns.
Usar o Azure DevOps
O App Service tem entrega contínua incorporada para contentores por meio do Centro de Implementaçã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 ficheiro de fluxo de trabalho cria e etiqueta o contêiner com a ID de commit, envia-o para um registo de contêiner e atualiza a aplicação web especificada com a nova etiqueta 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.
Node
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, algumas aplicações precisam apenas de um armazenamento de conteúdo de alto desempenho e somente leitura, que possam operar 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 paragem, use sempre a cache local com slots de implementaçã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 esta situação acontecer, aumente temporariamente o número de instâncias para realizar a implementaçã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.
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 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.