Aplicação Web básica

Este artigo fornece uma arquitetura básica destinada a aprender sobre a execução de aplicativos Web no Serviço de Aplicativo do Azure em uma única região.

Arquitetura

Figura 1: Arquitetura básica do Serviço de Aplicativo do Azure

Transfira um ficheiro do Visio desta arquitetura.

Fluxo de Trabalho

1. Um usuário emite uma solicitação HTTPS para o domínio padrão do Serviço de Aplicativo no azurewebsites.net. Este domínio aponta automaticamente para o IP público incorporado do Serviço de Aplicações. A conexão TLS é estabelecida do cliente diretamente para o serviço de aplicativo. O certificado é gerenciado completamente pelo Azure.
2. O Easy Auth, um recurso do Serviço de Aplicativo do Azure, garante que o usuário que acessa o site seja autenticado com a ID do Microsoft Entra.
3. O código do aplicativo implantado no Serviço de Aplicativo lida com a solicitação. Por exemplo, esse código pode se conectar a uma instância do Banco de Dados SQL do Azure, usando uma cadeia de conexão configurada no Serviço de Aplicativo configurada como uma configuração de aplicativo.
4. As informações sobre a solicitação original para o Serviço de Aplicativo e a chamada para o Banco de Dados SQL do Azure são registradas no Application Insights.

Componentes

• O Microsoft Entra ID é um serviço de gerenciamento de identidade e acesso baseado em nuvem. Ele fornece um único plano de controle de identidade para gerenciar permissões e funções para usuários que acessam seu aplicativo Web. Ele se integra ao Serviço de Aplicativo e simplifica a autenticação e a autorização para aplicativos Web.
• O Serviço de Aplicativo é uma plataforma totalmente gerenciada para criar, implantar e dimensionar aplicativos Web.
• O Azure Monitor é um serviço de monitoramento que coleta, analisa e atua em dados de telemetria em toda a sua implantação.
• O Banco de Dados SQL do Azure é um serviço de banco de dados relacional gerenciado para dados relacionais.

Recomendações e considerações

Os componentes listados nesta arquitetura vinculam-se aos guias de serviço do Azure Well-Architected. Os guias de serviço detalham recomendações e considerações para serviços específicos. Esta seção estende essa orientação destacando as principais recomendações e considerações do Azure Well-Architected Framework que se aplicam a essa arquitetura. Para obter mais informações, consulte Microsoft Azure Well-Architected Framework.

Essa arquitetura básica não se destina a implantações de produção. A arquitetura favorece a simplicidade e a eficiência de custos em detrimento da funcionalidade para permitir que você avalie e aprenda o Serviço de Aplicativo do Azure. As seções a seguir descrevem algumas deficiências dessa arquitetura básica, juntamente com recomendações e considerações.

Fiabilidade

A confiabilidade garante que seu aplicativo possa atender aos compromissos que você assume com seus clientes. Para obter mais informações, consulte Lista de verificação de revisão de design para confiabilidade.

Como essa arquitetura não foi projetada para implantações de produção, o seguinte descreve alguns dos recursos críticos de confiabilidade que são omitidos nessa arquitetura:

• O Plano do Serviço de Aplicativo está configurado para a Standard camada, que não tem suporte à zona de disponibilidade do Azure. O Serviço de Aplicativo fica indisponível no caso de qualquer problema com a instância, o rack ou o datacenter que hospeda a instância.
• O Banco de Dados SQL do Azure está configurado para a Basic camada, que não oferece suporte à redundância de zona. Isso significa que os dados não são replicados nas zonas de disponibilidade do Azure, correndo o risco de perda de dados comprometidos no caso de uma interrupção.
• As implantações nessa arquitetura podem resultar em tempo de inatividade com implantações de aplicativos, já que a maioria das técnicas de implantação exige que todas as instâncias em execução sejam reiniciadas. Os usuários podem experimentar erros 503 durante este processo. Isso é abordado na arquitetura de linha de base por meio de slots de implantação. O design cuidadoso do aplicativo, o gerenciamento do esquema e o tratamento da configuração do aplicativo são necessários para dar suporte à implantação simultânea de slots. Use este POC para projetar e validar sua abordagem de implantação de produção baseada em slots.
• O dimensionamento automático não está habilitado nesta arquitetura básica. Para evitar problemas de confiabilidade devido à falta de recursos de computação disponíveis, você precisaria provisionar demais para sempre executar com computação suficiente para lidar com a capacidade máxima simultânea.

Veja como superar essas preocupações de confiabilidade na seção de confiabilidade no aplicativo Web redundante de zona altamente disponível Linha de base.

Se essa carga de trabalho eventualmente exigir uma arquitetura ativa-ativa ou ativa-passiva de várias regiões, consulte Aplicativo Web multirregião altamente disponível para obter orientação sobre como implantar sua carga de trabalho hospedada pelo Serviço de Aplicativo em várias regiões.

Segurança

A segurança oferece garantias contra ataques deliberados e o abuso de seus valiosos dados e sistemas. Para obter mais informações, consulte Lista de verificação de revisão de design para segurança.

Como essa arquitetura não foi projetada para implantações de produção, o seguinte descreve alguns dos recursos de segurança críticos que foram omitidos nessa arquitetura, juntamente com outras recomendações e considerações de confiabilidade:

• Esta arquitetura básica não implementa a privacidade da rede. Os dados e os planos de gerenciamento para os recursos, como o Serviço de Aplicativo do Azure e o SQL Server do Azure, podem ser acessados pela Internet pública. Omitir a rede privada aumenta significativamente a superfície de ataque da sua arquitetura. Para ver como a implementação da rede privada garante os seguintes recursos de segurança, consulte a seção de rede do aplicativo Web com redundância de zona altamente disponível da linha de base:

  • Um único ponto de entrada seguro para o tráfego de clientes
  • O tráfego de rede é filtrado no nível do pacote e no nível DDoS.
  • A exfiltração de dados é minimizada mantendo o tráfego no Azure usando o Private Link
  • Os recursos de rede são logicamente agrupados e isolados uns dos outros através da segmentação de rede.

• Essa arquitetura básica não inclui uma implantação do Firewall de Aplicativo Web do Azure. O aplicativo Web não está protegido contra exploits e vulnerabilidades comuns. Consulte a implementação da linha de base para ver como o Firewall de Aplicativo Web pode ser implementado com o Gateway de Aplicativo do Azure em uma arquitetura dos Serviços de Aplicativo do Azure.

• Essa arquitetura básica armazena segredos como a cadeia de conexão do SQL Server do Azure nas Configurações do Aplicativo. Embora as configurações do aplicativo sejam criptografadas, ao passar para a produção, considere armazenar segredos no Cofre de Chaves do Azure para aumentar a governança. Uma solução ainda melhor é usar a identidade gerenciada para autenticação e não ter segredos armazenados na cadeia de conexão.

• Deixar a depuração remota e os endpoints Kudu ativados durante o desenvolvimento ou a fase de prova de conceito é bom. Ao passar para a produção, você deve desabilitar o plano de controle, a implantação ou o acesso remoto desnecessários.

• Deixar os métodos de autenticação local para implantações de site FTP e SCM habilitados é bom durante a fase de desenvolvimento ou prova de conceito. Ao passar para a produção, você deve desabilitar a autenticação local para esses pontos de extremidade.

• Não é necessário habilitar o Microsoft Defender para Serviço de Aplicativo na fase de prova de conceito. Ao passar para a produção, você deve habilitar o Defender for App Service para gerar recomendações de segurança que você deve implementar para aumentar sua postura de segurança e detetar várias ameaças ao seu Serviço de Aplicativo.

• O Serviço de Aplicativo do Azure inclui um ponto de extremidade SSL em um subdomínio sem azurewebsites.net custo extra. As solicitações HTTP são redirecionadas para o ponto de extremidade HTTPS por padrão. Para implantações de produção, você normalmente usará um domínio personalizado associado ao gateway de aplicativo ou ao gerenciamento de API na frente da implantação do Serviço de Aplicativo.

• Use o mecanismo de autenticação integrado para o Serviço de Aplicativo ("EasyAuth"). O EasyAuth simplifica o processo de integração de provedores de identidade em seu aplicativo Web. Ele lida com a autenticação fora do seu aplicativo Web, para que você não precise fazer alterações significativas no código.

• Use a identidade gerenciada para identidades de carga de trabalho. A identidade gerenciada elimina a necessidade de os desenvolvedores gerenciarem credenciais de autenticação. A arquitetura básica é autenticada no SQL Server por meio de senha em uma cadeia de conexão. Considere usar a identidade gerenciada para autenticar no SQL Server do Azure.

Para obter algumas outras considerações de segurança, consulte Proteger um aplicativo no Serviço de Aplicativo do Azure.

Excelência operacional

A excelência operacional abrange os processos operacionais que implantam um aplicativo e o mantêm em execução na produção. Para obter mais informações, consulte Lista de verificação de revisão de design para excelência operacional.

As seções a seguir fornecem orientação sobre configuração, monitoramento e implantação do seu aplicativo do Serviço de Aplicativo.

Configurações do aplicativo

Como a arquitetura básica não se destina à produção, ela usa a configuração do Serviço de Aplicativo para armazenar valores e segredos de configuração. Armazenar segredos na configuração do Serviço de Aplicativo é bom para a fase PoC. Você não está usando segredos reais e não precisa de governança de segredos que as cargas de trabalho de produção exigem.

A seguir estão as recomendações e considerações de configuração:

• Comece usando a configuração do Serviço de Aplicativo para armazenar valores de configuração e cadeias de conexão em implantações de prova de conceito. As definições da aplicação e as cadeias de ligação são encriptadas e desencriptadas imediatamente antes de serem injetadas na sua aplicação quando esta é iniciada.
• Quando passar para a fase de produção, armazene os seus segredos no Azure Key Vault. O uso do Azure Key Vault melhora a governança de segredos de duas maneiras:
  • Externalizar o armazenamento de segredos para o Cofre de Chaves do Azure permite centralizar o armazenamento de segredos. Você tem um lugar para gerenciar segredos.
  • Usando o Cofre de Chaves do Azure, você pode registrar todas as interações com segredos, inclusive sempre que um segredo é acessado.
• Ao entrar em produção, você pode manter o uso da configuração do Cofre da Chave do Azure e do Serviço de Aplicativo usando referências do Cofre da Chave.

Diagnóstico e monitorização

Durante a fase de prova de conceito, é importante entender quais logs e métricas estão disponíveis para serem capturados. Seguem-se recomendações e considerações para monitorização na fase de prova de conceito:

• Habilite o log de diagnóstico para todas as fontes de log de itens. Definir o uso de todas as configurações de diagnóstico ajuda você a entender quais logs e métricas são fornecidos para você imediatamente e quaisquer lacunas que você precisará fechar usando uma estrutura de log no código do aplicativo. Ao passar para a produção, você deve eliminar as fontes de log que não estão agregando valor e estão adicionando ruído e custo ao coletor de logs da carga de trabalho.
• Configure o registo para utilizar o Azure Log Analytics. O Azure Log Analytics fornece uma plataforma escalável para centralizar o registo que é fácil de consultar.
• Use o Application Insights ou outra ferramenta de Gerenciamento de Desempenho de Aplicativo (APM) para emitir telemetria e logs para monitorar o desempenho do aplicativo.

Implementação

A lista a seguir lista as diretrizes sobre a implantação do seu aplicativo do Serviço de Aplicativo.

• Siga as orientações em CI/CD para Aplicativos Web do Azure com Pipelines do Azure para automatizar a implantação do seu aplicativo. Comece a criar sua lógica de implantação na fase PoC. A implementação de CI/CD no início do processo de desenvolvimento permite que você itere seu aplicativo de forma rápida e segura à medida que avança para a produção.
• Use modelos ARM para implantar recursos do Azure e suas dependências. É importante iniciar este processo na fase PoC. À medida que avança para a produção, você quer a capacidade de implantar automaticamente sua infraestrutura.
• Use diferentes modelos ARM e integre-os aos serviços de DevOps do Azure. Esta configuração permite-lhe criar ambientes diferentes. Por exemplo, você pode replicar cenários semelhantes aos de produção ou ambientes de teste de carga somente quando necessário e economizar custos.

Para obter mais informações, consulte a seção DevOps no Azure Well-Architected Framework.

Contentores

A arquitetura básica pode ser usada para implantar o código suportado diretamente em instâncias do Windows ou Linux. Como alternativa, o Serviço de Aplicativo também é uma plataforma de hospedagem de contêiner para executar seu aplicativo Web em contêiner. O Serviço de Aplicativo oferece vários contêineres integrados. Se você estiver usando aplicativos personalizados ou de vários contêineres para ajustar ainda mais seu ambiente de tempo de execução ou para oferecer suporte a uma linguagem de código sem suporte nativo, será necessário introduzir um registro de contêiner.

Plano de controlo

Durante a fase POC, sinta-se confortável com o plano de controle do Serviço de Aplicativo do Azure, conforme exposto por meio do serviço Kudu. Este serviço expõe APIs de implantação comuns, como implantações ZIP, expõe logs brutos e variáveis de ambiente.

Se estiver usando contêineres, certifique-se de entender a capacidade do Kudu de abrir uma sessão SSH em um contêiner para oferecer suporte a recursos avançados de depuração.

Eficiência de desempenho

Eficiência de desempenho é a capacidade da sua carga de trabalho para dimensionar para satisfazer as exigências que os utilizadores lhe colocam de forma eficiente. Para obter mais informações, consulte Lista de verificação de revisão de projeto para eficiência de desempenho.

Como essa arquitetura não foi projetada para implantações de produção, a seguir descrevemos alguns dos recursos críticos de eficiência de desempenho que foram omitidos nessa arquitetura, juntamente com outras recomendações e considerações.

Um resultado da sua prova de conceito deve ser a seleção de SKU que você estima ser adequada para sua carga de trabalho. Sua carga de trabalho deve ser projetada para atender com eficiência à demanda por meio de dimensionamento horizontal, ajustando o número de instâncias de computação implantadas no Plano do Serviço de Aplicativo. Não projete o sistema para depender da alteração da SKU de computação para se alinhar com a demanda.

• O Serviço de Aplicativo nessa arquitetura básica não tem o dimensionamento automático implementado. O serviço não é dimensionado dinamicamente para se manter alinhado com a demanda de forma eficiente.
  • A camada Standard oferece suporte a configurações de dimensionamento automático para permitir que você configure o dimensionamento automático baseado em regras. Parte do seu processo POC deve ser chegar a configurações eficientes de dimensionamento automático com base nas necessidades de recursos do código do aplicativo e nas características de uso esperadas.
  • Para implantações de produção, considere camadas Premium que oferecem suporte ao dimensionamento automático automático , em que a plataforma lida automaticamente com decisões de dimensionamento.
• Siga as orientações para dimensionar bancos de dados individuais sem tempo de inatividade do aplicativo se precisar de uma camada de serviço ou nível de desempenho mais alto para o Banco de dados SQL.

Implementar este cenário

A orientação é apoiada por um exemplo de implementação que mostra uma implementação básica do Serviço de Aplicativo no Azure.

Próximos passos

Recursos relacionados

• Aplicativo Web redundante de zona de linha de base
• Aplicação Web multi-região altamente disponível

Documentação do produto:

• Descrição geral do Serviço de Aplicações
• Descrição geral do Azure Monitor
• Descrição Geral do plano do Serviço de Aplicações do Azure
• Descrição geral do Log Analytics no Azure Monitor
• O que é o Microsoft Entra ID?
• O que é a Base de Dados SQL do Azure?

Módulos do Microsoft Learn:

• Configurar e gerenciar o Azure Monitor
• Configurar o Microsoft Entra ID
• Configurar o Azure Monitor
• Implantar e configurar servidores, instâncias e bancos de dados para o SQL do Azure
• Explore o Serviço de Aplicativo do Azure
• Hospedar um aplicativo Web com o Serviço de Aplicativo do Azure
• Hospedar seu domínio no DNS do Azure
• Implementar o Azure Key Vault
• Gerenciar usuários e grupos no Microsoft Entra ID