Hospedagem multissite do Application Gateway
A hospedagem multissite permite configurar mais de um aplicativo Web na mesma porta de gateways de aplicativos usando ouvintes voltados para o público. Permite-lhe configurar uma topologia mais eficiente para as implementações ao adicionar até 100 sites a um gateway de aplicação. Cada site pode ser direcionado para o seu próprio agrupamento 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 aplicação. Teria de criar três serviços de escuta com vários sites e configurar cada serviço de escuta para a respetiva definição de porta e protocolo.
Além disso, pode definir nomes de anfitrião de caráter universal num serviço de escuta com vários sites e até cinco nomes de anfitrião por serviço de escuta. Para saber mais, consulte Nomes de host curinga no ouvinte.
Importante
As regras são processadas na ordem em que estão listadas no portal para o SKU v1. Para SKU v2, use a prioridade da regra para especificar a ordem de processamento. Antes de configurar um serviço de escuta básico, recomenda-se vivamente que configure serviços de escuta de múltiplos sites. Desta forma, assegura que o tráfego é encaminhado para o back-end certo. Se for apresentado primeiro um serviço de escuta básico e este corresponde a um pedido de entrada, o pedido é processado por esse serviço de escuta.
Os pedidos de http://contoso.com são encaminhados para ContosoServerPool e os pedidos de http://fabrikam.com são encaminhados para FabrikamServerPool.
Da mesma forma, você pode hospedar vários subdomínios do mesmo domínio pai na mesma implantação de 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 das regras de roteamento de solicitações
Quando você usa ouvintes multissite para garantir que o tráfego do cliente seja roteado para o back-end preciso, é importante que as regras de roteamento de solicitação estejam presentes na ordem correta.
Por exemplo, se você tiver 2 ouvintes com nomes de host associados de e shop.contoso.com, o ouvinte com o shop.contoso.com nome do host deverá ser processado *.contoso.com antes do ouvinte com *.contoso.com. Se o ouvinte com *.contoso.com for processado primeiro, nenhum tráfego de cliente será recebido pelo ouvinte mais específico shop.contoso.com .
A ordenação das regras pode ser estabelecida fornecendo um valor de campo Prioridade para as regras de roteamento de solicitação associadas aos ouvintes. Pode especificar um valor inteiro de 1 a 20 000, sendo 1 a prioridade mais alta e 20 000 a mais baixa. Se o tráfego de cliente de entrada corresponder a vários ouvintes, a regra de roteamento de solicitação com prioridade mais alta será usada para atender à solicitação. Cada regra de roteamento de solicitação deve 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 PathBasedRouting regra de roteamento de solicitação.
Nota
Para usar a prioridade da regra, você deve especificar valores de campo de prioridade de regra para todas as regras de roteamento de solicitação existentes. Quando o campo de prioridade da regra estiver em uso, qualquer nova regra de roteamento criada deverá ter um valor de campo de prioridade da regra como parte de sua configuração.
Importante
A partir da API versão 2021-08-01, o campo de prioridade da regra é obrigatório nas regras de roteamento de solicitações. Os valores de campo de prioridade de regra para regras de roteamento de solicitação existentes, com base na ordem atual de avaliação como parte da primeira chamada PUT, são preenchidos automaticamente se quaisquer atualizações de configuração forem aplicadas usando a API versão 2021-08-01 e superior, portal, Azure PowerShell e CLI do Azure. Atualizações futuras para regras de roteamento de solicitação devem ter o campo de prioridade da regra fornecido como parte da configuração.
Nomes de host curinga no ouvinte
O Application Gateway permite o roteamento baseado em host usando ouvinte HTTP(S) multissite. Agora, você pode usar caracteres curinga como asterisco (*) e ponto de interrogação (?) no nome do host e até 5 nomes de host por ouvinte HTTP(S) multissite. Por exemplo, *.contoso.com.
Usando um caractere curinga no nome do host, você pode corresponder a vários nomes de host em um único ouvinte. Por exemplo, *.contoso.com pode corresponder com ecom.contoso.com, b2b.contoso.com e customer1.b2b.contoso.com assim por diante. Usando uma matriz de nomes de host, você pode configurar mais de um nome de host para um ouvinte, para rotear solicitações para um pool de back-end. Por exemplo, um ouvinte pode conter contoso.com, fabrikam.com solicitações para ambos os nomes de host.
Nota
Esse recurso está disponível apenas para Standard_v2 e WAF_v2 SKU do Application Gateway.
No Azure PowerShell, você deve usar -HostNames em vez de -HostName. Com HostNames, você pode mencionar até 5 nomes de 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 de host, você pode mencionar até 5 nomes de host como valores separados por vírgulas e usar caracteres curinga. Por exemplo, --host-names "*.contoso.com,*.fabrikam.com".
No portal do Azure, sob o ouvinte multissite, você deve escolher o tipo de host Múltiplo/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 menos.- período como delimitador*- pode corresponder com vários caracteres no intervalo permitido?- pode corresponder com um único caractere no intervalo permitido
Condições para usar caracteres curinga e vários nomes de host em um ouvinte
- Você só pode mencionar até 5 nomes de host em um único ouvinte
- Asterisk
*pode ser mencionado apenas uma vez em um componente de um nome de estilo de domínio ou nome de host. Por exemplo, component1*.component2*.component3.(*.contoso-*.com)é válida. - Só pode haver até dois asteriscos
*em um nome de host. Por exemplo,*.contoso.*é válido e*.contoso.*.*.comé inválido. - Só pode haver um máximo de 4 caracteres curinga em um nome de host. Por exemplo,
????.contoso.com,w??.contoso*.edu.*são válidos, mas????.contoso.*são inválidos. - Usar asterisco
*e ponto de interrogação?juntos em um componente de um nome de host (*?ou?***) é inválido. Por exemplo,*?.contoso.come**.contoso.comsão inválidos.
Considerações e limitações do uso de 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 para ser usado na configuração do ouvinte. Se for um ouvinte multi-site, você pode inserir o nome do host também, geralmente este é o CN do certificado SSL. Ao especificar vários nomes de host no ouvinte ou usar caracteres curinga, você deve considerar o seguinte:
- Se for um nome de host curinga como *.contoso.com, você deve 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 SAN (Nomes Alternativos de Entidade) com os CNs correspondentes aos nomes de host mencionados.
- Não é possível usar uma expressão regular para mencionar o nome do host. Você só pode 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 do back-end, não é possível associar vários testes personalizados por configurações HTTP. Em vez disso, você pode investigar um dos sites no back-end ou usar "127.0.0.1" para investigar o localhost do servidor de back-end. No entanto, quando você estiver usando curinga 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, onde você pode mencionar apenas um nome de domínio não curinga. A propriedade "hostnames" usa uma matriz de cadeias de caracteres como entrada, onde você pode mencionar até 5 nomes de domínio curinga. Ambas as propriedades não podem ser usadas ao mesmo tempo.
Consulte Criar vários sites usando o Azure PowerShell ou usando a CLI do Azure para obter o guia passo a passo sobre como configurar nomes de host curinga em um ouvinte multissite.
Ouvinte multissite para ouvintes de protocolo TLS e TCP
O recurso multi-site também está disponível para proxy Layer4, mas apenas para seus ouvintes TLS. Você pode direcionar o tráfego de cada aplicativo para seu pool de back-end fornecendo nomes de domínio no ouvinte TLS. Para o funcionamento do recurso multissite em ouvintes TLS, o Application Gateway usa o valor SNI (Server Name Indication) (os clientes apresentam principalmente a extensão SNI para buscar o certificado TLS correto). Um ouvinte TLS multissite escolheria esse valor SNI dos dados de handshake TLS de uma conexão de entrada e encaminharia essa conexão para o pool de back-end apropriado. A conexão TCP inerentemente não tem nenhum conceito de nome de host ou nome de domínio; portanto, isso não está disponível para ouvintes TCP.
Cabeçalhos de anfitrião e Indicação do Nome de Servidor (SNI)
Existem três mecanismos comuns para permitir o alojamento multi-site na mesma infraestrutura.
- Aloje várias aplicações Web, cada uma num endereço IP exclusivo.
- Utilize o nome do anfitrião para alojar várias aplicações Web no mesmo endereço IP.
- Utilize portas diferentes para alojar várias aplicações Web no mesmo endereço IP.
Atualmente, o Application Gateway suporta um único endereço IP público onde escuta o tráfego. Portanto, vários aplicativos, cada um com seu próprio endereço IP, não são suportados no momento.
O Application Gateway oferece suporte a vários aplicativos, cada um escutando em portas diferentes, mas esse cenário exige que os aplicativos aceitem tráfego em portas não padrão.
O Gateway de Aplicação conta com os cabeçalhos de anfitrião HTTP 1.1 para alojar mais do que um site no mesmo endereço IP público e porta. Os sites hospedados no gateway de aplicativo também podem suportar o descarregamento de TLS com a extensão TLS de Indicação de Nome de Servidor (SNI). Neste cenário, o browser cliente e o web farm de back-end têm de suportar HTTP/1.1 e a extensão TLS conforme definido em RFC 6066.
Próximos passos
Saiba como configurar a hospedagem multissite no Application Gateway
Consulte Modelo do Resource Manager usando hospedagem de vários sites para uma implantação baseada em modelo de ponta a ponta.