Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
A hospedagem de múltiplos sites permite configurar mais de uma aplicação web na mesma porta dos gateways de aplicativo usando listeners voltados ao 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 o 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 de host com curinga em um listener multissite e até 5 nomes de host por listener. Para saber mais, consulte nomes de host curinga no listener.
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 listeners multissite antes de configurar um listener básico. Isso garante que o tráfego seja encaminhado para o servidor de back-end correto. Se um listener básico estiver listado primeiro e corresponder a uma solicitação recebida, essa solicitação será processada por esse listener.
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 das regras de roteamento de requisições
Ao usar listeners 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 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 listener com *.contoso.com for processado antes, nenhum tráfego de clientes será recebido pelo listener 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 PathBasedRouting regra de roteamento de solicitação.
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 para as regras de roteamento de solicitações existentes, com base na ordem de avaliação atual como parte da primeira chamada PUT, são preenchidos automaticamente se forem aplicadas atualizações de configuração usando a versão 2021-08-01 da API e posteriores, 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 um listener 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 de host, você pode fazer corresponder vários nomes de host em um único listener. Por exemplo, *.contoso.com pode corresponder a ecom.contoso.com, b2b.contoso.com, customer1.b2b.contoso.com e assim por diante. Usando uma lista de nomes de host, você pode configurar mais de um nome de host para um listener, para rotear solicitações para um pool de back-end. Por exemplo, um listener pode conter contoso.com, fabrikam.com, que aceita requisições para os dois nomes de host.
Observação
Esse recurso está disponível apenas para as SKUs Standard_v2 e WAF_v2 do Application Gateway.
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 de host, você pode especificar até 5 nomes de host como valores separados por vírgula e usar caracteres curinga. Por exemplo, --host-names "*.contoso.com,*.fabrikam.com".
No portal do Azure, no listener de vários sites, você deve escolher o tipo de host Múltiplos/Curinga para especificar 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 múltiplos nomes de host em um listener
As seguintes condições se aplicam quando você usa caracteres curinga ou vários nomes de host em um listener.
| Restrição | Limit | Example |
|---|---|---|
| Nomes de host em um único ouvinte | Até 5 | Não aplicável |
Asterisco (*) em um componente de um nome de estilo de domínio ou nome de host |
Pode ser mencionado apenas uma vez |
component1*.component2*.component3.
(*.contoso-*.com) é válido. |
Asteriscos (*) em um nome de host |
Até dois |
*.contoso.* é válido e *.contoso.*.*.com é inválido. |
| Caracteres curinga em um nome de host | Máximo de 4 |
????.contoso.com e w??.contoso*.edu.* são válidos, mas ????.contoso.* são inválidos. |
Asterisco (*) e ponto de interrogação (?) juntos em um componente de um nome de host (*? ou ?***) |
Inválido |
*?.contoso.com e **.contoso.com são inválidos. |
Comportamento de correspondência de *.contoso.com |
Não corresponde a contoso.com |
*.contoso.com especifica que há um ponto antes de contoso, então contoso.com não corresponde. |
Considerações e limitações do uso de caracteres curinga ou múltiplos nomes de host em um listener
-
A terminação SSL e SSL de ponta a ponta exigem que você configure o protocolo como HTTPS e faça upload de um certificado para ser usado na configuração do listener. 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 de host no listener ou ao 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 listener, você deverá fazer upload de um certificado SAN (Nomes Alternativos do Requerente) cujos CNs correspondam aos nomes de 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 do back-end, não é possível associar várias sondas personalizadas para cada configuração 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. No entanto, quando você estiver usando caracteres curinga ou vários nomes de host em um listener, as solicitações para todos os padrões de domínio especificados serão roteadas para o pool de back-end de acordo com o tipo de regra (básica ou baseada em caminho).
- A propriedade "hostname" recebe uma string como entrada, na qual é possível especificar apenas um nome de domínio sem curinga. A propriedade "hostnames" recebe um array de strings como entrada, onde você pode especificar até 5 nomes de domínio com curinga. Ambas as propriedades não podem ser usadas ao mesmo tempo.
Consulte criar vários sites usando o Azure PowerShell ou usando o CLI do Azure para obter instruções passo a passo para configurar nomes de host curinga em um ouvinte multissite.
Listener multissite para listeners de protocolo TLS e TCP
O recurso multisite também está disponível para o proxy Layer4, mas apenas para seus listeners 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 multissite nos ouvintes TLS, o Application Gateway usa o valor de Indicação de Nome do Servidor (SNI) — que os clientes normalmente apresentam por meio da extensão SNI — para selecionar o certificado TLS correto. Um listener TLS multissite escolheria esse valor de SNI a partir dos dados do handshake TLS de uma conexão de entrada e encaminharia essa conexão para o pool de backend 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.
Atualmente, o Application Gateway dá suporte a um único endereço IP público no qual escuta tráfego. Portanto, no momento, não há suporte a vários aplicativos, cada um com seu próprio endereço IP.
O Application Gateway oferece suporte a vários aplicativos, cada um deles escutando em portas diferentes, mas esse cenário exige que os aplicativos aceitem tráfego em portas não padronizadas.
O Application Gateway depende de cabeçalhos de host HTTP 1.1 para hospedar mais de um site no mesmo endereço IP público e na mesma porta. Os sites hospedados no gateway de aplicativo também podem oferecer suporte ao descarregamento de TLS com a extensão TLS SNI (Indicação de Nome do Servidor). Esse cenário significa que o navegador do cliente e o farm de servidores web de back-end devem dar suporte ao HTTP/1.1 e à extensão TLS, conforme definida na 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.