Поделиться через


Application Gateway multi-site hosting

Multi-site hosting enables you to configure more than one web application on the same port of application gateways using public-facing listeners. Так вы можете настроить более эффективную топологию для развернутых служб, добавляя более 100 веб-сайтов в один шлюз приложений. Каждый веб-сайт может быть направлен в свой собственный пул серверов. Например, три домена (contoso.com, fabrikam.com и adatum.com) указывают на IP-адрес шлюза приложений. Создайте три многосайтовых прослушивателя и настройте каждый из них на использование соответствующего порта и параметра протокола.

You can also define wildcard host names in a multi-site listener and up to 5 host names per listener. To learn more, see wildcard host names in listener.

Многосайтовый шлюз приложений

Внимание

Rules are processed in the order they are listed in the portal for the v1 SKU. Для SKU версии 2 можно указать порядок обработки, используя приоритет правил. Настоятельно рекомендуется сначала настроить многосайтовые прослушиватели, прежде чем приступить к настройке базового прослушивателя. This ensures that traffic gets routed to the right back end. If a basic listener is listed first and matches an incoming request, it gets processed by that listener.

Запросы для http://contoso.com маршрутизируются в ContosoServerPool, а запросы для http://fabrikam.com — в FabrikamServerPool.

Точно так же в одном развернутом шлюзе приложений можно разместить несколько поддоменов одного родительского домена. Например, вы можете размещать http://blog.contoso.com и http://app.contoso.com на одном развертывании шлюза приложений.

Порядок оценки правил маршрутизации запросов

When you use multi-site listeners to ensure that the client traffic is routed to the accurate backend, it's important that the request routing rules are present in the correct order. Например, если у вас есть 2 прослушивателя со связанными именами узлов *.contoso.com и shop.contoso.com, то прослушиватель с именем узла shop.contoso.com должен обрабатываться перед прослушивателем с именем узла *.contoso.com. Если прослушиватель с *.contoso.com обрабатывается первым, то более конкретный прослушиватель с shop.contoso.com не получает трафик клиентов.

Порядок правил можно установить, указав значение поля "Приоритет " правилам маршрутизации запросов, связанным с прослушивателями. Можно указывать целые значения в диапазоне от 1 до 20 000. Числу 1 соответствует самый высокий, а числу 20 000 — самый низкий приоритет. Если входящий клиентский трафик совпадает с несколькими прослушивателями, правило маршрутизации запросов с наивысшим приоритетом используется для обслуживания запроса. Каждое правило маршрутизации запросов должно иметь уникальное значение приоритета.

Поле приоритета влияет только на порядок оценки правила маршрутизации запросов, это не изменит порядок оценки правил на основе путей в PathBasedRouting правиле маршрутизации запросов.

Примечание.

Чтобы использовать приоритет правила, необходимо указать значения поля приоритета правила для всех существующих правил маршрутизации запросов. Когда поле приоритета правила используется, любое созданное правило маршрутизации должно иметь значение поля приоритета правила в рамках его конфигурации.

Внимание

Начиная с API версии 2021-08-01, поле приоритета правила является обязательным полем в правилах маршрутизации запросов. Значения полей приоритета правила для существующих правил маршрутизации запросов, основанные на текущем порядке оценки в рамках первого вызова PUT, автоматически заполняются, если какие-либо обновления конфигурации применяются с помощью API версии 2021-08-01 и выше, портала, Azure PowerShell и Azure CLI. Будущие обновления правил маршрутизации запросов должны иметь поле приоритета правила, предоставленное в рамках конфигурации.

Wildcard host names in listener

Шлюз приложений позволяет выполнять маршрутизацию на основе хостов с помощью многосайтового слушателя HTTP(S). Теперь можно использовать подстановочные знаки, например звездочку (*) и вопросительный знак (?), в имени узла и до пяти имен узлов для каждого прослушивателя HTTP(S), работающего с несколькими сайтами. Например, *.contoso.com.

Using a wildcard character in the host name, you can match multiple host names in a single listener. Например, *.contoso.com может соответствовать ecom.contoso.com, b2b.contoso.com, а также customer1.b2b.contoso.com и т. д. Используя массив имен узлов, можно настроить несколько имен узлов для прослушивателя, чтобы маршрутизировать запросы к внутреннему пулу. For example, a listener can contain contoso.com, fabrikam.com which accepts requests for both the host names.

Wildcard Listener

Примечание.

This feature is available only for Standard_v2 and WAF_v2 SKU of Application Gateway.

В Azure PowerShell необходимо использовать параметр -HostNames вместо -HostName. При использовании HostNames можно указать до 5 имен узлов в виде значений, разделенных запятыми, и использовать подстановочные знаки. Например, -HostNames "*.contoso.com","*.fabrikam.com".

В Azure CLI необходимо использовать параметр --host-names вместо --host-name. При использовании host-names можно указать до 5 имен узлов в виде значений, разделенных запятыми, и использовать подстановочные знаки. Например, --host-names "*.contoso.com,*.fabrikam.com".

In the Azure portal, under the multi-site listener, you must choose the Multiple/Wildcard host type to mention up to five host names with allowed wildcard characters.

Wildcard Listener UI

Allowed characters in the host names field

  • (A-Z,a-z,0-9) — алфавитно-цифровые символы;
  • - — дефис или минус;
  • . - period as a delimiter
  • * — может соответствовать нескольким символам в допустимом диапазоне;
  • ? — может соответствовать одному символу в допустимом диапазоне.

Conditions for using wildcard characters and multiple host names in a listener

  • You can only mention up to 5 host names in a single listener
  • Звездочку * можно упомянуть только один раз в компоненте стиля доменного имени или имени узла. For example, component1*.component2*.component3. (*.contoso-*.com) является допустимым;
  • There can only be up to two asterisks * in a host name. Например, *.contoso.* является допустимым, а *.contoso.*.*.com — нет.
  • There can only be a maximum of 4 wildcard characters in a host name. Например, ????.contoso.com, w??.contoso*.edu.* допустимы, а ????.contoso.* — нет.
  • Использование звездочки * и вопросительного знака ? вместе в компоненте имени узла (*?, или ?*, или **) недопустимо. Например, *?.contoso.com и **.contoso.com являются недопустимыми.
  • An entry of *.contoso.com does not match contoso.com because *.contoso.com specifies that a dot is present before contoso.

Considerations and limitations of using wildcard or multiple host names in a listener

  • Для завершения сеансов SSL и использования сквозного режима SSL необходимо настроить протокол как HTTPS и отправить сертификат, который будет использоваться в конфигурации прослушивателя. If it's a multi-site listener, you can input the host name as well, usually this is the CN of the SSL certificate. При указании нескольких имен хостов в прослушивателе или использовании подстановочных знаков необходимо учитывать следующее:
    • If it's a wildcard hostname like *.contoso.com, you must upload a wildcard certificate with CN like *.contoso.com
    • If multiple host names are mentioned in the same listener, you must upload a SAN certificate (Subject Alternative Names) with the CNs matching the host names mentioned.
  • Нельзя использовать регулярное выражение для указания имени хоста. Для формирования шаблона имени узла можно использовать только подстановочные знаки, такие как звездочка (*) и вопросительный знак (?).
  • For backend health check, you can't associate multiple custom probes per HTTP settings. Вместо этого можно проверить один из веб-сайтов в серверной части или использовать адрес 127.0.0.1 для проверки localhost внутреннего сервера. However, when you're using wildcard or multiple host names in a listener, the requests for all the specified domain patterns are routed to the backend pool depending on the rule type (basic or path-based).
  • The "hostname" property takes one string as input, where you can mention only one non-wildcard domain name. The "hostnames" property takes an array of strings as input, where you can mention up to 5 wildcard domain names. Оба этих свойства не могут использоваться одновременно.

See create multi-site using Azure PowerShell or using Azure CLI for the step-by-step guide on how to configure wildcard host names in a multi-site listener.

Multi-site listener for TLS and TCP protocol listeners

Функция с несколькими сайтами также доступна для прокси-сервера Уровня 4, но только для прослушивателей TLS. Трафик для каждого приложения можно направить в внутренний пул, указав доменные имена в прослушивателе TLS. For the functioning of the multisite feature on TLS listeners, Application Gateway uses the Server Name Indication (SNI) value (the clients primarily present SNI extension to fetch the correct TLS certificate). A multisite TLS listener would pick this SNI value from the TLS handshake data of an incoming connection and route that connection to the appropriate backend pool. Tcp-подключение по сути не имеет понятия имени узла или доменного имени; следовательно, это недоступно для прослушивателей TCP.

Заголовки хостов и указание имени сервера (SNI)

Существует три распространенных механизма включения размещения нескольких сайтов в одной инфраструктуре.

  1. Размещение нескольких веб-приложений с уникальным IP-адресом у каждого из них.
  2. Использование имени узла для размещения нескольких веб-приложений на одном IP-адресе.
  3. Использование разных портов для размещения нескольких веб-приложений на одном IP-адресе.

В настоящее время шлюз приложений поддерживает один общедоступный IP-адрес, на котором он прослушивает трафик. Поэтому размещение нескольких приложений, каждое из которых имеет собственный IP-адрес, сейчас не поддерживается.

Шлюз приложений поддерживает несколько приложений, прослушивающих разные порты, но в этом сценарии приложения должны принимать трафик на нестандартные порты.

Шлюз приложений использует заголовки узлов HTTP 1.1 для размещения нескольких веб-сайтов на одном общедоступном IP-адресе и порте. Сайты, размещенные в шлюзе приложений, могут также поддерживать разгрузку TLS с использованием расширения TLS для указания имени сервера (SNI). В рамках этого сценария это значит, что браузер клиента и внутренняя веб-ферма должны поддерживать HTTP/1.1 и расширение TLS, как определено в стандарте RFC 6066.

Следующие шаги

Узнайте, как настроить хостинг с несколькими сайтами в Application Gateway

See Resource Manager template using multiple site hosting for an end to end template-based deployment.