Hospedaje multisitio de Application Gateway
El hospedaje multisitio permite configurar más de una aplicación web en el mismo puerto de puertas de enlace de aplicaciones mediante agentes de escucha de acceso público. Permite configurar una topología más eficaz para las implementaciones al agregar hasta 100 sitios web a una puerta de enlace de aplicaciones. Cada sitio web se puede dirigir a su propio grupo de back-end. Por ejemplo, tres dominios, contoso.com, fabrikam.com y adatum.com, señalan a la dirección IP de la puerta de enlace de aplicaciones. Crearía tres clientes de escucha multisitio y configuraría cada uno con la configuración respectiva de protocolo y puerto.
También puede definir nombres de host con el carácter comodín en un cliente de escucha de varios sitios y hasta cinco nombres de host por cliente de escucha. Para obtener más información, consulte los nombres de host comodín en el cliente de escucha.
Importante
La reglas se procesan en el orden en que aparecen en el portal para la SKU v1. Para la SKU v2, use la prioridad de las reglas para especificar el orden de procesamiento. Es muy recomendable configurar a los agentes de escucha multisitio antes de configurar un agente de escucha básico. De esta forma se asegura de que el tráfico se enruta al back-end adecuado. Si un agente de escucha básico aparece en primer lugar y coincide con una solicitud entrante, lo procesa ese agente de escucha.
Las solicitudes para http://contoso.com se enrutan a ContosoServerPool y para http://fabrikam.com se enrutan a FabrikamServerPool.
De forma similar, puede hospedar varios subdominios del mismo dominio principal en la misma implementación de la puerta de enlace de aplicaciones. Por ejemplo, puede hospedar http://blog.contoso.com y http://app.contoso.com en la misma implementación de puerta de enlace de aplicaciones.
Orden de evaluación de las reglas de enrutamiento de solicitudes
Para asegurarse de que el tráfico del cliente se enrute al back-end preciso al usar clientes de escucha de varios sitios, es importante que las reglas de enrutamiento de solicitudes se presenten en el orden correcto.
Por ejemplo, si tiene 2 agentes de escucha con los nombres de host asociados de *.contoso.com y shop.contoso.com, el agente de escucha con el nombre de host shop.contoso.com debe procesarse antes que el agente de escucha con *.contoso.com. Si el cliente de escucha con *.contoso.com se procesa primero, el cliente de escucha shop.contoso.com más específico no recibiría tráfico de clientes.
El orden de las reglas se puede establecer proporcionando un valor de campo de Prioridad a las reglas de enrutamiento de solicitudes asociadas a los clientes de escucha. Puede especificar un valor entero de 1 a 20000, siendo 1 la prioridad más alta y 20000 la prioridad más baja. Si el tráfico de cliente entrante coincide con varios agentes de escucha, se usa la regla de enrutamiento de solicitudes con prioridad más alta para atender la solicitud. Cada regla de enrutamiento de solicitudes debe tener un valor de prioridad único.
El campo de prioridad solo afecta al orden de evaluación de una regla de enrutamiento de solicitudes. Esto no cambia el orden de evaluación de las reglas basadas en rutas de acceso dentro de una regla de enrutamiento de solicitudes PathBasedRouting.
Nota:
Si desea usar la prioridad de regla, tendrá que especificar valores de campo de prioridad de regla para todas las reglas de enrutamiento de solicitudes existentes. Una vez que el campo de prioridad de la regla esté en uso, cualquier nueva regla de enrutamiento que se cree también tendría que tener un valor de campo de prioridad de regla como parte de su configuración.
Importante
A partir de la versión de API 2021-08-01, el campo de prioridad de regla es un campo obligatorio en las reglas de enrutamiento de solicitudes. Los valores de campo de prioridad de la regla para las reglas de enrutamiento de solicitudes existentes basadas en el orden actual de evaluación como parte de la primera llamada PUT, se rellenarán automáticamente si se aplican actualizaciones de configuración mediante la versión de la API 2021-08-01 y posteriores, Azure Portal, Azure PowerShell y la CLI de Azure. Cualquier actualización futura de las reglas de enrutamiento de solicitudes debe tener el campo de prioridad de la regla proporcionado como parte de la configuración.
Nombres de host con el carácter comodín en los clientes de escucha
Application Gateway permite el enrutamiento basado en host mediante un cliente de escucha HTTP(S) de varios sitios. Ahora, puede usar caracteres comodín como el asterisco (*) y el signo de interrogación (?) en el nombre del host y hasta 5 nombres de host por cliente de escucha HTTPS(S) de varios sitios. Por ejemplo, *.contoso.com.
Con un carácter comodín en el nombre del host, puede hacer coincidir varios nombres de host en un único cliente de escucha. Por ejemplo, *.contoso.com puede coincidir con ecom.contoso.com, b2b.contoso.com y customer1.b2b.contoso.com y así sucesivamente. Con una matriz de nombres de host, puede configurar más de un nombre de host para un cliente de escucha, para enrutar las solicitudes a un grupo de back-end. Por ejemplo, un cliente de escucha puede contener contoso.com, fabrikam.com, lo que aceptará las solicitudes para ambos nombres de host.
Nota:
Esta característica solo está disponible para las SKU Standard_v2 y WAF_v2 de Application Gateway.
En Azure PowerShell, debe usar -HostNames en lugar de -HostName. Con los nombres de host, puede mencionar un máximo de cinco nombres de host como valores separados por comas y usar caracteres comodín. Por ejemplo, -HostNames "*.contoso.com","*.fabrikam.com".
En la CLI de Azure, debe usar --host-names en lugar de --host-name. Con los nombres de host, puede mencionar un máximo de cinco nombres de host como valores separados por comas y usar caracteres comodín. Por ejemplo, --host-names "*.contoso.com,*.fabrikam.com".
En Azure Portal, en el cliente de escucha de varios sitios, debe elegir el host de tipo varios o comodín para mencionar hasta cinco nombres de host con caracteres comodín permitidos.
Caracteres permitidos en el campo de nombres de host
(A-Z,a-z,0-9)-caracteres alfanuméricos--guion o menos.-punto como delimitador*-puede coincidir con varios caracteres del intervalo permitido?-puede coincidir con un único carácter del intervalo permitido
Condiciones para usar caracteres comodín y varios nombres de host en un cliente de escucha
- Solo puede mencionar hasta cinco nombres de host en un único cliente de escucha.
- Los asteriscos
*solo se pueden mencionar una vez en un componente de nombre de estilo de dominio o nombre de host. Por ejemplo, componente1*.componente2*.componente3.(*.contoso-*.com)es válido. - Solo puede haber hasta dos asteriscos
*en un nombre de host. Por ejemplo,*.contoso.*es válido y*.contoso.*.*.comno es válido. - Solo puede haber un máximo de 4 caracteres comodín en un nombre de host. Por ejemplo,
????.contoso.com,w??.contoso*.edu.*son válidos, pero????.contoso.*no es válido. - El uso del asterisco
*y el signo de interrogación?juntos en un componente de un nombre de host (*?,?*o**) no es válido. Por ejemplo,*?.contoso.comand**.contoso.comno son válidos.
Consideraciones y limitaciones del uso de caracteres comodín o varios nombres de host en un cliente de escucha
- La terminación SSL y SSL de un extremo a otro requieren que configure el protocolo como HTTPS y cargue un certificado que se usará en la configuración del cliente de escucha. Si se trata de un cliente de escucha de varios sitios, también puede especificar el nombre de host, que normalmente es el CN del certificado SSL. Al especificar varios nombres de host en el cliente de escucha o se usan caracteres comodín, se debe tener en cuenta lo siguiente:
- Si es un nombre de host comodín como *.contoso.com, deberá cargar un certificado comodín con CN como *.contoso.com
- Si se mencionan varios nombres de host en el mismo cliente de escucha, debe cargar un certificado SAN (nombres alternativos del firmante) con CN que coincidan con los nombres de host mencionados.
- No es posible usar una expresión regular para mencionar el nombre de host. Solo se pueden usar caracteres comodín como el asterisco (*) y el signo de interrogación (?) para formar el patrón de nombre de host.
- Para la comprobación de estado del back-end, no se pueden asociar varios sondeos personalizados por configuración HTTP. En su lugar, puede sondear uno de los sitios web en el back-end o usar "127.0.0.1" para sondear el localhost del servidor backend. Sin embargo, cuando se usan caracteres comodín o varios nombres de host en un cliente de escucha, las solicitudes de todos los patrones de dominio especificados se enrutarán al grupo de back-end en función del tipo de regla (básica o basada en la ruta de acceso).
- La propiedad «hostname» toma una cadena como entrada, donde solo se puede mencionar un nombre de dominio que no es comodín. La propiedad «hostname» toma una matriz de cadenas como entrada, donde solo se pueden mencionar hasta cinco nombres de dominio comodín. No se pueden usar las dos propiedades a la vez.
Consulte Creación de varios sitios con Azure PowerShell o con la CLI de Azure para ver la guía paso a paso sobre cómo configurar nombres de host con caracteres comodín en un cliente de escucha de varios sitios.
Agente de escucha multisitio para agentes de escucha de protocolo TLS y TCP
La característica de varios sitios también está disponible para el proxy Layer4, pero solo para sus agentes de escucha TLS. Puede dirigir el tráfico de cada aplicación a su grupo de back-end proporcionando nombres de dominio en el agente de escucha TLS. Para el funcionamiento de la característica multisitio en los agentes de escucha TLS, Application Gateway usa el valor de indicación de nombre de servidor (SNI) (los clientes presentan principalmente la extensión SNI para capturar el certificado TLS correcto). Un agente de escucha TLS multisitio elegiría este valor de SNI de los datos de protocolo de enlace TLS de una conexión entrante y enrutaría esa conexión al grupo de back-end adecuado. La conexión TCP no tiene inherentemente ningún concepto de nombre de host o nombre de dominio; por lo tanto, esto no está disponible para los agentes de escucha TCP.
Encabezados de host e Indicación de nombre de servidor (SNI)
Existen tres mecanismos comunes para habilitar el hospedaje multisitio en la misma infraestructura.
- Hospede varias aplicaciones web, cada una en una dirección IP única.
- Use el nombre de host para hospedar varias aplicaciones web en la misma dirección IP.
- Use puertos distintos para hospedar varias aplicaciones web en la misma dirección IP.
En la actualidad, Application Gateway admite una dirección IP pública única en la que escucha el tráfico. Por lo tanto, actualmente no se permite tener varias aplicaciones, cada una con su propia dirección IP.
Application Gateway permite que haya varias aplicaciones y que cada una escuche en un puerto diferente. Sin embargo, este escenario requiere que las aplicaciones acepten el tráfico en puertos no estándar.
Application Gateway se basa en los encabezados de host HTTP 1.1 para hospedar más de un sitio web en la misma dirección IP pública y en el mismo puerto. Los sitios que se hospedan en la puerta de enlace de aplicaciones también pueden admitir la descarga TLS con la extensión TLS de Indicación de nombre de servidor (SNI). Este escenario significa que el explorador cliente y la granja de servidores web back-end deben admitir la extensión TLS y HTTP/1.1, como se define en RFC 6066.
Pasos siguientes
Aprenda a configurar el hospedaje multisitio en Application Gateway
Consulte la plantilla de Resource Manager con hospedaje de múltiples sitios para ver una implementación completa basada en una plantilla.