Компоненты шлюза приложений

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

IP-адреса фронтенда

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

Статические и динамические общедоступные IP-адреса

SKU Шлюза приложений Azure версии 2 можно настроить для поддержки статических внутренних IP-адресов и статического общедоступного IP-адреса или только статического общедоступного IP-адреса. Его нельзя настроить для поддержки только статического внутреннего IP-адреса.

SKU версии 1 можно настроить для поддержки статического или динамического внутреннего IP-адреса и динамического общедоступного IP-адреса. Динамический IP-адрес шлюза приложений не изменяется на работающем шлюзе. Он может измениться только при запуске или отключении шлюза. Он не изменяется при сбоях в системе, обновлениях, обновлениях хостов Azure и т. д.

DNS-имя, связанное со шлюзом приложений, не меняется на протяжении жизненного цикла шлюза. В результате вам следует использовать псевдоним CNAME и направить его на DNS-адрес шлюза приложений.

Слушатели

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

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

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

Прослушиватели поддерживают следующие порты и протоколы.

Порты

Порт — это место, в котором прослушиватель прослушивает запрос клиента. Вы можете настроить порты для номеров SKU версии 1 и версии 2, как показано ниже.

Номер SKU	Поддерживаемый диапазон портов	Исключения
Версия 2	От 1 до 64999	Использование порта 22 не поддерживается для шлюзов с поддержкой приватного канала. Порт 53
Версия 1	От 1 до 65502	Порт 3389

Протоколы

Шлюз приложений обеспечивает поддержку веб-протоколов HTTP, HTTPS, HTTP/2 и WebSocket через прокси-сервер уровня 7. Кроме того, он поддерживает протоколы TLS и TCP через его прокси-сервер уровня 4 в предварительной версии, который можно настроить на одном ресурсе.

• Выберите между протоколами HTTP, HTTPS, TLS или TCP в конфигурации прослушивателя.
• Для завершения сеанса TLS можно использовать прослушиватель HTTPS или TLS. Прослушиватель HTTPS/TLS выгружает работу шифрования и расшифровки в шлюз приложений, поэтому ваши серверы не перегружены затратами на вычисления TLS.
• Поддержка WebSockets и протоколов HTTP/2 предоставляется нативно, а WebSocket включена по умолчанию. Настраиваемый пользователем параметр для выборочного включения или отключения поддержки WebSocket отсутствует. Используйте WebSockets с помощью прослушивателей HTTP и HTTPS.

Примечание.

Поддержка протокола HTTP/2 доступна только для клиентов, подключающихся к прослушивателям шлюза приложений. Подключение к внутренним пулам серверов осуществляется по протоколу HTTP/1.1. Поддержка HTTP/2 отключена по умолчанию. Вы можете включить его.

Пользовательские страницы ошибок

Шлюз приложений позволяет создавать пользовательские страницы ошибок вместо отображения страниц ошибок по умолчанию. Вы можете использовать свой собственный бренд и макет на пользовательской странице ошибок. Шлюз приложений отображает пользовательскую страницу ошибки, когда запрос не может достичь сервера.

Для получения дополнительной информации см. Пользовательские страницы ошибок для шлюза приложений.

Типы прослушивателей

Существуют два типа прослушивателей:

• Базовый. Этот тип прослушивателя прослушивает один доменный сайт, где имеется одно сопоставление DNS с IP-адресом шлюза приложений. Эта конфигурация прослушивателя необходима при размещении одного сайта за шлюзом приложений.

• Мульти-сайт. Эта конфигурация требуется, когда вы хотите настроить маршрутизацию на основе имени узла или доменного имени для нескольких веб-приложений в одном шлюзе. Так вы можете настроить более эффективную топологию для развернутых служб, добавляя более 100 веб-сайтов в один шлюз приложений. Каждый сайт может быть направлен в свой собственный бекенд-пул. Например, три домена (contoso.com, fabrikam.com и adatum.com) указывают на IP-адрес шлюза приложений. Создайте три многосайтовых прослушивателя и настройте каждый из них на использование соответствующего порта и параметра протокола.

  Вы также можете определить имена узлов с подстановочными знаками в многосайтовом прослушивателе и до пяти имен узлов на каждый прослушиватель. Чтобы узнать больше, см. имена узлов с подстановочными знаками в прослушивателе.

  Дополнительные сведения о настройке многосайтового прослушивателя см. в статье Размещение нескольких сайтов в шлюзе приложений с помощью портала Azure.

После создания прослушивателя его необходимо связать с правилом маршрутизации запросов. Это правило определяет, как запрос, полученный на прослушивателе, должен маршрутизироваться в серверную часть. Правило маршрутизации запросов также содержит внутренний пул для маршрутизации и параметр HTTP, в котором упоминаются внутренний порт, протокол и т. д.

Правила маршрутизации запросов

Правило маршрутизации запросов — это ключевой компонент шлюза приложений, так как он определяет способ маршрутизации трафика в прослушивателе. Правило связывает прослушиватель, пул серверов внутренней сети и настройки backend HTTP.

Когда прослушиватель принимает запрос, правило маршрутизации запросов перенаправляет запрос в серверную часть или перенаправляет его в другое место. Если запрос перенаправляется в серверную часть, правило маршрутизации запросов определяет, к какому внутреннему пулу серверов следует выполнить переадресацию. Правило маршрутизации запросов также определяет, следует ли перезаписывать заголовки в запросе. Один прослушиватель можно присоединить к одному правилу.

Существует два типа правил маршрутизации запросов:

• Базовый. Все запросы к связанному прослушивателю (например, blog.contoso.com/*) перенаправляются в связанный серверный пул с помощью соответствующего параметра HTTP.

• На основе пути. Это правило маршрутизации позволяет направлять запросы к ассоциированному слушателю на конкретный внутренний пул на основе URL-адреса в запросе. Если путь URL-адреса в запросе совпадает с шаблоном пути в правиле на основе пути, правило направляет запрос. Шаблон пути применяется только к URL-пути, а не к его параметрам запроса. Если URL-путь в запросе слушателя не соответствует ни одному из правил, основанных на пути, он направляет запрос в серверный пул по умолчанию и настройки HTTP.

Подробнее см. в разделе Доступ по URL-адресу.

Поддержка перенаправления

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

Вы можете выбрать цель перенаправления на другого слушателя (что может помочь включить автоматическое перенаправление HTTP в HTTPS) или на внешний сайт. Можно также указать, что перенаправление является временным или постоянным или добавить путь URI и строку запроса к перенаправленному URL-адресу.

Дополнительные сведения см. в статье Перенаправление трафика с помощью шлюза приложений.

Перезапись заголовков HTTP и URL-адреса

С помощью правил перезаписи можно добавлять, удалять или обновлять заголовки запросов и ответов HTTP и HTTPS, а также URL-пути и параметры строки запроса, так как пакеты запросов и ответов перемещаются между клиентом и серверными пулами через шлюз приложений.

Для заголовков и параметров URL-адреса можно задать статические значения или другие заголовки и серверные переменные. Это позволяет извлекать IP-адреса клиентов, удалять конфиденциальные сведения о серверной части, укреплять защиту и т. д.

Подробнее см. в статье Перезапись HTTP-заголовков и URL-адресов на шлюзе приложений.

Параметры HTTP

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

Порт и протокол, используемые в параметрах HTTP, определяют, шифруется ли трафик между шлюзом приложений и внутренними серверами (обеспечивая сквозное шифрование TLS) или не шифруется.

Этот компонент также позволяет:

• определять, должен ли сеанс пользователя храниться на том же сервере с помощью сходства сеансов на основе файлов cookie;

• Аккуратно удалите участников серверного пула, используя отвод подключений.

• Ассоциировать пользовательскую проверку для мониторинга работоспособности серверной части, установить интервал времени ожидания запроса, изменить имя узла и путь в запросе, а также одним нажатием указывать параметры для серверной части Службы приложений.

Серверные пулы

Внутренний пул направляет запрос на внутренние серверы, обслуживающие запрос. Серверные пулы могут содержать:

• Сетевые интерфейсные карты
• Масштабируемые наборы виртуальных машин
• общедоступные IP-адреса;
• Внутренние IP-адреса
• Полное доменное имя
• Многоклиентские бэкенды (например, Служба приложений)

Участники серверного пула Шлюза приложений не привязаны к группе доступности. Шлюз приложений может взаимодействовать с экземплярами за пределами виртуальной сети, в которой он находится. В результате элементы серверных пулов могут быть распределены между кластерами, центрами обработки данных или за пределами Azure, если имеется IP-подключение.

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

Шлюз приложений также может взаимодействовать с локальными серверами, когда они подключены к Azure ExpressRoute или VPN-туннелям, если трафик разрешен.

Можно создать различные серверные пулы для запросов различных типов. Например, один внутренний пул для общих запросов, а другой — для запросов к микрослужбам вашего приложения.

После добавления масштабируемых наборов виртуальных машин в качестве члена внутреннего пула необходимо обновить экземпляры масштабируемых наборов виртуальных машин. До обновления экземпляров масштабируемых наборов серверная часть будет неработоспособна.

Проверка здоровья систем

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

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

Подробнее см. статью Мониторинг работоспособности шлюза приложений.

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

Создание шлюза приложений

• на портале Azure.
• С помощью Azure PowerShell
• С помощью Azure CLI