Компоненты шлюза приложений
Шлюз приложений выступает в качестве единой точки контакта для клиентов. Он распределяет входящий трафик приложений между несколькими внутренними пулами, включая виртуальные машины 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 | Поддерживаемый диапазон портов | Исключения |
|---|---|---|
| V2 | От 1 до 64999 | 22 |
| V1 | От 1 до 65502 | 3389 |
Протоколы
Шлюз приложений поддерживает веб-протоколы HTTP, HTTPS, HTTP/2 и WebSocket с прокси-сервером уровня 7. Протоколы TLS и TCP поддерживаются с прокси-сервером уровня 4 (предварительная версия) и могут быть настроены на одном ресурсе.
Примечание.
Поддержка протокола HTTP/2 доступна только для клиентов, подключающихся к прослушивателям шлюза приложений. Подключение к внутренним пулам серверов осуществляется по протоколу HTTP/1.1. Поддержка HTTP/2 отключена по умолчанию. Тут можно его включить.
- Выберите между протоколами HTTP, HTTPS, TLS или TCP в конфигурации прослушивателя.
- Поддержка WebSockets и протоколов HTTP/2 предоставляется нативно. По умолчанию включена WebSocket. Настраиваемый пользователем параметр для выборочного включения или отключения поддержки WebSocket отсутствует. Используйте сокеты WebSocket с прослушивателями HTTP и HTTPS.
Используйте прослушиватель HTTPS или TLS для завершения TLS. Прослушиватель HTTPS/TLS выгружает работу шифрования и расшифровки в шлюз приложений, поэтому ваши серверы не перегружены вычислительными затратами.
Пользовательские страницы ошибок
Шлюз приложений позволяет создавать пользовательские страницы ошибок вместо отображения страниц ошибок по умолчанию. На пользовательской странице ошибок вы можете использовать собственные символику и макет. Шлюз приложений может отобразить пользовательскую страницу ошибки, когда запрос не может достичь серверной части.
Подробнее см. в статье Пользовательские страницы ошибок для шлюза приложений.
Типы прослушивателей
Существуют два типа прослушивателей:
Базовый. Этот тип прослушивателя прослушивает один доменный сайт, где имеется одно сопоставление DNS с IP-адресом шлюза приложений. Эта конфигурация прослушивателя необходима при размещении одного сайта за шлюзом приложений.
Несколько узлов. Эта конфигурация требуется, когда вы хотите настроить маршрутизацию на основе имени узла или доменного имени для нескольких веб-приложений в одном шлюзе. Так вы можете настроить более эффективную топологию для развернутых служб, добавляя более 100 веб-сайтов в один шлюз приложений. Каждый веб-сайт может быть направлен в свой собственный внутренний пул. Например, три домена (contoso.com, fabrikam.com и adatum.com) указывают на IP-адрес шлюза приложений. Создайте три многосайтовых прослушивателя и настройте каждый из них на использование соответствующего порта и параметра протокола.
Вы также можете определить имена узлов с подстановочными знаками в многосайтовом прослушивателе и до пяти имен узлов на каждый прослушиватель. См. сведения об использовании имен узлов с подстановочными знаками в прослушивателе.
Дополнительные сведения о настройке многосайтового прослушивателя см. в статье Размещение нескольких сайтов в шлюзе приложений с помощью портала Azure.
После создания прослушивателя его необходимо связать с правилом маршрутизации запросов. Это правило определяет, как запрос, полученный на прослушивателе, должен маршрутизироваться в серверную часть. Правило маршрутизации запросов также содержит внутренний пул для маршрутизации и параметр HTTP, в котором упоминаются внутренний порт, протокол и т. д.
Правила маршрутизации запросов
Правило маршрутизации запросов — это ключевой компонент шлюза приложений, так как он определяет способ маршрутизации трафика в прослушивателе. Правило привязывает прослушиватель, серверный пул серверов и параметры ВНУТРЕННЕГО 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-путь, интервал пробы и количество неудачных ответов, которые необходимо принять перед маркировкой экземпляра внутреннего пула как неработоспособные, пользовательские коды состояния и соответствие текста ответа и т. д. Рекомендуется настроить пользовательские пробы для мониторинга работоспособности каждого внутреннего пула.
Подробнее см. статью Мониторинг работоспособности шлюза приложений.
Следующие шаги
Создание шлюза приложений