Editar

Aplicativo Web básico

Serviço de aplicativo do Azure
Cofre de Chave do Azure
Azure Monitor
Banco de Dados SQL do Azure

Essa arquitetura mostra os componentes fundamentais de um aplicativo Web básico. Você pode usar a arquitetura para criar um aplicativo Web e, em seguida, personalizar o aplicativo de acordo com suas necessidades.

Arquitetura

Diagrama mostrando a arquitetura de referência de um aplicativo Web básico no Azure.

Baixe um Arquivo Visio dessa arquitetura.

Componentes

  • O Serviço de Aplicativo do Azure é uma plataforma totalmente gerenciada para criar e implantar aplicativos de nuvem. Ele permite definir um conjunto de recursos de computação para um aplicativo Web executar, implantar aplicativos Web e configurar slots de implantação.
  • Os slots de implantação permitem o preparo de uma implantação e, em seguida, a troca dela pela implantação de produção. Dessa forma, evita-se implantar diretamente na produção. Consulte a seção de engenharia e implantação de versão abaixo para obter recomendações específicas.
  • Endereço IP: o aplicativo Serviço de Aplicativo tem um endereço IP público e um nome de domínio. O nome de domínio é um subdomínio de azurewebsites.net, como contoso.azurewebsites.net.
  • O DNS do Azure é um serviço de hospedagem para domínios DNS, fornecendo resolução de nomes usando a infraestrutura do Microsoft Azure. Ao hospedar seus domínios no Azure, você pode gerenciar seus registros DNS usando as mesmas credenciais, APIs, ferramentas e cobrança que seus outros serviços do Azure. Para usar um nome de domínio personalizado (como contoso.com), crie registros DNS que mapeiem o nome de domínio personalizado para o endereço IP. Para obter mais informações, consulte Configurar um nome de domínio personalizado no Serviço de Aplicativo do Azure.
  • O Banco de Dados SQL do Azure é um banco de dados como serviço relacional na nuvem. O Banco de Dados SQL compartilha a sua base de código com o mecanismo do banco de dados do Microsoft SQL Server. Dependendo dos requisitos de aplicativo, você também pode usar o banco de dados do Azure para MySQL ou o banco de dados do Azure para PostgreSQL. Essas alternativas de banco de dados totalmente gerenciados, baseados no código-fonte aberto MySQL Server e nos mecanismos de banco de dados do Postgres.
  • O Microsoft Entra ID é um serviço de gerenciamento de identidade e acesso baseado em nuvem que permite aos funcionários acessar aplicativos em nuvem desenvolvidos para sua organização.
  • O Azure Monitor é uma solução para coletar, analisar e agir em logs e métricas em seus ambientes.
  • O Cofre de Chaves do Azure dá suporte ao gerenciamento de segredos, gerenciamento de chaves e gerenciamento de certificados. Ele pode armazenar segredos de aplicativos, como cadeias de conexão de banco de dados.

Recomendações

Seus requisitos podem ser diferentes da arquitetura descrita e fornecida no código. O código é implantado com configurações de produção. Use as recomendações para personalizar sua implantação para atender às suas necessidades.

Plano do Serviço de Aplicativo

O plano do Serviço de Aplicativo tem diferentes níveis de preços. Cada camada de preços dá suporte a vários tamanhos de instância que diferem por número de núcleos e memória. Você pode alterar a camada de preços após a implantação selecionando "Expandir (Plano do Serviço de Aplicativo)" na navegação à esquerda. Veja algumas recomendações do Serviço de Aplicativo:

  • Execute sua carga de trabalho de produção nos níveis de preços Basic, Standard e Premium. Nesses três níveis, o aplicativo é executado em instâncias de máquina virtual dedicadas e alocou recursos que podem ser expandidos.
  • Use as camadas Standard e Premier se precisar de dimensionamento automático e TLS/SSL.
  • Crie um plano do Serviço de Aplicativo diferente para teste e desenvolvimento. Use os níveis Gratuito e Compartilhado (visualização) para teste e desenvolvimento para eficiência de custos. Mas não use os níveis Gratuito e Compartilhado para cargas de trabalho de produção. Os recursos compartilhados não podem ser expandidos.
  • Lembre-se de excluir os planos que você não estiver usando (por exemplo, implantações de teste). Os Planos do Serviço de Aplicativo são cobrados por segundo. Você será cobrado pelas instâncias no Plano do Serviço de Aplicativo, mesmo se o aplicativo estiver parado. Para obter mais informações sobre planos e cobrança do Serviço de Aplicativo, consulte:

O modelo ARM abaixo é implantado no nível de preços Standard.

Banco de Dados SQL

  • Use o Banco de Dados SQL do Azure para reduzir a sobrecarga de gerenciamento. O Banco de Dados SQL do Azure cria um constructo lógico que atua como um ponto administrativo central para uma coleção de bancos de dados. Essa construção lógica reduz a sobrecarga de gerenciamento. Cada banco de dados dentro do grupo é implantado com uma camada de serviço específica. Dentro de cada grupo, os bancos de dados não podem compartilhar recursos. Não há custos de computação para o servidor, mas você precisa especificar a camada para cada banco de dados. Portanto, o desempenho pode ser melhor devido aos recursos dedicados, mas o custo pode ser maior.
  • Execute o planejamento de capacidade e escolha uma camada e um nível de desempenho que atendam às suas necessidades. O Banco de Dados SQL dá suporte às camadas de serviço Básico, Standard e Premium, com vários níveis de desempenho em cada camada que são medidos em DTUs (Unidades de Transmissão de Dados).

Region

  • Crie o Plano do Serviço de Aplicativo e o Banco de Dados SQL na mesma região para minimizar a latência de rede. Em geral, escolha a região mais próxima aos usuários.
  • O grupo de recursos também tem uma região. Ele especifica onde os metadados de implantação são armazenados. Coloque o grupo de recursos e seus recursos na mesma região para melhorar a disponibilidade durante a implantação.
  • Use a calculadora de preços para estimar os custos.
  • Para obter mais informações, confira a seção de custo em Estrutura Bem Projetada do Microsoft Azure.

Considerações

Essas considerações implementam os pilares da Estrutura Bem-Arquitetada do Azure. Os pilares são um conjunto de princípios de orientação que podem ser usados para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, confira Microsoft Azure Well-Architected Framework.

Eficiência de desempenho

Um grande benefício do Serviço de Aplicativo do Azure é a capacidade de dimensionar o aplicativo com base na carga. Aqui estão algumas considerações para ter em mente ao planejar dimensionar seu aplicativo.

Dimensionando o aplicativo do Serviço de Aplicativo

Há dois modos de dimensionar um aplicativo do Serviço de Aplicativo:

  • Aumentar significa alterar o tamanho da instância. O tamanho da instância determina a memória, o número de núcleos e o armazenamento em cada instância VM. Você pode aumentar manualmente, alterando o tamanho da instância ou a camada do plano.
  • Escalar horizontalmente significa adicionar instâncias para lidar com o aumento da carga. Cada tipo de preço tem um número máximo de instâncias. Você pode escalar horizontalmente de maneira manual alterando a contagem de instâncias ou configurar o dimensionamento automático para que o Azure adicione ou remova instâncias automaticamente com base na agenda e/ou nas métricas de desempenho. Cada operação de escala ocorre de maneira rápida, normalmente em questão de segundos.

Para habilitar o dimensionamento automático, crie um perfil de dimensionamento automático que defina o número mínimo e máximo de instâncias. Você pode configurar perfis baseados em agendamento para acionar eventos de escala. Por exemplo, você pode criar perfis separados para dias da semana e finais de semana. Um perfil pode conter regras de quando adicionar ou remover instâncias. Por exemplo, adicionar duas instâncias se o uso da CPU ficar acima de 70% durante 5 minutos.

Recomendações para dimensionar um aplicativo Web:

  • Limite a escala para cima e para baixo tanto quanto possível. Ele pode disparar uma reinicialização do aplicativo. Em vez disso, escale horizontalmente. Selecione uma camada e o tamanho de instância que atendem aos seus requisitos de desempenho sob carga típica e, em seguida, escale horizontalmente as instâncias para manipular as alterações no volume de tráfego.
  • Habilite o dimensionamento automático. Se seu aplicativo tiver uma carga de trabalho previsível e regular, crie perfis para agendar as contagens de instância antecipadamente. Se a carga de trabalho não for previsível, use o dimensionamento automático baseado em regras para reagir às alterações na carga conforme elas ocorrem. Você pode combinar as duas abordagens.
  • Use o uso da CPU para regras de dimensionamento automático. Geralmente, o uso da CPU é uma boa métrica para as regras de dimensionamento automático. No entanto, você deve fazer um teste de carga do seu aplicativo, identificar gargalos potenciais e basear as regras de dimensionamento automático nesses dados.
  • Defina um período de resfriamento menor para adicionar instâncias e um maior para remover instâncias. As regras de dimensionamento automático incluem um período de resfriamento . As regras de dimensionamento automático incluem um tempo de resfriamento, que é o intervalo de espera após a conclusão de uma ação de escala antes do início de uma nova ação de escala. O período de resfriamento permite que o sistema se estabilize antes de ser escalado novamente. Por exemplo, defina 5 minutos para adicionar uma instância, mas 60 minutos para remover uma instância. É melhor adicionar novas instâncias rapidamente sob carga pesada para manipular o outro tráfego e, em seguida, escalar gradualmente de volta.

Dimensionando bancos de dados SQL

Aumente bancos de dados individuais sem tempo de inatividade do aplicativo se você precisar de uma camada de serviço ou nível de desempenho mais alto para o Banco de Dados SQL.

Para obter mais informações, confira Escalar recursos de banco de dados individual no Banco de Dados SQL do Azure.

Confiabilidade

No momento em que este artigo foi escrito, o contrato de nível de serviço (SLA) para o Serviço de Aplicativo é de 99,95%. O SLA do Serviço de Aplicativo aplica-se a instâncias únicas e múltiplas. O SLA para Banco de Dados SQL é de 99,99% para as camadas Basic, Standard e Premium.

Backups

O Banco de Dados SQL fornece restauração pontual e restauração geográfica para restaurar a perda de dados. Esses recursos estão disponíveis em todas as camadas e são habilitados automaticamente. Você não precisa agendar ou gerenciar os backups.

Excelência operacional

Crie grupos de recursos separados para ambientes de produção, desenvolvimento e teste. Ambientes separados tornam mais fácil gerenciar implantações, excluir implantações de teste a atribuir direitos de acesso.

Ao atribuir recursos para grupos de recursos, considere os seguintes recursos:

  • Ciclo de vida. Em geral, coloque recursos com o mesmo ciclo de vida no mesmo grupo de recursos.
  • Acesso. É possível usar o controle de acesso baseado em função (RBAC) do Azure para aplicar políticas de acesso aos recursos de um grupo.
  • Cobrança. Você pode exibir os custos acumulados para o grupo de recursos.

Para obter mais informações, confira Visão geral do Azure Resource Manager.

Configuração de Aplicativo

  • Armazene definições de configuração como configurações do aplicativo. Defina as configurações do aplicativo em seus modelos do Resource Manager ou com o PowerShell. No runtime, as configurações de aplicativo ficam disponíveis para o aplicativo como variáveis de ambiente.
  • Nunca verifique senhas, chaves de acesso ou cadeias de conexão no controle do código-fonte. Nesse caso, passe esses parâmetros para um script de implantação que armazena esses valores como configurações do aplicativo.
  • Quando você alterna um slot de implantação, as configurações do aplicativo são alternadas por padrão. Se você precisar de configurações diferentes para produção e preparo, será possível criar configurações de aplicativo que permanecem em um slot e não são trocadas.

Diagnóstico e monitoramento

DevOps

  • Use modelos ARM para implantar recursos do Azure e suas dependências. O modelo ARM que o acompanha implanta um único aplicativo Web. Todos os recursos são isolados na mesma carga de trabalho básica. Esse isolamento facilita a associação de recursos específicos da carga de trabalho a uma equipe. A equipe pode então gerenciar de forma independente todos os aspectos desses recursos. Esse isolamento permite que a equipe de DevOps execute a CI/CD (integração contínua e entrega contínua).
  • Use diferentes modelos ARM e integre-os aos serviços de DevOps do Azure. Essa configuração permite criar ambientes diferentes em minutos. Por exemplo, você pode replicar cenários semelhantes à produção ou ambientes de teste de carga somente quando necessário e economizar no custo.
  • Provisione várias instâncias do aplicativo Web. Você não quer que seu aplicativo Web dependa de uma única instância e potencialmente crie um único ponto de falha. Várias instâncias aprimoram a resiliência e a escalabilidade.

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

Engenharia de versão e implantação

  • Use Modelos do Azure Resource Manager para provisionar recursos do Azure. Os modelos facilitam a automatização das implantações por meio do PowerShell ou da CLI do Azure.
  • Implante o aplicativo (código, binários e arquivos de conteúdo). Existem várias opções, incluindo a implantação de um repositório Git local, usando o Visual Studio ou a implantação contínua usando o controle do código-fonte baseado em nuvem. Consulte Implantar o aplicativo no Serviço de Aplicativo do Azure.

Um aplicativo do Serviço de Aplicativo sempre tem um slot de implantação chamado production. O slot de produção representa o local de produção ao vivo. É recomendável criar um slot de preparo para implantar atualizações. Os benefícios do uso de um slot de preparo incluem:

  • Você pode verificar se a implantação foi bem-sucedida antes de colocá-la em produção.
  • Implantar em um slot de preparo garante que todas as instâncias sejam aquecidas antes de serem alternadas para produção. Muitos aplicativos têm um tempo significativo de aquecimento e de resfriamento.
  • Crie um terceiro slot de implantação para conter a LKG (última implantação válida). Depois de alternar o preparo e a produção, mova a implantação de produção anterior (que agora está no processo de preparo) para o último slot válido. Dessa forma, se você descobrir um problema mais tarde, será possível reverter rapidamente para a última versão válida.

Trocando slots para implantações de produção e de preparo

  • Ao reverter para uma versão anterior, verifique se todas as alterações de esquema do banco de dados são compatíveis com as versões anteriores.
  • Não use os slots da implantação de produção para teste, porque todos os aplicativos no mesmo Plano do Serviço de Aplicativo compartilham as mesmas instâncias de VM. Por exemplo, testes de carga podem prejudicar o site de produção dinâmica. Nesse caso, crie Planos do Serviço de Aplicativo separados para teste e produção. Colocando as implantações de teste em um plano separado, você as isola da versão de produção.

Segurança

Esta seção lista as considerações sobre segurança específicas dos serviços do Azure descritos neste artigo. Esta não é uma lista completa de práticas recomendadas de segurança. Para algumas outras considerações de segurança, consulte Proteger um aplicativo no Serviço de Aplicativo do Azure.

Auditoria do Banco de Dados SQL

A auditoria pode ajudar a manter a conformidade regulamentar e obter informações sobre discrepâncias e irregularidades que podem indicar preocupações comerciais ou suspeitas de violações de segurança. Consulte Introdução à auditoria do banco de dados SQL.

Slots de implantação

Cada slot de implantação tem um endereço IP público. Proteja os slots que não são de produção usando o logon do Microsoft Entra para que somente os membros das equipes de desenvolvimento e de DevOps possam acessar esses pontos de extremidade.

Logging

Os logs nunca devem registrar senhas de usuários ou outras informações que possam ser usadas para confirmação de fraude de identidade. Remova esses detalhes dos dados antes de armazená-los.

SSL

Um aplicativo do Serviço de Aplicativo inclui um ponto de extremidade SSL em um subdomínio do azurewebsites.net sem custo adicional. O ponto de extremidade SSL inclui um certificado curinga para o domínio *.azurewebsites.net. Ao usar um nome de domínio personalizado, você deverá fornecer um certificado que corresponda ao domínio personalizado. A abordagem mais simples é comprar um certificado diretamente no portal do Azure. Você também pode importar certificados de outras autoridades de certificação. Para obter mais informações, consulte Comprar e configurar um certificado SSL para seu Serviço de Aplicativo do Azure.

O HTTPS não está habilitado por padrão na implantação do modelo ARM. Como prática recomendada de segurança, o aplicativo deve impor HTTPS redirecionando as solicitações HTTP. Você pode implementar HTTPS dentro do seu aplicativo ou usar uma regra de reescrita de URL conforme descrito em habilitar HTTPS para um aplicativo no Serviço de Aplicativo do Azure.

Autenticação

Recomendamos a autenticação por meio de um IDP (provedor de identidade), como Microsoft Entra ID, Facebook, Google ou Twitter. Use o OAuth 2 ou o OIDC (OpenID Connect) para o fluxo de autenticação. O Microsoft Entra ID fornece a funcionalidade de gerenciar usuários e grupos, criar funções de aplicativo, integrar identidades locais e consumir serviços de back-end, como o Microsoft 365 e o Skype for Business.

Evite que o aplicativo gerencie logins e credenciais de usuários diretamente. Ele cria uma superfície de ataque potencial. No mínimo, seria necessário ter uma confirmação por email, uma recuperação de senha e uma autenticação multifator, bem como validar o nível de segurança da senha e armazenar hashes de senha com segurança. Os grandes provedores de identidade cuidam de tudo isso para você e estão sempre monitoramento e aprimorando as práticas de segurança.

Considere usar Autenticação do Serviço de Aplicativo para implementar o fluxo de autenticação OAuth ou OIDC. Os benefícios de autenticação do Serviço de Aplicativo incluem:

  • Fácil de configurar.
  • Nenhum código é necessário para cenários de autenticação simples.
  • Dá suporte para autorização delegada usando tokens de acesso OAuth para consumir recursos em nome do usuário.
  • Fornece um cache de token interno.

Algumas limitações da autenticação do Serviço de Aplicativo:

  • Opções de personalização limitadas.
  • A autorização delegada é restrita a um recurso de back-end por sessão de logon.
  • Se você usar mais de um IDP, não haverá nenhum mecanismo interno para descoberta de realm inicial.
  • Para cenários multilocatários, o aplicativo deve implementar a lógica para validar o emissor do token.

Implantar este cenário

Essa arquitetura inclui um plano do Serviço de Aplicativo do Azure e um aplicativo vazio. Ele usa o Banco de Dados SQL do Azure, o Cofre de Chaves do Azure para armazenar a cadeia de conexão do banco de dados e o Monitor do Azure para log, monitoramento e alerta.

Use o comando a seguir para criar um grupo de recursos para a implantação. Clique no botão Experimentar para usar um shell inserido.

az group create --name basic-web-app --location eastus

Execute o comando a seguir para implantar o aplicativo Web e a infraestrutura de suporte. Quando solicitado, digite o nome de usuário e a senha. Esses valores são usados para acessar a instância do Banco de Dados SQL do Azure.

az deployment group create --resource-group basic-web-app  \
    --template-uri https://raw.githubusercontent.com/mspnp/samples/master/solutions/basic-web-app/azuredeploy.json

Para obter informações detalhadas e opções de implantação adicionais, consulte os modelos do ARM usados para implantar essa solução.

Modelo do ARM de aplicativo Web básico

Próximas etapas

Dicas para solucionar problemas do aplicativo:

Documentação do produto:

Módulos do Microsoft Learn: