Partilhar via

Usar o Azure Front Door em uma solução multilocatária

  • Artigo

O Azure Front Door é uma moderna rede de entrega de conteúdo na nuvem (CDN) que fornece acesso rápido e confiável entre os usuários e o conteúdo da Web estático e dinâmico dos aplicativos em todo o mundo. Este artigo descreve alguns dos recursos do Azure Front Door que são úteis quando você trabalha em sistemas multilocatário. Também fornece ligações para orientações e exemplos adicionais.

Quando você usa o Azure Front Door como parte de uma solução multilocatário, precisa tomar algumas decisões com base no design e nos requisitos da sua solução. Você precisa considerar os seguintes fatores:

  • Quantos inquilinos tem e quantos espera ter no futuro?
  • Você compartilha sua camada de aplicativo entre vários locatários, implanta muitas instâncias de aplicativo de locatário único ou implanta carimbos de implantação separados que são compartilhados por vários locatários?
  • Os seus inquilinos querem trazer os seus próprios nomes de domínio?
  • Você usará domínios curinga?
  • Você precisa usar seus próprios certificados TLS ou a Microsoft gerenciará seus certificados TLS?
  • Já considerou as quotas e limites que se aplicam ao Azure Front Door? Sabe quais os limites que vai abordar à medida que cresce? Se você suspeitar que vai se aproximar desses limites, considere usar vários perfis do Azure Front Door. Ou considere se você pode alterar a maneira como usa o Azure Front Door para evitar os limites. Observe que o SKU Premium tem limites mais altos do que o SKU Padrão.
  • Você ou seus locatários têm requisitos para filtragem de endereços IP, bloqueio geográfico ou personalização de regras WAF?
  • Todos os servidores de aplicativos dos seus locatários estão voltados para a Internet?

Recursos do Azure Front Door que oferecem suporte a multilocação

Esta seção descreve vários recursos principais do Azure Front Door que são úteis para soluções multilocatário. Ele descreve como o Azure Front Door pode ajudá-lo a configurar domínios personalizados, incluindo informações sobre domínios curinga e certificados TLS. Ele também resume como você pode usar os recursos de roteamento do Azure Front Door para dar suporte à multilocação.

Domínios personalizados

O Azure Front Door fornece um nome de host padrão para cada ponto de extremidade que você criar, por exemplo, contoso.z01.azurefd.net. Para a maioria das soluções, você associa seu próprio nome de domínio ao ponto de extremidade da Porta da Frente do Azure. Os nomes de domínio personalizados permitem que você use sua própria marca e configure o roteamento com base no nome do host fornecido na solicitação de um cliente.

Em uma solução multilocatário, você pode usar nomes de domínio ou subdomínios específicos do locatário e configurar o Azure Front Door para rotear o tráfego do locatário para o grupo de origem correto para a carga de trabalho desse locatário. Por exemplo, você pode configurar um nome de domínio personalizado como tenant1.app.contoso.com. Com o Azure Front Door, você pode configurar vários domínios personalizados em um único perfil do Azure Front Door.

Para obter mais informações, veja Adicionar um domínio personalizado ao Front Door.

Domínios curinga

Os domínios curinga simplificam a configuração de registros DNS e a configuração de roteamento de tráfego da Porta da Frente do Azure quando você usa um domínio tronco compartilhado e subdomínios específicos do locatário. Por exemplo, suponha que seus locatários acessem seus aplicativos usando subdomínios como tenant1.app.contoso.com e tenant2.app.contoso.com. Você pode configurar um domínio curinga, *.app.contoso.com, em vez de configurar cada domínio específico do locatário individualmente.

O Azure Front Door dá suporte à criação de domínios personalizados que usam curingas. Em seguida, você pode configurar uma rota para solicitações que chegam no domínio curinga. Ao integrar um novo locatário, você não precisa reconfigurar seus servidores DNS, emitir novos certificados TLS ou atualizar a configuração do seu perfil do Azure Front Door.

Os domínios curinga funcionam bem se você enviar todo o seu tráfego para um único grupo de origem. Mas se você tiver carimbos separados de sua solução, um domínio curinga de nível único não será suficiente. Você precisa usar domínios tronco de vários níveis ou fornecer configuração extra, por exemplo, substituindo as rotas a serem usadas para cada subdomínio do locatário. Para obter mais informações, consulte Considerações ao usar nomes de domínio em uma solução multilocatário.

O Azure Front Door não emite certificados TLS gerenciados para domínios curinga, portanto, você precisa comprar e fornecer seu próprio certificado.

Para obter mais informações, consulte Domínios curinga.

Certificados TLS gerenciados

Adquirir e instalar certificados TLS pode ser complexo e propenso a erros. E os certificados TLS expiram após um período de tempo, geralmente um ano, e precisam ser reemitidos e reinstalados para evitar interrupções no tráfego de aplicativos. Quando você usa certificados TLS gerenciados pelo Azure Front Door, a Microsoft é responsável por emitir, instalar e renovar certificados para seu domínio personalizado.

Seu aplicativo de origem pode estar hospedado em outro serviço do Azure que também fornece certificados TLS gerenciados, como o Serviço de Aplicativo do Azure. O Azure Front Door funciona de forma transparente com o outro serviço para sincronizar seus certificados TLS.

Se você permitir que seus locatários forneçam seus próprios domínios personalizados e quiser que o Azure Front Door emita certificados para esses nomes de domínio, seus locatários não devem configurar registros CAA em seus servidores DNS que possam impedir o Azure Front Door de emitir certificados em seu nome. Para obter mais informações, consulte Certificados TLS/SSL.

Para obter mais informações sobre certificados TLS, consulte TLS de ponta a ponta com a porta frontal do Azure.

Encaminhamento

Um aplicativo multilocatário pode ter um ou mais carimbos de aplicativo que atendem aos locatários. Os carimbos são frequentemente usados para permitir implantações em várias regiões e para dar suporte ao dimensionamento de uma solução para um grande número de locatários.

O Azure Front Door tem um poderoso conjunto de recursos de roteamento que podem dar suporte a várias arquiteturas multilocatário. Você pode usar o roteamento para distribuir o tráfego entre origens dentro de um carimbo ou para enviar o tráfego para o carimbo correto para um locatário específico. Você pode configurar o roteamento com base em nomes de domínio individuais, nomes de domínio curinga e caminhos de URL. E você pode usar o mecanismo de regras para personalizar ainda mais o comportamento de roteamento.

Para obter mais informações, consulte Visão geral da arquitetura de roteamento.

Motor de regras

Você pode usar o mecanismo de regras do Azure Front Door para personalizar como o Azure Front Door processa solicitações na borda da rede. O mecanismo de regras permite executar pequenos blocos de lógica dentro do pipeline de processamento de solicitações do Azure Front Door. Você pode usar o mecanismo de regras para uma variedade de tarefas, incluindo as seguintes:

  • Recupere informações sobre a solicitação HTTP, incluindo segmentos da URL e do caminho, e propague as informações para outra parte da solicitação.
  • Modifique elementos da solicitação HTTP antes que ela seja enviada para a origem.
  • Modifique algumas partes da resposta HTTP antes que ela seja retornada ao cliente.
  • Substitua a configuração de roteamento de uma solicitação, por exemplo, alterando o grupo de origem para o qual uma solicitação deve ser enviada.

Aqui estão alguns exemplos de abordagens para usar o mecanismo de regras do Azure Front Door em uma solução multilocatário:

  • Suponha que você implante uma camada de aplicativo multilocatário na qual também use subdomínios curinga específicos do locatário, conforme descrito nos cenários de exemplo a seguir. Você pode usar o mecanismo de regras para extrair o identificador de locatário do subdomínio de solicitação e adicioná-lo a um cabeçalho de solicitação. Essa regra pode ajudar a camada de aplicativo a determinar de qual locatário a solicitação veio.
  • Suponha que você implante uma camada de aplicativo multilocatário e use o roteamento baseado em caminho (por exemplo, https://application.contoso.com/tenant1/welcome e https://application.contoso.com/tenant2/welcome para os locatários 1 e 2, respectivamente). Você pode usar o mecanismo de regras para extrair o segmento de identificador de locatário do segmento de caminho de URL e reescrever a URL para incluir o identificador de locatário em um parâmetro de cadeia de caracteres de consulta ou cabeçalho de solicitação para o aplicativo consumir.

Para obter mais informações, consulte O que é o mecanismo de regras do Azure Front Door?.

Cenários de exemplo

Os cenários de exemplo a seguir ilustram como você pode configurar várias arquiteturas multilocatárias no Azure Front Door e como as decisões tomadas podem afetar sua configuração de DNS e TLS.

Muitas soluções multilocatárias implementam o padrão Deployment Stamps. Quando você usa essa abordagem de implantação, normalmente implanta um único perfil compartilhado da Porta da Frente do Azure e usa a Porta da Frente do Azure para rotear o tráfego de entrada para o carimbo apropriado. Esse modelo de implantação é o mais comum, e os cenários 1 a 4 deste artigo mostram como você pode usá-lo para atender a uma variedade de requisitos.

Em algumas situações, no entanto, você pode implantar um perfil do Azure Front Door em cada carimbo de sua solução. O cenário 5 descreve esse modelo de implantação.

Cenário 1: Domínio curinga gerenciado pelo provedor, carimbo único

A Contoso está criando uma pequena solução multilocatário. A empresa implanta um único selo em uma única região, e esse selo atende a todos os seus lojistas. Todas as solicitações são roteadas para o mesmo servidor de aplicativos. A Contoso decidiu usar domínios curinga para todos os locatários, como tenant1.contoso.com e tenant2.contoso.com.

A Contoso implanta o Azure Front Door usando esta configuração:

Diagrama que mostra uma configuração da Porta da Frente do Azure que tem um único domínio, rota e grupo de origem personalizados e um certificado TLS curinga no Cofre da Chave do Azure.

Configuração do DNS

Configuração única: a Contoso configura duas entradas DNS:

  • Um registro TXT curinga para *.contoso.com. Ele é definido como o valor especificado pelo Azure Front Door durante o processo de integração de domínio personalizado.
  • Um registro CNAME curinga, *.contoso.com, que é um alias para o ponto de extremidade da Porta da Frente do Azure da Contoso: contoso.z01.azurefd.net.

Quando um novo locatário é integrado: nenhuma configuração adicional é necessária.

Configuração do TLS

Configuração única: a Contoso compra um certificado TLS curinga, adiciona-o a um cofre de chaves e concede acesso à Porta da Frente do Azure ao cofre.

Quando um novo locatário é integrado: nenhuma configuração adicional é necessária.

Configuração do Azure Front Door

Configuração única: a Contoso cria um perfil de Porta de Entrada do Azure e um único ponto de extremidade. Eles adicionam um domínio personalizado com o nome *.contoso.com e associam seu certificado TLS curinga ao recurso de domínio personalizado. Em seguida, eles configuram um único grupo de origem que contém uma única origem para seu servidor de aplicativos. Finalmente, eles configuram uma rota para conectar o domínio personalizado ao grupo de origem.

Quando um novo locatário é integrado: nenhuma configuração adicional é necessária.

Benefícios

  • Essa configuração é relativamente fácil de configurar e fornece aos clientes URLs da marca Contoso.
  • A abordagem suporta um grande número de inquilinos.
  • Quando um novo locatário é integrado, a Contoso não precisa fazer alterações nos certificados do Azure Front Door, DNS ou TLS.

Desvantagens

  • Essa abordagem não pode ser facilmente dimensionada além de um único carimbo de aplicativo ou região.
  • A Contoso precisa comprar um certificado TLS curinga e renovar e instalar o certificado quando ele expirar.

Cenário 2: Domínio curinga gerenciado pelo provedor, vários carimbos

A Proseware está construindo uma solução multilocatária em vários selos que são implantados na Austrália e na Europa. Todos os pedidos dentro de uma única região são atendidos pelo carimbo nessa região. Como a Contoso, a Proseware decidiu usar domínios curinga para todos os locatários, como tenant1.proseware.com e tenant2.proseware.com.

O Proseware implanta o Azure Front Door usando esta configuração:

Diagrama que mostra uma configuração da Porta da Frente do Azure que tem vários domínios, rotas e grupos de origem personalizados e um certificado TLS curinga no Cofre da Chave.

Configuração do DNS

Configuração única: o Proseware configura duas entradas DNS:

  • Um registro TXT curinga para *.proseware.com. Ele é definido como o valor especificado pelo Azure Front Door durante o processo de integração de domínio personalizado.
  • Um registro CNAME curinga, *.proseware.com, que é um alias para o ponto de extremidade Azure Front Door do Proseware: proseware.z01.azurefd.net.

Quando um novo locatário é integrado: nenhuma configuração adicional é necessária.

Configuração do TLS

Configuração única: o Proseware compra um certificado TLS curinga, adiciona-o a um cofre de chaves e concede acesso ao cofre do Azure Front Door.

Quando um novo locatário é integrado: nenhuma configuração adicional é necessária.

Configuração do Azure Front Door

Configuração única: o Proseware cria um perfil do Azure Front Door e um único ponto de extremidade. A empresa configura vários grupos de origem, um por carimbo/servidor de aplicativo em cada região.

Quando um novo locatário é integrado: o Proseware adiciona um recurso de domínio personalizado ao Azure Front Door. Eles usam o nome *.proseware.com e associam seu certificado TLS curinga ao recurso de domínio personalizado. Em seguida, eles criam uma rota para especificar para qual grupo de origem (carimbo) as solicitações do locatário devem ser direcionadas. No diagrama anterior, tenant1.proseware.com rotas para o grupo de origem na região da Austrália e tenant2.proseware.com rotas para o grupo de origem na região da Europa.

Benefícios

  • Quando novos locatários são integrados, nenhuma alteração de configuração de DNS ou TLS é necessária.
  • O Proseware mantém uma única instância do Azure Front Door para rotear o tráfego para vários carimbos em várias regiões.

Desvantagens

  • O Proseware precisa reconfigurar o Azure Front Door sempre que um novo locatário é integrado.
  • O Proseware precisa prestar atenção às cotas e limites do Azure Front Door, especialmente no número de rotas e domínios personalizados e no limite de roteamento composto.
  • Proseware precisa comprar um certificado TLS curinga.
  • Proseware é responsável por renovar e instalar o certificado quando ele expira.

Cenário 3: Subdomínios curinga baseados em selos gerenciados pelo provedor

A Fabrikam está criando uma solução multilocatário. A empresa implanta selos na Austrália e nos Estados Unidos. Todos os pedidos dentro de uma única região serão atendidos pelo carimbo nessa região. A Fabrikam usará domínios de tronco baseados em selos, como tenant1.australia.fabrikam.com, tenant2.australia.fabrikam.come tenant3.us.fabrikam.com.

A empresa implanta o Azure Front Door usando esta configuração:

Diagrama que mostra uma configuração do Azure Front Door que tem vários domínios de tronco baseados em carimbo personalizados, rotas, grupos de origem e certificado TLS curinga no Cofre da Chave.

Configuração do DNS

Configuração única: a Fabrikam configura as duas entradas DNS curinga a seguir para cada carimbo.

  • Um registro TXT curinga para cada carimbo: *.australia.fabrikam.com e *.us.fabrikam.com. Eles são definidos com os valores especificados pelo Azure Front Door durante o processo de integração de domínio personalizado.
  • Um registro CNAME curinga para cada carimbo *.australia.fabrikam.com e *.us.fabrikam.com, que são ambos aliases para o ponto de extremidade da Porta da Frente do Azure: fabrikam.z01.azurefd.net.

Quando um novo locatário é integrado: nenhuma configuração adicional é necessária.

Configuração do TLS

Configuração única: a Fabrikam compra um certificado TLS curinga para cada carimbo, adiciona-os a um cofre de chaves e concede ao Azure Front Door acesso ao cofre.

Quando um novo locatário é integrado: nenhuma configuração adicional é necessária.

Configuração do Azure Front Door

Configuração única: a Fabrikam cria um perfil do Azure Front Door e um único ponto de extremidade. Eles configuram um grupo de origem para cada selo. Eles criam domínios personalizados, usando um curinga, para cada subdomínio baseado em carimbo: *.australia.fabrikam.com e *.us.fabrikam.com. Eles criam uma rota para o domínio personalizado de cada selo para enviar tráfego para o grupo de origem apropriado.

Quando um novo locatário é integrado: nenhuma configuração adicional é necessária.

Benefícios

  • Essa abordagem permite que a Fabrikam seja dimensionada para um grande número de locatários em vários selos.
  • Quando novos locatários são integrados, nenhuma alteração de configuração de DNS ou TLS é necessária.
  • A Fabrikam mantém uma única instância do Azure Front Door para rotear o tráfego para vários carimbos em várias regiões.

Desvantagens

  • Como as URLs usam uma estrutura de domínio de tronco com várias partes, as URLs podem ser mais complexas para os usuários trabalharem.
  • A Fabrikam precisa comprar vários certificados TLS curinga.
  • A Fabrikam é responsável pela renovação e instalação dos certificados TLS quando eles expiram.

Cenário 4: Domínios de vaidade

A Adventure Works Cycles está criando uma solução multilocatário. A empresa implanta selos em várias regiões, como Austrália e Estados Unidos. Todos os pedidos dentro de uma única região serão atendidos pelo carimbo nessa região. A Adventure Works permitirá que seus locatários tragam seus próprios nomes de domínio. Por exemplo, o locatário 1 pode configurar um nome de domínio personalizado como tenant1app.tenant1.com.

A empresa implanta o Azure Front Door usando esta configuração:

Diagrama que mostra uma configuração do Azure Front Door que tem vários domínios, rotas e grupos de origem personalizados e uma combinação de certificados TLS no Key Vault e certificados TLS gerenciados pelo Azure Front Door.

Configuração do DNS

Configuração única: Nenhuma.

Quando um novo locatário é integrado: o locatário precisa criar dois registros em seu próprio servidor DNS:

  • Um registro TXT para validação de domínio. Por exemplo, o locatário 1 precisa configurar um registro TXT chamado tenant1app.tenant1.com e defini-lo com o valor especificado pelo Azure Front Door durante o processo de integração de domínio personalizado.
  • Um registro CNAME com alias para o ponto de extremidade da Porta da Frente do Azure da Adventure Works. Por exemplo, o locatário 1 precisa configurar um registro CNAME chamado tenant1app.tenant1.com e mapeá-lo para adventureworks.z01.azurefd.net.

Configuração do TLS

A Adventure Works e seus locatários precisam decidir quem emite certificados TLS:

  • A opção mais fácil é usar o Azure Front Door para emitir e gerenciar os certificados, mas os locatários não devem configurar registros CCA em seus servidores DNS. Se isso acontecer, os registros podem impedir que a autoridade de certificação do Azure Front Door emita certificados.
  • Em alternativa, os inquilinos podem fornecer os seus próprios certificados. Eles precisam trabalhar com a Adventure Works para carregar o certificado em um cofre de chaves e fornecer acesso ao Azure Front Door.

Configuração do Azure Front Door

Configuração única: a Adventure Works cria um perfil de Porta de Entrada do Azure e um único ponto de extremidade. Eles configuram um grupo de origem para cada selo. Eles não criam recursos de domínio personalizados ou rotas.

Quando um novo locatário é integrado: a Adventure Works adiciona um recurso de domínio personalizado ao Azure Front Door. Eles usam o nome de domínio fornecido pelo locatário e associam o certificado TLS apropriado ao recurso de domínio personalizado. Em seguida, eles criam uma rota para especificar para qual grupo de origem (carimbo) as solicitações do locatário devem ser direcionadas. No diagrama anterior, tenant1app.tenant1.com é roteado para o grupo de origem na região da Austrália e tenant2app.tenant3.com é roteado para o grupo de origem na região dos EUA.

Benefícios

  • Os clientes podem fornecer seus próprios nomes de domínio. O Azure Front Door encaminha de forma transparente as solicitações para a solução multilocatário.
  • A Adventure Works mantém uma única instância do Azure Front Door para rotear o tráfego para vários carimbos em várias regiões.

Desvantagens

  • A Adventure Works precisa reconfigurar o Azure Front Door sempre que um novo locatário é integrado.
  • Os inquilinos precisam estar envolvidos no processo de integração. Eles precisam fazer alterações de DNS e, possivelmente, emitir certificados TLS.
  • Os locatários controlam seus registros DNS. Alterações nos registros DNS podem afetar sua capacidade de acessar a solução Adventure Works.
  • A Adventure Works precisa prestar atenção às cotas e limites do Azure Front Door, especialmente no número de rotas e domínios personalizados e no limite de roteamento composto.

Cenário 5: Perfil do Azure Front Door por carimbo

Você pode implantar um perfil do Azure Front Door para cada carimbo. Se você tiver 10 carimbos, implantará 10 instâncias do Azure Front Door. Essa abordagem pode ser útil se você precisar restringir o acesso de gerenciamento da configuração da Porta da Frente do Azure de cada selo. Também pode ser útil se você precisar usar vários perfis do Azure Front Door para evitar exceder as cotas ou limites de recursos.

Gorjeta

O Azure Front Door é um recurso global. Mesmo se você implantar carimbos com escopo regional, cada perfil do Azure Front Door será distribuído globalmente. Você deve considerar se realmente precisa implantar vários perfis do Azure Front Door e quais vantagens você ganha ao fazer isso.

Se você tiver um carimbo que atenda a vários locatários, precisará considerar como rotear o tráfego para cada locatário. Analise as abordagens descritas nos cenários anteriores e considere combinar abordagens para atender às suas necessidades.

Benefícios

  • Se você estender sua configuração em vários perfis, é menos provável que atinja os limites de recursos do Azure Front Door. Por exemplo, se você precisar dar suporte a um grande número de domínios personalizados, poderá dividir os domínios entre vários perfis do Azure Front Door e permanecer dentro dos limites de cada perfil.
  • Essa abordagem permite que você defina o escopo de suas permissões de gerenciamento de recursos do Azure Front Door. Você pode usar o RBAC (controle de acesso baseado em função) do Azure para conceder aos administradores acesso a um único perfil de carimbo.

Desvantagens

  • Essa abordagem normalmente incorre em um alto custo porque você implanta mais perfis. Para obter mais informações, consulte Compreender o faturamento da porta da frente.
  • Há um limite para o número de perfis do Azure Front Door que você pode implantar em uma única assinatura do Azure. Para obter mais informações, consulte Cotas e limites da porta da frente.
  • Você precisa configurar o perfil da Porta da Frente do Azure de cada carimbo separadamente e precisa gerenciar a configuração de DNS, certificados TLS e configuração TLS para cada carimbo.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Principais autores:

  • Raj Nemani - Brasil | Diretor, Estrategista de Tecnologia de Parceiros
  • John Downs - Brasil | Engenheiro de Software Principal

Outros contribuidores:

Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.

Próximos passos