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

O Azure Front Door é uma rede de distribuição de conteúdo (CDN) em nuvem moderna, 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ários. Ele também fornece links para diretrizes e exemplos adicionais.

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

• Quantos locatários você tem e quantos espera ter no futuro?
• Você compartilha sua camada de aplicativo entre múltiplos locatários, implanta muitas instâncias de aplicativo de locatário único ou implanta selos de implantação separados que são compartilhados por múltiplos locatários?
• Seus locatários desejam trazer 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?
• Você já considerou as cotas e os limites que se aplicam ao Azure Front Door? Você sabe quais limites abordará à medida que crescer? Se você suspeitar que se aproximará desses limites, considere usar vários perfis do Azure Front Door. Ou considere se você poderá alterar a maneira como usará o Azure Front Door para evitar os limites. A SKU Premium tem limites mais altos do que a 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 do WAF?
• Todos os servidores de aplicativos de seus locatários estão voltados para a Internet?

Recursos do Azure Front Door que dão suporte à multilocação

Esta seção descreve vários recursos principais do Azure Front Door que são úteis para soluções multilocatário. Ela descreve como o Azure Front Door pode ajudá-lo a configurar domínios personalizados, incluindo informações sobre domínios curinga e certificados TLS. Ela 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 criado; 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 do Azure Front Door. Os nomes de domínio personalizados permitem que você use sua própria identidade visual 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, confira Adicionar um domínio personalizado ao seu 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 do Azure Front Door quando você usa um domínio-tronco compartilhado e subdomínios específicos do locatário. Por exemplo, suponha que seus locatários acessem os 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 o domínio específico de cada locatário individualmente.

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

Os domínios curinga funcionarão bem se você enviar todo o seu tráfego para um único grupo de origem. Porém, se você tiver selos 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 o subdomínio de cada 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

A aquisição e instalação de certificados TLS podem ser complexas e propensas 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ção no tráfego de aplicativo. Quando você usa certificados TLS gerenciados pelo Azure Front Door, a Microsoft é responsável por emitir, instalar e renovar os certificados para seu domínio personalizado.

Seu aplicativo de origem pode ser hospedado em outro serviço do Azure que também fornece certificados TLS gerenciados, como o Serviço de Aplicativos 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 deverão configurar registros CAA nos 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 os certificados TLS, consulte TLS de ponta a ponta com o Azure Front Door.

Roteamento

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

O Azure Front Door tem um conjunto poderoso de recursos de roteamento que pode dar suporte a várias arquiteturas multilocatário. Você pode usar o roteamento para distribuir o tráfego entre origens dentro de um selo ou para enviar o tráfego para o selo correto de 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. Além disso, 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.

Mecanismo de regras

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

• Recuperar informações sobre a solicitação HTTP, incluindo segmentos da URL e do caminho, e propagar as informações para outra parte da solicitação.
• Modificar os elementos da solicitação HTTP antes que ela seja enviada para a origem.
• Modificar algumas partes da resposta HTTP antes que ela seja retornada ao cliente.
• Substituir 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.

Veja abaixo 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, como 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 poderá 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 do identificador do locatário do segmento do caminho da URL e reescrever a URL para incluir o identificador do 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ário no Azure Front Door e como as decisões tomadas podem afetar a configuração de DNS e TLS.

Muitas soluções multilocatário implementam o padrão de Selos de Implantação. Ao usar essa abordagem de implantação, você geralmente implantará um perfil compartilhado único do Azure Front Door e usará o Azure Front Door para rotear o tráfego de entrada para o selo apropriado. Esse modelo de implantação é o mais comum, e os cenários 1 a 4 deste artigo mostram como você pode usar esse modelo para atender a uma variedade de requisitos.

No entanto, em algumas situações, você poderá implantar um perfil do Azure Front Door em cada selo da sua solução. O Cenário 5 descreve esse modelo de implantação.

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

A Contoso está criando uma pequena solução multilocatário. A empresa implanta um selo único em uma única região, e esse selo atende a todos os seus locatários. 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:

Configuração de DNS

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

• Um registro TXT curinga para *.contoso.com. Ele é definido para o valor que foi 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 do Azure Front Door da Contoso: contoso.z01.azurefd.net.

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

Configuração TLS

Configuração única: a Contoso compra um certificado TLS curinga, adiciona-o 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 Contoso cria um perfil do Azure Front Door e um único ponto de extremidade. A empresa adiciona um domínio personalizado com o nome *.contoso.com e associa 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 o 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 definir e fornece aos clientes URLs com a marca Contoso.
• A abordagem tem suporte para um grande número de locatários.
• Quando um novo locatário é integrado, a Contoso não precisa fazer alterações no Azure Front Door, no DNS ou nos certificados TLS.

Desvantagens

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

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

A Proseware está criando uma solução multilocatário em vários selos que são implantados na Austrália e na Europa. Todas as solicitações dentro de uma única região são atendidas pelo selo dessa região. Assim como a Contoso, a Proseware decidiu usar domínios curinga para todos os locatários, como tenant1.proseware.com e tenant2.proseware.com.

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

Configuração de DNS

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

• Um registro TXT curinga para *.proseware.com. Ele é definido para o valor que foi 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 do Azure Front Door da Proseware: proseware.z01.azurefd.net.

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

Configuração TLS

Configuração única: a Proseware compra um certificado TLS curinga, adiciona-o 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 Proseware cria um perfil do Azure Front Door e um único ponto de extremidade. A empresa configura vários grupos de origem, um por selo/servidor de aplicativo em cada região.

Quando um novo locatário é integrado: a Proseware adiciona um recurso de domínio personalizado ao Azure Front Door. A empresa usa o nome *.proseware.com e associa seu certificado TLS curinga ao recurso de domínio personalizado. Em seguida, ela cria uma rota para especificar para qual grupo de origem (selo) as solicitações do locatário devem ser direcionadas. No diagrama anterior, tenant1.proseware.com direciona para o grupo de origem na região da Austrália e tenant2.proseware.com direciona 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.
• A Proseware mantém uma única instância do Azure Front Door para rotear o tráfego para vários selos em várias regiões.

Desvantagens

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

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

A Fabrikam está criando uma solução multilocatário. A empresa implanta selos na Austrália e nos Estados Unidos. Todas as solicitações dentro de uma única região serão atendidas pelo selo dessa região. A Fabrikam usará domínios-tronco baseados em selos, como tenant1.australia.fabrikam.com, tenant2.australia.fabrikam.com e tenant3.us.fabrikam.com.

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

Configuração de DNS

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

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

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

Configuração TLS

Configuração única: a Fabrikam compra um certificado TLS curinga para cada selo, adiciona-o 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. A empresa configura um grupo de origem para cada selo. Ela cria domínios personalizados, usando um curinga, para cada subdomínio baseado em selo: *.australia.fabrikam.com e *.us.fabrikam.com. Ela cria uma rota para o domínio personalizado de cada selo, a fim de 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 selos em várias regiões.

Desvantagens

• Como as URLs usam uma estrutura de domínio-tronco de várias partes, elas podem ser mais complexas para os usuários trabalharem.
• A Fabrikam precisa comprar vários certificados TLS curinga.
• A Fabrikam é responsável por renovar e instalar os certificados TLS quando eles expiram.

Cenário 4: Domínios intuitivos

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. Todas as solicitações dentro de uma única região serão atendidas pelo selo dessa 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:

Configuração de DNS

Configuração única: nenhuma.

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

• Um registro TXT para validação de domínio. Por exemplo, o locatário 1 precisa configurar um registro TXT denominado 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 do Azure Front Door da Adventure Works. Por exemplo, o locatário 1 precisa configurar um registro CNAME denominado tenant1app.tenant1.com e mapeá-lo para adventureworks.z01.azurefd.net.

Configuração TLS

A Adventure Works e seus locatários precisam decidir quem emitirá os 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 nos servidores DNS. Se isso acontecer, os registros poderão impedir a autoridade de certificação do Azure Front Door de emitir certificados.
• Como alternativa, os locatários poderão fornecer seus próprios certificados. Eles precisam trabalhar com a Adventure Works para carregar o certificado para 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 do Azure Front Door e um único ponto de extremidade. A empresa configura um grupo de origem para cada selo. A empresa não cria recursos ou rotas de domínio personalizado.

Quando um novo locatário é integrado: a Adventure Works adiciona um recurso de domínio personalizado ao Azure Front Door. Ela usa o nome de domínio fornecido pelo locatário e associa o certificado TLS apropriado ao recurso de domínio personalizado. Em seguida, ela cria uma rota para especificar para qual grupo de origem (selo) 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 roteia solicitações de forma transparente 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 selos em várias regiões.

Desvantagens

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

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

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

Se você tiver um selo que atenda a múltiplos locatários, precisará considerar como rotear o tráfego para cada locatário. Analise as abordagens descritas nos cenários anteriores e considere combiná-las de forma que atendam às suas necessidades.

Benefícios

• Se você estender a configuração em vários perfis, será 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 definir 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 perfil de selo único.

Desvantagens

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

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Principais autores:

• Raj Nemani | Diretor, Estrategista de Tecnologia de Parceiros
• John Downs | Engenheiro de software principal

Outros colaboradores:

• Mick Alberts | Escritor Técnico
• Fernando Antivero | Desenvolvedor de Pilha Completa e Engenheiro de Plataforma de Nuvem
• Duong Au | Desenvolvedor Sênior de Conteúdo, P&D de Conteúdo de Habilidades C+E
• Harikrishnan M B (HARI) | Gerente de Produto 2, Rede do Azure
• Arsen Vladimirskiy | Engenheiro principal de atendimento ao cliente, FastTrack for Azure

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

Próximas etapas

• Treinamento: Introdução ao Azure Front Door
• Introdução ao Azure Front Door
• O que é o Azure Front Door?

Recursos relacionados

• Arquitetar soluções multilocatários no Azure
• Lista de verificação para arquitetar e criar soluções multilocatário no Azure
• Modelos de locação a serem considerados para uma solução multilocatário