Использование Azure Front Door в мультитенантном решении

Azure Front Door — это современная сеть доставки содержимого облака (CDN), которая обеспечивает быстрый, надежный доступ между пользователями и приложениями статического и динамического веб-содержимого по всему миру. В этой статье описываются некоторые функции Azure Front Door, которые полезны при работе в мультитенантных системах. Он также предоставляет другие связанные рекомендации и примеры.

При использовании Azure Front Door в составе мультитенантного решения необходимо принять некоторые решения на основе дизайна и требований вашего решения. Обратите внимание на следующие факторы:

• Рассмотрим количество клиентов, которые в настоящее время у вас есть, и количество клиентов, которые вы ожидаете в будущем.

• Определите, используете ли вы уровень приложения совместно с несколькими арендаторами, развертываете множество экземпляров однопользовательских приложений или развертываете отдельные пакеты развертывания, совместно используемые несколькими арендаторами.

• Определите, хотят ли клиенты принести собственные доменные имена.

• Определите, хотите ли вы использовать подстановочные домены.

• Оцените, нужно ли использовать собственные сертификаты TLS или позволить Майкрософт управлять вашими сертификатами TLS.

• Учитывайте квоты и ограничения , которые применяются к Azure Front Door. Определите, какие ограничения можно использовать при масштабировании решения. Если вы ожидаете приближение этих ограничений, рассмотрите возможность использования нескольких профилей Azure Front Door или настройки использования Azure Front Door для сохранения допустимых ограничений. Номер SKU уровня "Премиум" имеет более высокие ограничения, чем номер SKU уровня "Стандартный".

• Определите, имеют ли вы или ваши клиенты требования к фильтрации IP-адресов, геоблокировки или настройке правил брандмауэра веб-приложений.

• Убедитесь, что все серверы приложений клиентов имеют доступ к Интернету.

Функции Azure Front Door, поддерживающие мультитенантность

В этом разделе описаны несколько ключевых функций Azure Front Door, которые полезны для мультитенантных решений. В нем описывается, как Azure Front Door помогает настроить пользовательские домены, включая сведения о подстановочных доменах и сертификатах TLS. В нем также приведены сведения о том, как использовать возможности маршрутизации Azure Front Door для поддержки мультитенантности.

Личные домены

Azure Front Door предоставляет имя узла по умолчанию для каждой создаваемой конечной точки, например contoso.z01.azurefd.net. Но для большинства решений вы связываете собственное доменное имя с конечной точкой Azure Front Door. Пользовательские доменные имена позволяют использовать собственную фирменную символику и настраивать маршрутизацию на основе имени узла, включенного в запрос клиента.

В мультитенантном решении можно использовать доменные имена или поддомены для конкретного клиента и настроить Azure Front Door для маршрутизации трафика клиента в правильную группу источников для рабочей нагрузки этого клиента. Например, можно настроить имя личного домена, например tenant1.app.contoso.com. Вы можете настроить несколько пользовательских доменов в одном профиле Azure Front Door.

Дополнительные сведения см. в статье "Добавление личного домена в Azure Front Door".

Подстановочные домены

Подстановочные домены упрощают настройку записей системы доменных имен (DNS) и маршрутизацию трафика через Azure Front Door при использовании общих доменов и поддоменов, специфичных для каждого арендатора. Например, предположим, что клиенты получают доступ к своим приложениям с помощью поддоменов, таких как tenant1.app.contoso.com и tenant2.app.contoso.com. Вы можете настроить подстановочный домен *.app.contoso.com, вместо того чтобы настраивать каждый домен для конкретного клиента по отдельности.

Azure Front Door поддерживает создание пользовательских доменов, использующих подстановочные знаки. Затем можно настроить маршрут для запросов, поступающих на подстановочный домен. При подключении нового клиента вам не нужно перенастраивать DNS-серверы, выдавать новые сертификаты TLS или обновлять конфигурацию профиля Azure Front Door.

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

Azure Front Door не выдает управляемые сертификаты TLS для подстановочных доменов, поэтому необходимо приобрести и предоставить свой собственный сертификат.

Управляемые сертификаты TLS

Получение и установка сертификатов TLS может быть сложным процессом и подверженным ошибкам. Срок действия сертификатов TLS истекает через период времени, обычно один год, и его необходимо переустановить и переустановить, чтобы избежать нарушения трафика приложения. При использовании сертификатов TLS, управляемых Azure Front Door, корпорация Майкрософт отвечает за выдачу, установку и продление сертификатов для личного домена.

Исходное приложение может размещаться в другой службе Azure, которая также предоставляет управляемые сертификаты TLS, такие как Служба приложений Azure. Azure Front Door прозрачно работает с другой службой для синхронизации сертификатов TLS.

Если клиенты могут предоставлять свои собственные пользовательские домены и вы хотите, чтобы Azure Front Door выдает сертификаты для этих доменных имен, ваши клиенты не должны настраивать записи авторизации центра сертификации (CAA) на своих DNS-серверах. Эти записи могут блокировать выдачу сертификатов от имени ваших арендаторов службой Azure Front Door. Дополнительные сведения о мультитенантности см. в статье TLS и SSL-сертификаты в мультитенантных решениях. Дополнительные сведения об Azure Front Door см. в статье о шифровании TLS с помощью Azure Front Door.

Маршрутизация

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

Azure Front Door имеет мощный набор возможностей маршрутизации, которые могут поддерживать множество мультитенантных архитектур. Вы можете использовать маршрутизацию для распределения трафика между источниками в метке или отправки трафика на правильную метку для конкретного клиента. Вы можете настроить маршрутизацию на основе отдельных доменных имен, подстановочных доменных имен и путей URL-адресов. И вы можете использовать обработчик правил для дальнейшей настройки поведения маршрутизации.

Дополнительные сведения см. в разделе Общие сведения об архитектуре маршрутизации.

Обработчик правил

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

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

• Измените элементы HTTP-запроса перед отправкой в источник.

• Измените элементы HTTP-ответа, прежде чем он вернется клиенту.

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

В следующем примере подходы используют подсистему правил Azure Front Door в мультитенантном решении:

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

• Предположим, что вы развертываете многотенантный уровень приложения и используете путевую маршрутизацию, например, https://application.contoso.com/tenant1/welcome и https://application.contoso.com/tenant2/welcome для клиентов 1 и 2 соответственно. Можно использовать обработчик правил для извлечения сегмента идентификатора клиента из сегмента URL-пути и перезаписи URL-адреса, чтобы включить идентификатор клиента в параметр строки запроса или заголовок запроса для используемого приложения.

Дополнительные сведения см. в подсистеме правил Azure Front Door.

Примеры сценариев

В следующих примерах сценариев показано, как настроить различные мультитенантные архитектуры в Azure Front Door и как решения, которые вы принимаете, могут повлиять на конфигурацию DNS и TLS.

Многие мультитенантные решения используют паттерн Deployment Stamps. При использовании этого подхода развертывания обычно развертывается один общий профиль Azure Front Door и используется Azure Front Door для маршрутизации входящего трафика на соответствующую метку. Эта модель развертывания является наиболее распространенной, и в сценариях 1–4 в этой статье показано, как использовать ее для удовлетворения ряда требований.

Однако в некоторых случаях можно развернуть профиль Azure Front Door в каждой метке решения. Сценарий 5 описывает эту модель развертывания.

Сценарий 1. Домен подстановочных знаков, управляемый поставщиком, одна метка

Компания Contoso создает мультитенантное решение небольшого размера. Компания развертывает один штамп в одном регионе, и этот штамп обслуживает всех своих клиентов. Все запросы направляются на один сервер приложений. Компания Contoso решила использовать подстановочные домены для всех арендаторов, например tenant1.contoso.com и tenant2.contoso.com.

Компания Contoso развертывает Azure Front Door с помощью следующей конфигурации.

DNS configuration (Настройка DNS)

Одноразовая конфигурация: Contoso настраивает две записи DNS.

• Для записи *.contoso.com TXT с подстановочным знаком задано значение, указываемое Azure Front Door во время процесса подключения личного домена.

• Подстановочная запись CNAME *.contoso.com является псевдонимом конечной точки Azure Front Door Contoso contoso.z01.azurefd.net.

При подключении нового клиента: Дополнительная конфигурация не требуется.

Конфигурация протокола TLS

Одноразовая конфигурация: Компания Contoso покупает сертификат TLS с подстановочными знаками, добавляет его в хранилище ключей и предоставляет Azure Front Door доступ к хранилищу.

При подключении нового клиента: Дополнительная конфигурация не требуется.

Конфигурация Azure Front Door

Одноразовая конфигурация: Contoso создает профиль Azure Front Door и единую конечную точку.

• Они добавляют один личный домен с именем *.contoso.com и связывают сертификат TLS с ресурсом личного домена.

• Они настраивают одну группу источников, содержащую один источник для сервера приложений.

• Они настраивают маршрут для подключения личного домена к группе источников.

При подключении нового клиента: Дополнительная конфигурация не требуется.

Преимущества

• Этот сценарий относительно прост в настройке и предоставляет клиентам url-адреса с фирменной символикой Contoso.

• Такой подход поддерживает большое количество клиентов.

• При подключении нового клиента Contoso не требуется вносить изменения в сертификаты Azure Front Door, DNS или TLS.

Недостатки

• Этот подход не может легко масштабироваться за пределами одной метки или региона приложения.

• Компания Contoso должна приобрести сертификат TLS с подстановочными знаками и обновить и установить сертификат после истечения срока его действия.

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

Proseware создает мультитенантное решение для нескольких меток, развернутых как в Австралии, так и в Европе. Все запросы в одном регионе обслуживаются сервером в этом регионе. Как и Contoso, компания Proseware приняла решение использовать подстановочные доменные имена для всех арендаторов, такие как tenant1.proseware.com и tenant2.proseware.com.

Proseware развертывает Azure Front Door с помощью следующей конфигурации:

DNS configuration (Настройка DNS)

Одноразовая конфигурация: Proseware настраивает две записи DNS.

• Для записи *.proseware.com TXT с подстановочным знаком задано значение, указываемое Azure Front Door во время процесса подключения личного домена.

• Подстановочная запись CNAME *.proseware.com является псевдонимом для конечной точки Azure Front Door proseware.z01.azurefd.net компании Proseware.

При подключении нового клиента: Дополнительная конфигурация не требуется.

Конфигурация протокола TLS

Одноразовая конфигурация: Proseware покупает подстановочный сертификат TLS, добавляет его в хранилище ключей и предоставляет Azure Front Door доступ к хранилищу.

При подключении нового клиента: Дополнительная конфигурация не требуется.

Конфигурация Azure Front Door

Одноразовая конфигурация: Proseware создает профиль Azure Front Door и единственную конечную точку. Компания настраивает несколько групп источников, по одному для каждой метки приложения или сервера в каждом регионе.

При подключении нового клиента: Proseware добавляет ресурс личного домена в Azure Front Door.

• Они используют имя *.proseware.com и связывают подстановочный сертификат TLS с ресурсом пользовательского домена.

• Они создают маршрут, чтобы указать, в какую группу источников или метку должны направляться запросы арендатора. На предыдущей схеме маршрут tenant1.proseware.com ведет к группе источников в регионе Австралии, а маршрут tenant2.proseware.com ведет к группе источников в регионе Европы.

Преимущества

• При подключении новых клиентов изменения конфигурации DNS или TLS не требуются.

• Proseware поддерживает один экземпляр Azure Front Door для маршрутизации трафика на несколько меток в нескольких регионах.

Недостатки

• Proseware необходимо перенастроить Azure Front Door при каждом подключении нового клиента.

• Proseware необходимо обратить внимание на квоты и ограничения Azure Front Door, особенно на количество маршрутов и пользовательских доменов, а также на комплексное ограничение маршрутизации.

• Proseware необходимо приобрести wildcard-сертификат TLS.

• Proseware отвечает за продление и установку сертификата после истечения срока его действия.

Сценарий 3. Поддомены поддомена на основе меток, управляемые поставщиком

Fabrikam создает мультитенантное (многопользовательское) решение. Компания выпускает почтовые марки в Австралии и Соединенных Штатах. Все запросы в одном регионе обслуживаются сервером в этом регионе. Fabrikam использует домены на основе меток, например tenant1.australia.fabrikam.com, tenant2.australia.fabrikam.comи tenant3.us.fabrikam.com.

Компания развертывает Azure Front Door с помощью следующей конфигурации.

DNS configuration (Настройка DNS)

Одноразовая конфигурация: Fabrikam настраивает следующие две подстановочные знаки DNS для каждой метки.

• Для каждой метки подстановочные знаки TXT записываются с значениями *.australia.fabrikam.com и *.us.fabrikam.com, которые Azure Front Door задает во время процесса подключения и настройки личного домена.

• Для каждой метки подстановочные знаки CNAME и *.australia.fabrikam.com*.us.fabrikam.com являются псевдонимами для конечной точки fabrikam.z01.azurefd.netAzure Front Door.

При подключении нового клиента: Дополнительная конфигурация не требуется.

Конфигурация протокола TLS

Одноразовая конфигурация: Fabrikam покупает подстановочный сертификат TLS для каждой метки, добавляет их в хранилище ключей и предоставляет Azure Front Door доступ к хранилищу.

При подключении нового клиента: Дополнительная конфигурация не требуется.

Конфигурация Azure Front Door

Одноразовая конфигурация: Fabrikam создает профиль Azure Front Door и единую конечную точку.

• Они настраивают группу источников для каждой метки.

• Они создают пользовательские домены, используя подстановочный знак для каждого поддомена на основе меток: *.australia.fabrikam.com и *.us.fabrikam.com.

• Они создают маршрут для настраиваемого домена каждой метки для отправки трафика в соответствующую группу источников.

При подключении нового клиента: Дополнительная конфигурация не требуется.

Преимущества

• Такой подход позволяет Fabrikam масштабироваться до большого количества клиентов по нескольким меткам.

• При подключении новых клиентов изменения конфигурации DNS или TLS не требуются.

• Fabrikam поддерживает один экземпляр Azure Front Door для маршрутизации трафика на несколько меток в нескольких регионах.

Недостатки

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

• Компании Fabrikam необходимо приобрести несколько wildcard сертификатов TLS.

• Fabrikam отвечает за продление и установку сертификатов TLS при истечении срока их действия.

Сценарий 4. Ванити-домены

Adventure Works Cycles создает многопользовательское решение. Компания выпускает почтовые марки в нескольких регионах, таких как Австралия и Соединенные Штаты Америки. Все запросы в одном регионе обслуживаются сервером в этом регионе. Adventure Works позволяет своим клиентам принести собственные доменные имена. Например, клиент 1 может настроить имя личного домена, например tenant1app.tenant1.com.

Компания развертывает Azure Front Door с помощью следующей конфигурации.

DNS configuration (Настройка DNS)

Одноразовая конфигурация: Никакой.

При подключении нового клиента: Клиент должен создать две записи на собственном DNS-сервере.

• Запись TXT предназначена для проверки домена. Например, клиент 1 должен настроить запись TXT с именем tenant1app.tenant1.com и задать значение, указанное Azure Front Door во время процесса подключения личного домена.

• Запись CNAME является псевдонимом для конечной точки Azure Front Door компании Adventure Works. Например, арендатор 1 должен настроить запись CNAME с именем tenant1app.tenant1.com и сопоставить ее с adventureworks.z01.azurefd.net.

Конфигурация протокола TLS

Adventure Works и его клиенты должны решить, кто выдает сертификаты TLS:

• Самый простой вариант — использовать Azure Front Door для выдачи сертификатов и управления ими. Однако тенанты не должны настраивать записи CAA на своих DNS-серверах. Если они это сделают, записи могут не позволить центру сертификации Azure Front Door выдать сертификаты.

• Кроме того, клиенты могут предоставлять собственные сертификаты. Они должны работать с Adventure Works для отправки сертификата в хранилище ключей и предоставления доступа к Azure Front Door.

Конфигурация Azure Front Door

Одноразовая конфигурация: Adventure Works создает профиль Azure Front Door и одну конечную станцию. Они настраивают группу источников для каждой метки. Они не создают настраиваемые ресурсы домена или маршруты.

При подключении нового клиента: Adventure Works добавляет ресурс личного домена в Azure Front Door.

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

• Затем они создают маршрут, чтобы указать, в какую группу источников или метку должны направляться запросы арендатора. На предыдущей схеме tenant1app.tenant1.com направляется в группу источников в регионе Австралии и tenant2app.tenant3.com направляется в группу источников в регионе США.

Преимущества

• Клиенты могут предоставлять собственные доменные имена. Azure Front Door прозрачно маршрутизирует запросы к мультитенантному решению.

• Adventure Works поддерживает единственный экземпляр Azure Front Door для маршрутизации трафика к нескольким узлам в разных регионах.

Недостатки

• Adventure Works необходимо перенастроить Azure Front Door при каждом подключении нового клиента.

• Арендаторы должны участвовать в процессе подключения. Они должны вносить изменения DNS и, возможно, выдавать сертификаты TLS.

• Клиенты управляют записями DNS. Изменения записей DNS могут повлиять на их возможность доступа к решению Adventure Works.

• Adventure Works необходимо обратить внимание на квоты и ограничения Azure Front Door, особенно на количество маршрутов и пользовательских доменов, а также составной предел маршрутизации.

Сценарий 5. Профиль Azure Front Door для каждой метки

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

Если у вас есть печать, которая обслуживает нескольких арендаторов, необходимо рассмотреть, как вы направляете трафик к каждому арендатору. Просмотрите подходы, описанные в предыдущих сценариях. Рассмотрите возможность объединения подходов в соответствии с вашими требованиями.

Преимущества

• Если вы расширяете конфигурацию по нескольким профилям, вы с меньшей вероятностью достигнете ограничений ресурсов Azure Front Door. Например, если вам нужно поддерживать большое количество пользовательских доменов, можно разделить домены между несколькими профилями Azure Front Door и оставаться в пределах каждого профиля.

• Этот подход позволяет ограничить разрешения управления ресурсами Azure Front Door. Вы можете использовать управление доступом на основе ролей Azure для предоставления администраторам доступа к профилю одной метки.

Недостатки

• Этот подход обычно вызывает высокую стоимость, так как развертывается больше профилей. Дополнительные сведения см. в статье "Общие сведения о выставлении счетов Azure Front Door".

• Существует ограничение на количество профилей Azure Front Door, которые можно развернуть в одной подписке Azure. Дополнительные сведения см. в статье о квотах и ограничениях Azure Front Door.

• Необходимо настроить профиль Azure Front Door для каждой метки отдельно, а также управлять конфигурацией DNS, сертификатами TLS и конфигурацией TLS для каждой метки.

Соавторы

Корпорация Майкрософт поддерживает эту статью. Следующие авторы написали эту статью.

Основные авторы:

• Джон Даунс | Главный инженер программного обеспечения
• Радж Немани | Директор, Стратег технологий партнеров

Другие участники:

• Мик Альбертс | Технический писатель

• Фернандо Антиверо | Разработчик Fullstack и инженер облачной платформы

• Duong Au | Старший разработчик содержимого, C+E Skilling Content R&D

• Харкришнан М Б (Хари) | Продуктовый менеджер 2, Azure Networking

• Арсен Владимирский | Главный инженер по работе с клиентами, FastTrack для Azure

Чтобы просмотреть неопубликованные профили LinkedIn, войдите в LinkedIn.

Дальнейшие шаги

• Учебный курс. Введение в Azure Front Door
• Введение в Azure Front Door
• Что такое Azure Front Door?

Связанные ресурсы

• Проектирование мультитенантных решений в Azure
• Контрольный список для проектирования и создания мультитенантных решений в Azure
• Модели аренды для решения с несколькими арендаторами