Hospedagem multissite do Application Gateway

A hospedagem multissite permite configurar mais de uma aplicação web na mesma porta dos gateways de aplicações usando escutadores com interface pública. 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 pool de servidores. Por exemplo, três domínios, contoso.com, fabrikam.com e adatum.com, apontam para o endereço IP do gateway de aplicação. Criaria três escutadores multi-site e configuraria cada escutador para as respetivas definições 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 coringa no listener.

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, é possível hospedar http://blog.contoso.com e http://app.contoso.com numa única implementação de gateway de aplicações.

Ordem de avaliação das regras de roteamento de solicitações

Quando utilizar escutadores multissite para garantir que o tráfego do cliente seja encaminhado para o back-end correto, é importante que as regras de encaminhamento de solicitações estejam presentes na ordem correta. Por exemplo, se tiver 2 ouvintes com os nomes de host associados de *.contoso.com e shop.contoso.com, o ouvinte com o nome de host shop.contoso.com deve 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 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.

Nomes de host wildcard na escuta

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, é possível corresponder a vários nomes de host numa única escuta. 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, que aceita solicitações para ambos os nomes de host.

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, deve-se escolher o tipo de host Múltiplo/Curinga no ouvinte multissite 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
• . - 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 utilizar caracteres curinga e vários nomes de host num listener

• Você só pode mencionar até 5 nomes de host num único escutador
• 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.com e **.contoso.com são inválidos.
• Uma entrada de *.contoso.com não corresponde a contoso.com porque *.contoso.com especifica que um ponto está presente antes de contoso.

Considerações e limitações do uso de wildcard ou múltiplos nomes de host num listener

• 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 escutador ou usar caracteres curinga, deve considerar o seguinte:
  • Se for um nome de host curinga como *.contoso.com, deve-se enviar um certificado curinga com CN semelhante a *.contoso.com.
  • Se forem mencionados vários nomes de host no mesmo listener, 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 saúde do back-end, não é possível associar várias sondas personalizadas 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 se estiver a usar caracteres universais ou vários nomes de host num listener, as solicitações para todos os padrões de domínio especificados serão encaminhadas 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 multissite usando o Azure PowerShell ou usar o Azure CLI para obter o manual passo a passo sobre como configurar nomes de host curinga num ouvinte multissite.

Ouvinte multissite para protocolos TLS e TCP

O recurso multi-site também está disponível para o proxy Layer4, mas apenas para os seus listeners TLS. Você pode direcionar o tráfego de cada aplicação para o seu pool de back-end fornecendo nomes de domínio no sintonizador TLS. Para que o recurso multissite funcione em ouvintes TLS, o Application Gateway utiliza o valor de Indicação de Nome de Servidor (SNI), uma vez que os clientes apresentam principalmente a extensão SNI para obter o certificado TLS correto. Um ouvinte TLS de múltiplos sites selecionaria esse valor SNI dos dados de handshake TLS de uma conexão de entrada e encaminharia essa conexão para o grupo de back-end apropriado. A conexão TCP inerentemente não tem conceito de nome de host ou de domínio; portanto, esta informação não está disponível para escutadores TCP.

Cabeçalhos de host e Indicação do Nome do Servidor (SNI)

Existem três mecanismos comuns para permitir o alojamento multi-site na mesma infraestrutura.

1. Aloje várias aplicações Web, cada uma num endereço IP exclusivo.
2. Utilize o nome do anfitrião para alojar várias aplicações Web no mesmo endereço IP.
3. 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 host HTTP 1.1 para hospedar mais do que um site no mesmo endereço IP público e porta. Os sites hospedados no gateway de aplicações também podem suportar o offload 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

• Utilizar o portal do Azure
• Utilizar o Azure PowerShell
• Utilizar a CLI do Azure

Consulte Modelo do Resource Manager usando hospedagem de vários sites para uma implantação baseada em modelo de ponta a ponta.