Aplicativo Web básico

Serviço de aplicativo do Azure

Azure Monitor

Banco de Dados SQL do Azure

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

Importante

Essa arquitetura não se destina a aplicativos de produção. Ele serve como uma configuração introdutória para fins de aprendizado e prova de conceito (POC). Para criar um aplicativo em produção do Serviço de Aplicativo, consulte um aplicativo Web redundante em zonas de alta disponibilidade na linha de base.

Arquitetura

Baixe um arquivo do Visio dessa arquitetura.

Workflow

O fluxo de trabalho a seguir corresponde ao diagrama anterior.

Um usuário emite uma solicitação HTTPS para o domínio padrão do Serviço de Aplicativo.azurewebsites.net Esse domínio aponta automaticamente para o endereço IP público integrado do aplicativo do Serviço de Aplicativo. A conexão TLS (segurança da camada de transporte) é estabelecida do cliente diretamente para o App Service. Azure gerencia totalmente o certificado.
O Easy Auth, que é um recurso do Serviço de Aplicativo, garante que o usuário que acessa o site seja autenticado usando Microsoft Entra ID.
O código do aplicativo, implantado no App Service, lida com a solicitação. Por exemplo, esse código pode se conectar a uma instância de Banco de Dados SQL do Azure usando uma cadeia de conexão configurada no App Service como uma configuração de app.
As informações sobre a solicitação original para o Serviço de Aplicativo e a chamada para o Banco de Dados SQL são registradas no Application Insights.

Componentes

O Microsoft Entra ID é um serviço de gerenciamento de acesso e identidade baseado em nuvem que fornece recursos de autenticação e autorização. Nessa arquitetura, ele se integra ao Serviço de Aplicativo por meio da Autenticação Fácil para garantir a autenticação para usuários que acessam o aplicativo Web. Ele também simplifica o processo de autenticação sem exigir alterações significativas no código.
O Serviço de Aplicativo é uma plataforma gerenciada para criar, implantar e dimensionar aplicativos Web. Nessa arquitetura, ele hospeda o código do aplicativo Web, lida com solicitações HTTPS no domínio padrão azurewebsites.net e se conecta ao Banco de Dados SQL por meio de cadeias de conexão configuradas.
O Azure Monitor é um serviço de monitoramento que coleta, analisa e atua em dados de telemetria de ambientes locais e de nuvem. Nessa arquitetura, ele captura e armazena informações sobre solicitações para o Serviço de Aplicativo e chamadas para o Banco de Dados SQL por meio da integração do Application Insights.
O Banco de Dados SQL é um serviço de banco de dados relacional gerenciado que fornece recursos do SQL Server na nuvem. Nessa arquitetura, ela serve como a camada de armazenamento de dados, que permite que o aplicativo do Serviço de Aplicativo se conecte por meio de cadeias de conexão definidas nas configurações do aplicativo.

Considerações

Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que você pode usar para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Well-Architected Framework.

Os componentes listados nesta arquitetura se referem aos guias de serviço do 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 FrameworkWell-Architected que se aplicam a essa arquitetura.

Essa arquitetura básica foi projetada apenas para fins de avaliação e aprendizado. Ele prioriza a simplicidade e a eficiência de custo em relação à funcionalidade de nível de produção. As seções a seguir destacam as principais limitações dessa arquitetura e fornecem recomendações e considerações para ajudá-lo a planejar implantações mais robustas.

Confiabilidade

A confiabilidade ajuda a garantir que seu aplicativo possa cumprir os compromissos que você faz aos seus clientes. Para obter mais informações, consulte Lista de verificação de revisão de design para confiabilidade.

Essa arquitetura não foi projetada para implantações de produção. Os seguintes recursos críticos de confiabilidade são omitidos nesta arquitetura:

O plano do Serviço de Aplicativo está configurado para a camada Standard, que não inclui suporte para zonas de disponibilidade Azure. O Serviço de Aplicativo ficará indisponível se ocorrer um problema com a instância, o rack ou o datacenter que hospeda a instância.
O Banco de Dados SQL está configurado para a camada Básica, que não dá suporte à redundância de zona. Como resultado, os dados não são replicados nas zonas de disponibilidade do Azure, o que apresenta o risco de perda de dados comprometidos, caso ocorra uma interrupção.
As implantações nessa arquitetura podem resultar em tempo de inatividade para 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 experimentar 503 erros durante esse processo. Esse tempo de inatividade da implantação é solucionado na arquitetura de referência por meio dos 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 centrada em slots.
O dimensionamento automático não está habilitado nesta arquitetura básica. Para evitar problemas de confiabilidade causados por recursos de computação insuficientes, você deve superprovisionar para garantir capacidade suficiente para lidar com a demanda máxima simultânea.

Para obter mais informações sobre como superar essas preocupações de confiabilidade, consulte o aplicativo Web com redundância de zona altamente disponível na linha de base – Confiabilidade.

Se a carga de trabalho exigir uma arquitetura ativa-ativa ou ativa-passiva de várias regiões, consulte Abordagens de aplicativo do App Service para várias regiões em recuperação de desastre.

Segurança

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

Essa arquitetura não foi projetada para implantações de produção. Os seguintes recursos críticos de segurança 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 para os recursos, como o Serviço de Aplicativo e o Azure SQL Server, podem ser acessados pela Internet pública. Omitir a rede privada aumenta significativamente a superfície de ataque de sua arquitetura. Para obter mais informações sobre como implementar a rede privada garante os seguintes recursos de segurança, consulte o aplicativo Web com redundância de zona altamente disponível na linha de base – Rede. Implementar a rede privada ajuda a atenuar esses riscos fornecendo os seguintes recursos de segurança:
- Um único ponto de entrada seguro para o tráfego do cliente.
- O tráfego de rede é filtrado no nível do pacote e no nível de DDoS (negação de serviço distribuído).
- A exfiltração de dados é minimizada mantendo o tráfego em Azure usando Link Privado do Azure.
- Os recursos de rede são agrupados e isolados logicamente uns dos outros por meio da segmentação de rede.
Essa arquitetura básica não inclui uma implantação de Firewall de Aplicativo Web do Azure. O aplicativo Web não está protegido contra explorações e vulnerabilidades comuns. Para ver como Firewall de Aplicativo Web do Azure pode ser implementado com Gateway de Aplicativo do Azure em uma arquitetura dos Serviços de Aplicativo, consulte a implementação baseline.
Essa arquitetura básica armazena segredos como o SQL Server cadeia de conexão nas Configurações do Aplicativo. As configurações do aplicativo são criptografadas por padrão. No entanto, ao migrar para a produção, considere armazenar segredos em Azure Key Vault para aumentar a governança. Para uma segurança mais forte e uma sobrecarga de gerenciamento de segredo reduzida, considere usar a identidade gerenciada para autenticação em vez de inserir segredos em cadeias de conexão.
A depuração remota e os endpoints do Kudu podem permanecer habilitados durante o desenvolvimento ou a fase POC. Ao passar para a produção, você deve desabilitar o plano de controle, a implantação ou o acesso remoto desnecessários.
Métodos de autenticação local para ftp (protocolo de transferência de arquivo) e implantações de site de gerenciamento de controle do código-fonte (SCM) podem permanecer habilitados durante a fase de desenvolvimento ou POC. 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 App Service na fase POC. Ao migrar para a produção, você deve habilitar o Defender para App Service para gerar recomendações de segurança. Você deve implementar essas recomendações para aumentar sua postura de segurança e detectar várias ameaças à implantação do Serviço de Aplicativo.
Serviço Aplicativo do azurewebsites.net inclui um endpoint SSL (Secure Sockets Layer) em um subdomínio sem custo extra. As solicitações HTTP são redirecionadas para o ponto de extremidade HTTPS por padrão. Para implantações de produção, um domínio personalizado normalmente é usado com o Application Gateway ou o Gerenciamento de API à frente da implantação do Serviço de Aplicativo.
Use o mecanismo de autenticação integrada para o Serviço de Aplicativo. O Easy Auth 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 autentica-se ao SQL Server usando uma senha em uma cadeia de conexão. Considere usar identidade gerenciada para autenticar no SQL Server.

Para obter mais informações, consulte Proteger um aplicativo no Serviço de Aplicativo.

Otimização de custos

A Otimização de Custos concentra-se em maneiras de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Lista de verificação para revisão de design da Otimização de Custos.

Essa arquitetura otimiza custos ao fazer várias concessões em relação aos outros pilares do Well-Architected Framework. Essas compensações são feitas especificamente para se alinharem às metas de aprendizagem e POC dessa arquitetura. A economia de custos em comparação com uma arquitetura mais próxima da produção, como o aplicativo Web altamente disponível e com redundância de zona, resulta principalmente das seguintes opções:

Uma única instância do Serviço de Aplicativo, sem dimensionamento automático habilitado
Tipo de preço padrão para o Serviço de Aplicativo
Nenhum certificado TLS personalizado ou endereço IP estático
Nenhum firewall de aplicativo web (WAF)
Nenhuma conta de armazenamento dedicada para implantação de aplicativo
Tipo de preço básico para o Banco de Dados SQL, sem políticas de retenção de backup
Não há nenhum componente do Microsoft Defender para Nuvem
Nenhum controle de saída de tráfego de rede por meio de um firewall
Não existem endpoints privados
Período mínimo de retenção e logs nos Logs do Azure Monitor

Para exibir o custo estimado dessa arquitetura, consulte a estimativa da calculadora de preços que usa os componentes dessa arquitetura. O custo dessa arquitetura geralmente pode ser reduzido ainda mais usando uma assinatura Azure Dev/Test, que seria um tipo de assinatura ideal para POCs como este.

Excelência Operacional

A Excelência Operacional abrange os processos de operações que implantam um aplicativo e o mantêm em execução em 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 a configuração, o monitoramento e a implantação do aplicativo do 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. Você pode armazenar segredos na configuração do App Service durante a fase POC. Você não usa segredos reais e não requer a governança de segredos que as cargas de trabalho de produção exigem.

Considere as seguintes 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 POC. As configurações do aplicativo e as cadeias de conexão são criptografadas e descriptografadas imediatamente antes de serem injetadas em seu aplicativo quando ele é iniciado.
Ao migrar para a produção, armazene seus segredos em Key Vault. Key Vault melhora a governança de segredos de duas maneiras:
- Externalizar seus segredos para Key Vault fornece um único local centralizado para gerenciamento seguro de segredos.
- Usando Key Vault, você pode registrar todas as interação com segredos, inclusive sempre que um segredo for acessado.
Ao migrar para a produção, você pode continuar usando tanto o Key Vault quanto a configuração do App Service utilizando referências Key Vault.

Contêineres

Você pode usar a arquitetura básica para implantar o código com suporte diretamente em instâncias Windows ou Linux. Como alternativa, o Serviço de Aplicativo também é uma plataforma de hospedagem de contêiner que você pode usar para executar seu aplicativo Web em contêineres. O Serviço de Aplicativo fornece vários contêineres internos. Aplicativos personalizados ou com múltiplos contêineres ajudam a ajustar o ambiente de tempo de execução ou a suportar linguagens de programação que não têm suporte nativo. Essa abordagem requer a introdução de um registro de contêiner.

Painel de controle

Durante a fase de POC, familiarize-se com o Plano de Controle do Serviço de Aplicativo, que é acessível por meio do serviço Kudu. Esse serviço fornece APIs de implantação comuns, como implantações ZIP, e expõe logs brutos e variáveis de ambiente.

Se você usar contêineres, certifique-se de entender a capacidade do Kudu de abrir uma sessão SSH (Secure Shell) em um contêiner para dar suporte a recursos avançados de depuração.

Diagnóstico e monitoramento

Durante a fase POC, é importante ter uma compreensão de quais logs e métricas estão disponíveis para captura. Considere as seguintes recomendações e ideias para monitoramento na fase POC:

Habilite o log de diagnóstico para todas as fontes de log. Configurar o uso de todas as configurações de diagnóstico ajuda você a entender quais logs e métricas são fornecidos e a identificar quaisquer lacunas que você precise fechar utilizando um framework de logging no código do seu aplicativo. Ao migrar para a produção, elimine as fontes de log que não adicionam valor, mas adicionam ruído e custo ao coletor de log da carga de trabalho.
Configure o registro em log para usar o Azure Log Analytics. 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 gerenciamento de desempenho de aplicativos (APM) para emitir telemetria e logs para monitorar o desempenho do aplicativo.

Implantação

Os seguintes pontos fornecem diretrizes sobre como implantar seu aplicativo do 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 POC. Implementar a CI/CD (integração contínua e entrega contínua) no início do processo de desenvolvimento permite que você itera rapidamente e com segurança em seu aplicativo à medida que avança em direção à produção.
Use modelos Azure Resource Manager (modelos do ARM) para implantar Azure recursos 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 modelos diferentes do ARM e integre-os ao Azure DevOps Services. 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, consulte os princípios de design da Excelência Operacional.

Eficiência de desempenho

A Eficiência de Desempenho refere-se à capacidade da carga de trabalho de dimensionar para atender às demandas do usuário com eficiência. 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, esta seção descreve 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 de sua POC deve ser uma seleção de SKU que você estima ser adequada para sua carga de trabalho. Projete sua carga de trabalho 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 que dependa da alteração da SKU de computação para se alinhar à demanda.

A implantação do Serviço de Aplicativo nesta arquitetura básica não tem o dimensionamento automático implementado. O serviço não escala dinamicamente para fora ou para dentro para se manter eficientemente alinhado com a demanda.
- A camada Standard dá suporte a configurações de dimensionamento automático para permitir que você configure o dimensionamento automático baseado em regra. Como parte do processo de POC, determine as configurações de dimensionamento automático eficientes adaptadas aos requisitos de recursos do código do aplicativo e aos padrões de uso esperados.
- Para implantações de produção, considere as camadas Premium que dão suporte ao dimensionamento automático em que a plataforma lida automaticamente com 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.

Próximas etapas

Tutoriais de implantação:

Documentação do produto:

Módulos do Microsoft Learn:

Comentários

Esta página foi útil?