Aplicação Web básica

Serviço de Aplicações do Azure

Azure Monitor

Base de Dados SQL do Azure

Este artigo apresenta uma arquitetura básica para o ajudar a aprender a executar aplicações web no Serviço de Aplicações do Azure numa única região.

Importante

Esta arquitetura não é feita para aplicações de produção. Funciona como uma configuração introdutória para propósitos de aprendizagem e prova de conceito (POC). Para conceber uma aplicação de Serviço de Aplicação de produção, consulte Baseline aplicação web altamente disponível e redundante por zona.

Arquitetura

Descarregue um ficheiro Visio desta arquitetura.

Workflow

O fluxo de trabalho a seguir corresponde ao diagrama anterior.

Um utilizador emite um pedido HTTPS para o domínio predefinido do Serviço de Aplicações em azurewebsites.net. Este domínio aponta automaticamente para o endereço IP público incorporado da sua aplicação de Serviço de Aplicações. A ligação de segurança da camada de transporte (TLS) é estabelecida diretamente do cliente para o App Service. O Azure gere totalmente o certificado.
Easy Auth, que é uma funcionalidade do App Service, garante que o utilizador que acede ao site é autenticado usando o Microsoft Entra ID.
O código da aplicação implantado no App Service processa o pedido. Por exemplo, esse código pode ligar-se a uma instância do Base de Dados SQL do Azure usando uma cadeia de ligação configurada no App Service como configuração de app.
A informação sobre o pedido original ao App Service e a chamada para a base de dados SQL está registada no Application Insights.

Componentes

O Microsoft Entra ID é um serviço de gerenciamento de identidade e acesso baseado em nuvem que fornece recursos de autenticação e autorização. Nesta arquitetura, integra-se com o App Service através da Easy Auth para garantir a autenticação dos utilizadores que acedem à aplicação web. Também simplifica o processo de autenticação sem exigir alterações significativas ao código.
O Serviço de Aplicativo é uma plataforma gerenciada para criar, implantar e dimensionar aplicativos Web. Nesta arquitetura, aloja o código da aplicação web, gere pedidos HTTPS no domínio predefinido azurewebsites.net e liga-se à base de dados SQL através de cadeias de ligação configuradas.
O Azure Monitor é um serviço de monitoramento que coleta, analisa e atua em dados de telemetria de ambientes locais e na nuvem. Nessa arquitetura, ele captura e armazena informações sobre solicitações ao 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. Nesta arquitetura, serve como camada de armazenamento de dados, que permite à aplicação do Serviço de Aplicações conectar-se através de cadeias de ligação definidas nas definições da aplicação.

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 estão ligados 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 secção aprofunda essa orientação, destacando as recomendações e considerações chaves do Well-Architected Framework que se aplicam a esta arquitetura.

Esta arquitetura básica foi concebida apenas para fins de avaliação e aprendizagem. Prioriza a simplicidade e a eficiência de custos em detrimento da funcionalidade de produção. As secções seguintes destacam as principais limitações desta arquitetura e fornecem recomendações e considerações para o ajudar a planear implementações mais robustas.

Fiabilidade

A confiabilidade ajuda a garantir 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.

Esta arquitetura não foi concebida para implementações em produção. As seguintes características críticas de fiabilidade são omitidas nesta arquitetura:

O plano de App Service está configurado para o nível Standard, que não inclui suporte para zonas de disponibilidade Azure. O App Service torna-se indisponível se surgir um problema com a instância, o rack ou o datacenter que aloja a instância.
A base de dados SQL está configurada para o nível Básico, que não suporta redundância de zonas. Como resultado, os dados não são replicados entre as zonas de disponibilidade do Azure, o que pode causar perda de dados comprometidos caso ocorra uma falha.
Implementações nesta arquitetura podem resultar em indisponibilidade para aplicações porque a maioria das técnicas de implementação exige que todas as instâncias em execução sejam reiniciadas. Os utilizadores podem experienciar erros 503 durante este processo. Esse tempo de inatividade da implantação é abordado na arquitetura de linha de base por meio 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 fiabilidade causados por recursos computacionais insuficientes, deve sobreprovisionar para garantir capacidade suficiente para lidar com a procura máxima concorrente.

Para mais informações sobre como lidar com estas preocupações de fiabilidade, consulte Aplicação web de zona altamente disponível e redundante - Fiabilidade.

Se a carga de trabalho exigir uma arquitetura multi-região ativo-ativo ou ativo-passivo, consulte abordagens do serviço de aplicativo multi-região para recuperação de desastres.

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.

Esta arquitetura não foi concebida para implementações em produção. As seguintes características críticas de segurança foram omitidas nesta arquitetura, juntamente com outras recomendações e considerações de fiabilidade:

Esta arquitetura básica não implementa a privacidade da rede. Os planos de dados e gestão dos recursos, como App Service e Azure SQL Server, são acessíveis através da internet pública. Omitir a rede privada aumenta significativamente a superfície de ataque da sua arquitetura. Para mais informações sobre como a implementação de redes privadas garante as seguintes funcionalidades de segurança, consulte Aplicação web redundante de zona altamente disponível – Rede. A implementação de redes privadas ajuda a mitigar estes riscos ao fornecer as seguintes funcionalidades de segurança:
- Um único ponto de entrada seguro para o tráfego dos clientes.
- O tráfego de rede é filtrado tanto ao nível do pacote como ao nível de negação de serviço distribuída (DDoS).
- A exfiltração de dados é minimizada mantendo o tráfego no Azure através do Azure Private Link.
- Os recursos de rede são logicamente agrupados e isolados uns dos outros através da segmentação de rede.
Esta arquitetura básica não inclui uma implementação de Firewall de Aplicações Web do Azure. O aplicativo Web não está protegido contra exploits e vulnerabilidades comuns. Para ver como Firewall de Aplicações Web do Azure pode ser implementado com Gateway de Aplicação do Azure numa arquitetura de Serviços de Aplicações, veja a implementação baseline.
Esta arquitetura básica armazena segredos como o SQL Server cadeia de ligação nas Definições da Aplicação. As definições da aplicação estão encriptadas por padrão. No entanto, quando passar para produção, considere armazenar segredos no Azure Key Vault para melhorar a governação. Para maior segurança e redução da sobrecarga de gestão de segredos, considere usar identidade gerida para autenticação em vez de incorporar segredos em cadeias de ligação.
A depuração remota e os endpoints Kudu podem permanecer ativados 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.
Os métodos locais de autenticação para implementações de protocolos de transferência de ficheiros (FTP) e gestão de controlo de versões (SCM) podem permanecer ativados durante a fase de desenvolvimento ou POC. Deve-se desabilitar a autenticação local nesses endpoints ao passar para a produção.
Não precisas de ativar o Microsoft Defender para o App Service na fase POC. Quando passar para produção, deve ativar o Defender for App Service para gerar recomendações de segurança. Deve implementar estas recomendações para aumentar a sua postura de segurança e detetar múltiplas ameaças à implementação do seu Serviço de Aplicações.
O Serviço de Aplicações inclui um endpoint Secure Sockets Layer (SSL) num subdomínio de azurewebsites.net sem custo adicional. As solicitações HTTP são redirecionadas para o ponto de extremidade HTTPS por padrão. Para implementações em produção, um domínio personalizado é normalmente utilizado com o Application Gateway ou API Management antes da implementação do seu Serviço de Aplicações.
Utilize o mecanismo integrado de autenticação do App Service. A Easy Auth simplifica o processo de integração dos fornecedores de identidade na sua aplicação 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 autentica-se ao SQL Server usando uma palavra-passe numa cadeia de ligação. Considere usar a identidade gerida para autenticar para SQL Server.

Para mais informações, consulte Proteger uma aplicação no App Service.

Otimização de Custos

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

Esta arquitetura otimiza o custo através dos muitos trade-offs em relação aos outros pilares do Well-Architected Framework. Estas compensações são especificamente feitas para alinhar-se com os objetivos de aprendizagem e provas de conceito desta arquitetura. A poupança de custos em comparação com uma arquitetura mais pronta para produção, como a aplicação web redundante de zona altamente disponível e de base, resulta principalmente das seguintes escolhas:

Uma única instância de Serviço de Aplicações, sem autoescalonamento ativado
Escalão de preços padrão para o App Service
Sem certificado TLS personalizado ou endereço IP estático
Nenhum firewall de aplicativo Web (WAF)
Nenhuma conta de armazenamento dedicada para implantação de aplicativos
Tarifa básica para base de dados SQL, sem políticas de retenção de cópias de segurança
Nenhum componente do Microsoft Defender para a Cloud
Sem controle de saída de tráfego de rede através de um firewall
Sem pontos finais privados
Logs mínimos e período de retenção de logs no Azure Monitor Logs

Para ver o custo estimado desta arquitetura, consulte a estimativa do calculador de preços que utiliza os componentes desta arquitetura. O custo desta arquitetura pode geralmente ser ainda mais reduzido usando uma subscrição Azure Dev/Test, que seria um tipo de subscrição ideal para POCs deste tipo.

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 secções seguintes fornecem orientações sobre a configuração, monitorização e implementação da sua aplicação de Serviços de Aplicação.

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. Podes guardar segredos na configuração do App Service durante a fase POC. Não se usam segredos autênticos nem se requer a gestão de segredos que as cargas de trabalho de produção exigem.

Considere as seguintes recomendações e considerações de configuração:

Comece por usar a configuração do App Service para armazenar valores de configuração e cadeias de ligação em implementações POC. As definições da aplicação e as cadeias de ligação são encriptadas e desencriptadas imediatamente antes de serem injetadas na aplicação quando esta começa.
Quando passares para produção, guarda os teus segredos no Key Vault. O Key Vault melhora a governação dos segredos de duas formas:
- Externalizar os seus segredos para o Key Vault proporciona um local único e centralizado para a gestão segura de segredos.
- Ao usar o Key Vault, pode registar todas as interações com segredos, incluindo sempre que um segredo é acedido.
Quando passar para produção, pode manter a configuração tanto do Key Vault como do Serviço de Aplicações, usando referências Key Vault.

Contentores

Pode usar a arquitetura básica para implementar código suportado diretamente para instâncias do Windows ou Linux. Alternativamente, o App Service é também uma plataforma de alojamento de contentores que pode usar para executar a sua aplicação web containerizada. O App Service fornece vários contentores incorporados. Aplicações personalizadas ou de múltiplos contentores ajudam a afinar o ambiente de execução ou a suportar linguagens de código que não são suportadas nativamente. Esta abordagem requer a introdução de um registo de contentores.

Plano de controlo

Durante a fase POC, familiarize-se com o plano de controlo do App Service, acessível através do serviço Kudu. Este serviço fornece APIs comuns de implementação, como implementações ZIP, e expõe logs brutos e variáveis de ambiente.

Se usar contentores, assegure-se de compreender as funcionalidades do Kudu para abrir uma sessão de Secure Shell (SSH) num contentor, suportando assim capacidades avançadas de depuração.

Diagnóstico e monitorização

Durante a fase POC, é importante compreender que registos e métricas estão disponíveis para captura. Considere as seguintes recomendações e ideias para monitorização na fase de POC:

Habilite o registo de diagnósticos para todas as origens de registo de itens. Configurar o uso de todas as definições de diagnóstico ajuda-o a perceber que logs e métricas lhe são fornecidos logo de início e ajuda-o a identificar quaisquer lacunas que precise de colmatar usando um framework de logging no seu código de aplicação. Quando passares para produção, elimina fontes de registos que não acrescentam valor mas acrescentam ruído e custo ao sumidouro de logs da tua carga de trabalho.
Configure o registo para utilizar o Azure Log Analytics. O Azure Log Analytics oferece-lhe uma plataforma escalável para centralizar o registo e fácil de consultar.
Utilize o Application Insights ou outra ferramenta de gestão de desempenho de aplicações (APM) para a emissão de telemetria e de logs para monitorizar o desempenho de aplicações.

Implementação

Os seguintes pontos fornecem orientações sobre como implementar a sua aplicação de Serviços de Aplicações:

Siga as orientações em CI/CD para Aplicativos Web do Azure com Pipelines do Azure para automatizar a implantação do seu aplicativo. Começa a construir a tua lógica de implementação na fase POC. Implementar integração contínua e entrega contínua (CI/CD) logo no início do processo de desenvolvimento permite-lhe iterar rápida e com segurança sobre a sua aplicação à medida que avança para a produção.
Use modelos Azure Resource Manager (templates ARM) para implementar os recursos Azure e as suas dependências. É importante começar 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 com os Serviços Azure DevOps. 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 mais informações, consulte os princípios de design de Excelência Operacional.

Eficiência de desempenho

A Eficiência de Desempenho refere-se à capacidade da sua carga de trabalho de escalar para atender às demandas dos usuários de forma eficiente. Para obter mais informações, consulte Lista de verificação de revisão de projeto para eficiência de desempenho.

Como esta arquitetura não foi concebida para implementações em produção, esta secção descreve algumas das características críticas de eficiência de desempenho que foram omitidas nesta arquitetura, juntamente com outras recomendações e considerações.

Um resultado do seu POC deve ser uma seleção de SKU que considere adequada para a sua carga de trabalho. Projete a sua carga de trabalho para responder eficientemente à procura através da escalabilidade horizontal, ajustando o número de instâncias de computação implementadas no plano de Serviços de Aplicação. Não projete o sistema para depender da alteração do SKU de computação para alinhar com a procura.

A implementação do App Service nesta arquitetura básica não tem escalabilidade automática implementada. O serviço não escala dinamicamente para fora nem para dentro para se alinhar eficientemente com a procura.
- O nível Standard suporta definições de autoscaling para permitir configurar autoscaling baseado em regras. Como parte do seu processo POC, determine definições de autoscaling eficientes adaptadas aos requisitos de recursos do seu código de aplicação e aos padrões de utilização esperados.
- Para implementações em produção, considere os níveis Premium que suportam autoescalabilidade , onde a plataforma gere automaticamente as decisões de escalabilidade.
Siga as orientações para dimensionar bancos de dados individuais sem qualquer tempo de inatividade do aplicativo, se necessitar de um nível de serviço ou desempenho mais elevado para o Banco de Dados SQL.

Próximos passos

Tutoriais de implantação:

Documentação do produto:

Módulos do Microsoft Learn:

Comentários

Esta página foi útil?