Настройка подстановочного знака Azure Application Gateway для нескольких конечных точек.

Вопрос или проблема

У меня есть набор статических веб-приложений, которые обрабатываются через Шлюз приложений. Каждое статическое веб-приложение настроено для использования пользовательского домена (например, app1.example.com), который является поддоменом подстановочного домена, на котором слушает Шлюз приложений (например, *.example.com)

Какую приблизительную конфигурацию мне нужно настроить в Шлюзе приложений? Я не могу понять …

Вариант 1:

Единый подстановочный слушатель (*.example.com)
Единое правило маршрутизации с подстановочным знаком (*example.com -> подстановочный пул бэкендов)
Единые универсальные настройки бэкенда (без переопределения имени хоста)
Единый подстановочный пул бэкендов (просто переслать запрос)

Но это невозможно, потому что пулы бэкендов не позволяют настраивать подстановочные FQDN

Вариант 2:

Единый подстановочный слушатель (*.example.com)
Явное правило маршрутизации, основанное на поддомене
Единые универсальные настройки бэкенда (без переопределения имени хоста)
Несколько пулов бэкендов

Но это также невозможно, так как правила маршрутизации не могут быть настроены для поддоменов (но могут для путей)

Вариант 3:

Слушатель для каждого поддомена (app1.example.com, app2.example.com и т.д.)
Правило маршрутизации для каждого поддомена
Единые универсальные настройки бэкенда (без переопределения имени хоста)
Пул бэкендов для каждого поддомена

Это возможно, но кажется чрезвычайно избыточным и громоздким – это также заставляет меня задуматься, зачем вообще нужна опция подстановки для слушателя?

Ответ или решение

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

Теория

Azure Application Gateway предоставляет возможность маршрутизации трафика на уровнях HTTP/HTTPS с различными функциональными возможностями, включая защиту веб-приложений и балансировку нагрузки. Одной из ключевых возможностей является использование SSL-ферментов, а также управление правилами маршрутизации на основе URL, что включает работы с поддоменами и путями.

Проблема с конфигурацией в данном случае связана с необходимостью использования поддоменов, где каждый Static Web App имеет свой поддомен, управляемый через Application Gateway. Стандартная схема предполагает настройку слушателей (Listeners), правил маршрутизации (Routing Rules) и пулов бэкендов (Backend Pools).

Пример

Возможности и ограничения:
- Wildcard Listener (*.example.com) позволяет охватывать множество поддоменов, но ограничен в функционале с точки зрения настройки конкретных маршрутов на уровне поддоменов.
- Пулы бэкендов не поддерживают использование подстановочных знаков (wildcards) для FQDN, что представляет собой главную проблему в настройке автоматической маршрутизации на уровне поддоменов.
Решения:
- Вариант 1: Использование одного wildcard Listener и общего правила маршрутизации кажется оптимальным на первый взгляд, но ограничено отсутствием поддержки подстановочных знаков в пулах бэкендов.
- Вариант 2: Здесь предполагается наличие специализированных правил маршрутизации для отдельных поддоменов, но это усложняется, так как правила уровня URL не поддерживают поддомены в качестве условий — только пути.
- Вариант 3: Каждое правило маршрутизации и слушатель настроены под конкретный поддомен, что позволяет обеспечить гибкость и точность маршрутизации, однако делает процесс настройки громоздким и сложным в поддержке.

Применение

Рассмотрим, как можно эффективно применять данные решения, учитывая ограничения и цели.

Анализ потребностей: Прежде всего, необходимо определить необходимость использования wildcard Listener. Если бюджет и сложность конфигурации не являются главными барьерами, то рассмотрение варианта 3 может оказаться наиболее разумным, так как позволяет достигать максимальной детализации управления и маршрутизации.
Эффективное использование ресурсов: В случае, если количество поддоменов ограничено и возможно управление группой приложений через объединенные правила, стоит обратить внимание на возможность использования путей внутри правил, что позволит сократить количество необходимых настройок.
Средства оптимизации: Для случаев, когда количество поддоменов динамично изменяется, можно рассмотреть автоматизацию процесса настройки через Azure Resource Manager (ARM) шаблоны или другие инструменты DevOps, такие как Terraform или Ansible. Это позволит автоматизировать создание и конфигурирование множества слушателей и правил.

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