Aplicativo Web básico

Este artigo fornece uma arquitetura básica para aprender como executar 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

Baixe um Arquivo Visio dessa arquitetura.

Workflow

1. Um usuário emite uma solicitação HTTPS para o domínio padrão do Serviço de Aplicativo em azurewebsites.net. Esse domínio aponta automaticamente para o IP interno do Serviço de Aplicativo. A conexão TLS é estabelecida a partir do cliente diretamente para o serviço de aplicativo. O certificado é gerenciado completamente pelo Azure.
2. A Autenticação Fácil, um recurso do Serviço de Aplicativo do Azure, garante que o usuário que acessa o site seja autenticado com o Microsoft Entra ID.
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 ao Banco de Dados SQL do Azure são registradas no Application Insights.

Componentes

• 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 colocar em escala aplicativos Web.
• O Azure Monitor é um serviço de monitoramento que coleta, analisa e atua em dados de telemetria em 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 são vinculados 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 essas diretrizes 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 eficiência de custos em vez da funcionalidade para permitir que você avalie e aprenda sobre 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.

Confiabilidade

A confiabilidade garante que seu aplicativo possa cumprir os 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, a seguir descrevemos alguns dos recursos críticos de confiabilidade que são omitidos nessa arquitetura:

• O Plano do Serviço de Aplicativo está configurado para a camada Standard, 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 camada Basic, que não dá suporte à redundância de zona. Isso significa que os dados não são replicados entre as zonas de disponibilidade do Azure, arriscando a perda de dados confirmados em caso de interrupção.
• As implantações nessa arquitetura podem resultar em tempo de inatividade com implantações de aplicativos, pois a maioria das técnicas de implantação exige que todas as instâncias em execução sejam reiniciadas. Os usuários podem enfrentar erros 503 durante esse processo. Isso é abordado na arquitetura de linha de base por meio de slots de implantação. O design cuidadoso do aplicativo, o gerenciamento de esquema e a manipulação da configuração do aplicativo são necessários para dar suporte à implantação simultânea de slots. Use esta POC para projetar e validar sua abordagem de implantação de produção baseada em slot.
• 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 superprovisionar para 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 confiabilidade no aplicativo Web com redundância de zona altamente disponível da linha de base.

Se essa carga de trabalho eventualmente exigir uma arquitetura ativa-ativa ou ativa-passiva de várias regiões, consulte os seguintes recursos:

• Abordagens de aplicativo do Serviço de Aplicativo de várias regiões para recuperação de desastre para obter diretrizes sobre como implantar sua carga de trabalho hospedada no Serviço de Aplicativo em várias regiões.
• Aplicativo Web multirregional altamente disponível para uma arquitetura de referência que segue uma abordagem ativa-passiva.

Segurança

A segurança fornece garantias contra ataques deliberados e o abuso de seus dados e sistemas valiosos. 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, a seguir descrevemos alguns dos recursos críticos de segurança que foram omitidos nessa arquitetura, juntamente com outras recomendações e considerações de confiabilidade:

• Essa arquitetura básica não implementa a privacidade da rede. Os planos de dados e gerenciamento dos 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 de 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 cliente.
  • O tráfego de rede é filtrado no nível do pacote e no nível do DDoS.
  • A exfiltração de dados é minimizada mantendo o tráfego no Azure usando link privado
  • Os recursos de rede sejam agrupados e isolados de maneira lógica uns dos outros por meio 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 explorações e vulnerabilidades comuns. Consulte a implementação de 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 Azure Key Vault 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 pontos de extremidade do 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 sites FTP e SCM ativados é 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.

• Você não precisa 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 para Serviço de Aplicativo para gerar recomendações de segurança a serem implementadas para aumentar sua postura de segurança e detectar várias ameaças ao Serviço de Aplicativo.

• Um Serviço de Aplicativo do Azure inclui um ponto de extremidade SSL em um subdomínio do azurewebsites.net sem custo adicional. 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 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 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 de operações 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 diretrizes sobre configuração, monitoramento e implantação do aplicativo Serviço de Aplicativo.

Configuração de 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 de configuração e segredos. Armazenar segredos na configuração do Serviço de Aplicativo é útil para a fase de PoC. Você não está usando segredos reais e não exige a governança de segredos que as cargas de trabalho de produção exigem.

Veja a seguir 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 configurações do aplicativo e as cadeias de conexão são criptografadas e descriptografadas antes de serem injetadas no seu aplicativo quando ele é iniciado.
• Ao passar para a fase de produção, armazene 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 Azure Key Vault permite centralizar o armazenamento de segredos. Você tem um lugar para gerenciar segredos.
  • Usando o Azure Key Vault, você pode registrar todas as interações com segredos, inclusive sempre que um segredo é acessado.
• Ao passar para a produção, você pode manter o uso da configuração do Azure Key Vault e do Serviço de Aplicativo usando referências do Key Vault.

Diagnóstico e monitoramento

Durante a fase de prova de conceito, é importante entender quais logs e métricas estão disponíveis para serem capturados. A seguir estão as recomendações e considerações para monitoramento 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 prontos para usar e quaisquer lacunas que você precisará preencher utilizando uma estrutura de registros no código do aplicativo. Ao passar para a produção, você deve eliminar as fontes de log que não agregam valor e adicionam ruído e custo ao coletor de log da carga de trabalho.
• Configure o registro em log para usar o Azure Log Analytics. O Azure Log Analytics fornece uma plataforma escalonável para centralizar o registro em log que é fácil de consultar.
• Use o Application Insights ou outra ferramenta de APM (Gerenciamento de Desempenho de Aplicativos) para emitir telemetria e logs a fim de monitorar o desempenho do aplicativo.

Implantação

Veja a seguir uma lista de diretrizes sobre como implantar seu aplicativo Serviço de Aplicativo.

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

Para obter mais informações, confira a seção de DevOps em Azure Well-Architected Framework.

Contêineres

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

Painel de controle

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

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

Eficiência de desempenho

A eficiência do desempenho é a capacidade de dimensionar a carga de trabalho para atender às demandas exigidas pelos usuários de maneira eficiente. Para obter mais informações, consulte Lista de verificação de revisão de design 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 para eficiência de performance que foram omitidos nessa arquitetura, juntamente com outras recomendações e considerações de confiabilidade.

Um resultado de sua prova de conceito deve ser a seleção de SKU que você acha ser adequada para sua carga de trabalho. Sua carga de trabalho deve ser projetada para atender com eficiência à demanda por meio do 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 precisar de uma alteração de SKU de computação para se alinhar à demanda.

• O Serviço de Aplicativo nessa arquitetura básica não suporta dimensionamento automático. O serviço não é dimensionado dinamicamente para atender à demanda.
  • A camada Standard aceita configurações de dimensionamento automático para permitir que você configure o dimensionamento automático baseado em regras. Parte do processo de POC deve ser encontrar 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 as camadas Premium que aceitam dimensionamento automático, em que a plataforma lida automaticamente com as decisões de dimensionamento.
• Caso seja necessário elevar uma camada de serviço ou um nível de desempenho do Banco de Dados SQL, consulte as orientações sobre como aumentar os bancos de dados individuais, sem tempo de inatividade do aplicativo.

Implantar este cenário

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

Próximas etapas

Recursos relacionados

• Aplicativo Web com redundância de zona de linha de base
• Aplicativo Web de várias regiões altamente disponível
• Abordagens de aplicativo do Serviço de Aplicativo de várias regiões para recuperação de desastre

Documentação do produto:

• Visão geral do Serviço de Aplicativos
• Visão geral do Azure Monitor
• Visão geral do plano do Serviço de Aplicativo do Azure
• Visão geral do Log Analytics no Azure Monitor
• O que é o Microsoft Entra ID?
• O que é o Banco de Dados SQL do Azure?

Módulos do Microsoft Learn:

• Configurar e gerenciar o Azure Monitor
• Configuração do Microsoft Entra ID
• Configurar o Azure Monitor
• Implantar e configurar servidores, instâncias e bancos de dados para o SQL Azure
• Explorar 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