Hospedagem de sites do Gateway de Aplicativo
A hospedagem de vários sites permite que você configure mais de um aplicativo Web na mesma porta de gateways de aplicativo, usando ouvintes voltados para o público. Permite que você configure a topologia mais eficiente para suas implantações adicionando até mais de 100 sites a um gateway de aplicativo. Cada site pode ser direcionado para seu próprio pool de back-end. Por exemplo, três domínios, contoso.com, fabrikam.com e adatum.com, apontam para o endereço IP do gateway de aplicativo. Você criaria três ouvintes com vários sites e configuraria cada ouvinte para as respectivas configurações de porta e protocolo.
Você também pode definir nomes do host curinga em um ouvinte com vários sites e até cinco nomes do host por ouvinte. Para saber mais, confira nomes do host curinga em ouvinte.
Importante
As regras são processadas na ordem em que estão listadas no portal para a SKU v1. Para o SKU v2, use a prioridade de regra para especificar a ordem de processamento. É altamente recomendável configurar primeiro os ouvintes de vários locais para configurar um ouvinte básico. Isso garante que o tráfego seja roteado para o back-end correto. Se um ouvinte básico for listado primeiro e corresponder a uma solicitação de entrada, ele é processado por esse ouvinte.
As solicitações de http://contoso.com são encaminhadas para ContosoServerPool, e as de http://fabrikam.com são encaminhadas para FabrikamServerPool.
Da mesma forma, você pode hospedar vários subdomínios do mesmo domínio pai na mesma implantação do gateway de aplicativo. Por exemplo, você pode hospedar http://blog.contoso.com e http://app.contoso.com em uma única implantação de gateway de aplicativo.
Ordem de avaliação de regras de roteamento de solicitação
Quando você usar ouvintes de vários sites para garantir que o tráfego do cliente seja roteado para o backend correto, é importante que as regras de roteamento de solicitações estejam presentes na ordem correta.
Por exemplo, se você tiver dois ouvintes com nomes de host associados de *.contoso.com e shop.contoso.com, o ouvinte com o nome do host shop.contoso.com deverá ser processado antes do ouvinte com *.contoso.com. Se o ouvinte com *.contoso.com for processado primeiro, nenhum tráfego de cliente será recebido pelo ouvinte de shop.contoso.com mais específico.
A ordenação de regras pode ser estabelecida fornecendo um valor de campo Prioridade para as regras de roteamento de solicitação associadas aos ouvintes. Você pode especificar um valor inteiro entre 1 e 20.000, em que 1 é a prioridade mais baixa e 20.000 é a mais alta. Se o tráfego de entrada do cliente corresponder a vários ouvintes, a regra de roteamento de solicitação com prioridade mais alta será usada para atender a solicitação. Cada regra de roteamento de solicitação precisa ter um valor de prioridade exclusivo.
O campo de prioridade afeta apenas a ordem de avaliação de uma regra de roteamento de solicitação. Isso não alterará a ordem de avaliação das regras baseadas em caminho dentro de uma regra de roteamento de solicitação PathBasedRouting.
Observação
Para usar a prioridade de regra, você deve especificar valores de campo de prioridade de regra para todas as regras de roteamento de solicitação existentes. Depois que o campo de prioridade de regra estiver em uso, qualquer nova regra de roteamento criada deverá ter um valor de campo de prioridade de regra como parte da sua configuração.
Importante
A partir da versão 2021-08-01 da API, o campo de prioridade de regra seria um campo obrigatório como parte das regras de roteamento de solicitação. Os valores do campo de prioridade de regra das regras de roteamento de solicitação existentes com base na ordem atual, serão preenchidos automaticamente se as atualizações de configuração forem aplicadas usando a API versão 2021-08-01 e superior, o portal, o Azure PowerShell e a CLI do Azure. As atualizações futuras para solicitar regras de roteamento devem ter o campo de prioridade da regra fornecido como parte da configuração.
Nomes do host curinga em ouvinte
O Gateway de Aplicativo permite o roteamento baseado em host usando o ouvinte de HTTP(S) de vários sites. Agora, você pode usar caracteres curinga, como asterisco (*) e ponto de interrogação (?), no nome do host e até cinco nomes de host por ouvinte HTTP(S) de vários sites. Por exemplo, *.contoso.com.
Usando um caractere curinga no nome do host, você pode corresponder a vários nomes do host em um único ouvinte. Por exemplo, *.contoso.com pode corresponder a ecom.contoso.com, b2b.contoso.com, customer1.b2b.contoso.com e assim por diante. Usando uma matriz de nomes do host, você pode configurar mais de um para um ouvinte, a fim de rotear solicitações para um pool de back-end. Por exemplo, um ouvinte pode conter contoso.com, fabrikam.com, o qual aceita solicitações para ambos os nomes de host.
Observação
Esse recurso está disponível somente para o SKU Standard_v2 e o WAF_v2 do Gateway de Aplicativo.
No Azure PowerShell, você deve usar -HostNames em vez de -HostName. Com HostNames, você pode mencionar até cinco nomes do host como valores separados por vírgulas e usar caracteres curinga. Por exemplo, -HostNames "*.contoso.com","*.fabrikam.com".
Na CLI do Azure, você deve usar --host-names em vez de --host-name. Com nomes do host, você pode mencionar até cinco nomes do host como valores separados por vírgulas e usar caracteres curinga. Por exemplo, --host-names "*.contoso.com,*.fabrikam.com".
No portal do Azure, no ouvinte de vários sites, você deve escolher o tipo de host Vários/Curinga para mencionar até cinco nomes de host com caracteres curinga permitidos.
Caracteres permitidos no campo de nomes de host
(A-Z,a-z,0-9)– caracteres alfanuméricos-– hífen ou sinal de menos.– ponto como delimitador*– pode corresponder com vários caracteres no intervalo permitido?– pode corresponder a um único caractere no intervalo permitido
Condições para usar caracteres curinga e vários nomes de host em um ouvinte
- Só é possível mencionar até cinco nomes do host em um único ouvinte
- O asterisco
*pode ser mencionado apenas uma vez em um componente de nome de estilo de domínio ou nome do host. Por exemplo, component1*.component2*.component3.(*.contoso-*.com)é válido. - Só pode haver até dois asteriscos
*em um nome do host. Por exemplo,*.contoso.*é válido e*.contoso.*.*.comé inválido. - Pode haver no máximo quatro caracteres curinga em um nome do host. Por exemplo,
????.contoso.com,w??.contoso*.edu.*são válidos, mas????.contoso.*é inválido. - O uso de asterisco
*e ponto de interrogação?juntos em um componente de nome do host (*?ou?*ou**) é inválido. Por exemplo:*?.contoso.come**.contoso.comsão inválidos.
Considerações e limitações ao usar caracteres curinga ou vários nomes de host em um ouvinte
- A terminação SSL e o SSL de ponta a ponta exigem que você configure o protocolo como HTTPS e carregue um certificado a ser usado na configuração do ouvinte. Se for um ouvinte de vários sites, você também poderá inserir o nome do host, geralmente esse é o CN do certificado SSL. Ao especificar vários nomes do host no ouvinte ou usar caracteres curinga, você deve considerar o seguinte:
- Se for um nome de host curinga como *.contoso.com, você deverá carregar um certificado curinga com CN como *.contoso.com
- Se vários nomes de host forem mencionados no mesmo ouvinte, você deverá carregar um certificado de SAN (Nomes Alternativos da Entidade) com os CNs correspondentes aos nomes do host mencionados.
- Você não pode usar uma expressão regular para mencionar o nome do host. Só é possível usar caracteres curinga, como asterisco (*) e ponto de interrogação (?) para formar o padrão de nome do host.
- Para a verificação de integridade de back-end, não é possível associar várias investigações personalizadas por configurações de HTTP. Em vez disso, você pode investigar um dos sites no back-end ou usar "127.0.0.1" para investigar o host local do servidor de back-end. Porém, quando você estiver usando caracteres coringa ou vários nomes de host em um ouvinte, as solicitações para todos os padrões de domínio especificados serão roteadas para o pool de back-end dependendo do tipo de regra (básica ou baseada em caminho).
- A propriedade "hostname" usa uma cadeia de caracteres como entrada, na qual você pode mencionar apenas um nome de domínio não curinga. A propriedade "hostnames" recebe uma matriz de cadeia de caracteres como entrada, na qual você pode mencionar até 5 nomes de domínio curinga. Ambas as propriedades não podem ser usadas ao mesmo tempo.
Confira criar vários sites usando Azure PowerShell ou usando a CLI do Azure para obter o guia passo a passo sobre como configurar nomes do host curinga em um ouvinte em vários sites.
Ouvinte de vários sites para ouvintes de protocolo TLS e TCP
O recurso de vários sites também está disponível para o proxy Layer4, mas somente para os ouvintes TLS. Você pode redirecionar o tráfego de cada aplicativo para seu respectivo pool de back-end, especificando nomes de domínio no ouvinte TLS. Para o funcionamento do recurso de vários nos ouvintes do TLS, o Gateway de Aplicativo usa o valor de Indicação de Nome do Servidor (SNI), que é fornecido pelos clientes principalmente através da extensão SNI para obter o certificado TLS correto. Um ouvinte de TLS para vários sites escolheria esse valor de SNI nos dados de handshake do TLS de uma conexão recebida e rotearia essa conexão para o pool de back-end apropriado. A conexão TCP, por natureza, não possui um conceito de nome de host ou nome de domínio, e por isso essa funcionalidade não se aplica a ouvintes TCP.
Cabeçalhos de host e SNI (Indicação de Nome de Servidor)
Existem três mecanismos comuns para habilitar a hospedagem de vários sites na mesma infraestrutura.
- Hospede vários aplicativos Web, cada um em um endereço IP exclusivo.
- Use o nome de host para hospedar vários aplicativos Web no mesmo endereço IP.
- Use portas diferentes para hospedar vários aplicativos Web no mesmo endereço IP.
No momento, um Gateway de Aplicativo obtém um único endereço IP público que escuta o tráfego. Portanto, no momento, não há suporte a vários aplicativos, cada um com seu próprio endereço IP.
O Gateway de Aplicativo dá suporte a vários aplicativos, cada um ouvindo em portas diferentes, mas esse cenário exige que os aplicativos aceitem o tráfego nas portas não padrão.
O Gateway de Aplicativo depende de cabeçalhos de host HTTP 1.1 para hospedar mais de um site na mesma porta e endereço IP público. Os sites hospedados no gateway de aplicativo também podem dar suporte ao descarregamento de TLS com a extensão TLS de SNI (Indicação de Nome de Servidor). Esse cenário significa que o farm da Web de back-end e o navegador cliente devem dar suporte à extensão TLS e HTTP/1.1 conforme definido no RFC 6066.
Próximas etapas
Saiba como configurar a hospedagem de vários sites no Gateway de Aplicativo
Confira o tópico Modelo do Resource Manager usando a hospedagem de vários sites para encontrar uma implantação completa baseada em modelo.