Рекомендации по использованию контейнерных приложений в мультитенантном решении
Приложения контейнеров Azure можно использовать для запуска микрослужб и контейнерных приложений на бессерверной платформе. В этой статье описаны некоторые функции контейнерных приложений, которые полезны для мультитенантных решений. Он также содержит ссылки на рекомендации, которые помогут вам на этапе планирования.
Модели изоляции
При работе с мультитенантной системой, используюющей контейнерные приложения, необходимо определить необходимый уровень изоляции. Контейнерные приложения поддерживают различные модели мультитенантности:
- Вы можете реализовать надежную мультитенантность с помощью общей среды. Например, эта модель может быть подходящей, если клиенты находятся в вашей организации.
- Вы можете реализовать враждебную мультитенантность , развернув отдельные среды для каждого клиента. Например, эта модель может быть подходящей, если вы не доверяете коду, выполняемого клиентами.
В следующей таблице перечислены различия между основными моделями изоляции аренды для контейнерных приложений. Модели описаны далее в этой статье.
| Рассмотрение | Одна среда для каждого клиента | Приложения контейнеров для конкретного клиента | Приложения общего контейнера |
|---|---|---|---|
| Изоляция данных | Высокая | Низкая | Низкая |
| Изоляция производительности | Высокая | Средняя. Нет сетевой изоляции. | Низкая |
| Сложность развертывания | Средняя | От низкого до среднего | Низкая |
| Операционная сложность | Средняя | Низкий | Низкая |
| Затраты на ресурсы | Высокая | Низкая | Низкая |
| Пример сценария | Выполнение враждебных мультитенантных рабочих нагрузок в изолированных средах для обеспечения безопасности и соответствия требованиям | Оптимизация затрат, сетевых ресурсов и операций для доверенных мультитенантных приложений | Реализация мультитенантного решения на уровне бизнес-логики |
Приложения общего контейнера
Возможно, вам нужно рассмотреть возможность развертывания общих контейнерных приложений в одной среде контейнеров, которая используется для всех клиентов.
Этот подход, как правило, экономит затраты, и это требует наименьших эксплуатационных накладных расходов, так как для управления ресурсами меньше.
Однако если вы хотите использовать эту модель изоляции, код приложения должен быть многотенантным. Эта модель изоляции не гарантирует изоляцию на уровне сети, вычислений, мониторинга или данных. Код приложения должен обрабатывать изоляцию клиента. Эта модель не подходит для враждебных рабочих нагрузок мультитенантности, в которых вы не доверяете работающему коду.
Кроме того, эта модель потенциально подвержена шумным проблемам соседей: рабочая нагрузка одного клиента может повлиять на производительность рабочей нагрузки другого клиента. Если требуется предоставить выделенную пропускную способность для устранения этой проблемы, модель общих приложений контейнеров может не соответствовать.
Примечание.
Шаблон меток развертывания полезен, если клиенты находятся в разных моделях затрат. Например, клиенты могут быть назначены общим или выделенным средам контейнерных приложений в зависимости от ценовой категории. Эта стратегия развертывания позволяет выйти за пределы контейнеров приложений для одной подписки на регион и масштабировать линейно по мере увеличения числа клиентов.
Приложения контейнеров для конкретного клиента
Другой подход, который можно рассмотреть, заключается в изоляции клиентов путем развертывания приложений контейнеров для конкретного клиента в общей среде.
Эта модель изоляции обеспечивает логическую изоляцию между каждым клиентом. Вы получите следующие преимущества:
- Экономичность. Предоставляя общий доступ к среде приложений-контейнерам, виртуальной сети и другим подключенным ресурсам, таким как рабочая область Log Analytics, вы можете сократить общую сложность затрат и управления для каждого клиента.
- Разделение обновлений и развертываний. Двоичные файлы приложений каждого клиента можно развертывать и обновлять независимо от других приложений контейнеров в той же среде. Этот подход может быть полезным, если вам нужно обновить разные клиенты до определенных версий кода в разное время.
- Изоляция ресурсов. Каждое приложение-контейнер в вашей среде выделяет собственные ресурсы ЦП и памяти. Если для конкретного клиента требуется больше ресурсов, можно выделить больше ЦП и памяти для конкретного приложения контейнера этого клиента. Помните, что в контейнерных приложениях есть ограничения на общее выделение ЦП и памяти.
Однако этот подход не обеспечивает аппаратной или сетевой изоляции между клиентами. Все приложения-контейнеры в одной среде используют одну виртуальную сеть. Необходимо доверять тому, что рабочие нагрузки, развернутые в приложениях, не будут использовать общие ресурсы.
Контейнерные приложения имеют встроенную поддержку Dapr, которая использует модульную структуру для предоставления функциональных возможностей в качестве компонентов. В контейнерных приложениях компоненты Dapr — это ресурсы уровня среды. При совместном использовании одной среды между несколькими клиентами убедитесь, что вы правильно обустраиваете компоненты Dapr в правильном приложении контейнера для конкретного клиента, чтобы гарантировать изоляцию и избежать риска утечки данных.
Примечание.
Не используйте редакции для создания разных версий приложения для разных клиентов. Редакции не обеспечивают изоляцию ресурсов. Они предназначены для сценариев развертывания, в которых необходимо иметь несколько версий приложения, работающих в рамках процесса развертывания обновлений, как в сине-зеленых развертываниях и тестировании A/B.
Одна среда для каждого клиента
Вы можете рассмотреть возможность развертывания одной среды приложений контейнеров для каждого клиента. Среда "Приложения контейнеров" — это граница изоляции для группы приложений-контейнеров. Среда обеспечивает вычисление и сетевую изоляцию на плоскости данных. Каждая среда развертывается в собственной виртуальной сети, которая предоставляется всем приложениям в среде. Каждая среда имеет собственную конфигурацию Dapr и мониторинга.
Этот подход обеспечивает самый сильный уровень изоляции данных и производительности, так как данные и трафик каждого клиента изолированы в определенной среде. И при использовании этой модели приложения не должны быть многотенантными. При использовании этого подхода у вас есть более детальный контроль над выделением ресурсов для контейнерных приложений в среде. Вы можете определить выделения на основе требований клиента. Например, для некоторых клиентов может потребоваться больше ресурсов ЦП и памяти, чем другие, поэтому вы можете предоставить больше ресурсов для приложений этих клиентов, используя изоляцию, которую предоставляют среды для конкретного клиента.
Однако есть низкие ограничения на количество сред, которые можно развернуть в подписке в каждом регионе. В некоторых ситуациях эти квоты можно увеличить, создав поддержка Azure билет.
Перед реализацией этой модели изоляции необходимо знать ожидаемый рост числа клиентов. Имейте в виду, что этот подход часто вызывает более высокую общую стоимость владения, а также более высокий уровень сложности развертывания и эксплуатации из-за дополнительных ресурсов, необходимых для развертывания и управления ими.
Функции контейнеров, поддерживающие мультитенантность
Личные доменные имена
Контейнерные приложения позволяют использовать ПОДстановочные знаки DNS и добавлять собственные подстановочные сертификаты TLS. При использовании поддоменов для конкретного клиента поддомены подстановочные знаки DNS и TLS позволяют легко масштабировать решение до большого количества клиентов без необходимости вручную перенастроить каждый новый клиент.
В контейнерных приложениях вы управляете сертификатами на уровне среды. Ingress также необходимо включить для приложения-контейнера, прежде чем можно привязать к нему личный домен.
Запрос проверки подлинности и авторизации
Контейнерные приложения могут проверять маркеры проверки подлинности от имени приложения. Если запрос не содержит маркер, маркер недействителен или запрос не авторизован, можно настроить контейнерные приложения для блокировки запроса или перенаправления его поставщику удостоверений, чтобы пользователь смог войти в систему.
Если клиенты используют идентификатор Microsoft Entra в качестве поставщика удостоверений, вы можете настроить контейнерные приложения для проверки маркеров пользователей с помощью /common endpoint . Это гарантирует, что независимо от клиента Microsoft Entra пользователя, их маркеры проверяются и принимаются.
Вы также можете интегрировать контейнерные приложения с Azure Active Directory B2C для проверки подлинности пользователей с помощью поставщиков удостоверений партнеров.
Дополнительные сведения см. в следующих ресурсах:
- Авторизация приложений контейнеров Azure
- Включение проверки подлинности и авторизации в приложениях контейнеров Azure с помощью идентификатора Microsoft Entra
Примечание.
Функции проверки подлинности и авторизации в контейнерных приложениях аналогичны функциям в службе приложение Azure. Однако существуют некоторые различия. Дополнительные сведения см. в статье "Рекомендации по использованию встроенной проверки подлинности".
Управляемые удостоверения
Управляемые удостоверения можно использовать из идентификатора Microsoft Entra, чтобы разрешить приложению-контейнеру доступ к другим ресурсам, прошедшим проверку подлинности с помощью идентификатора Microsoft Entra. При использовании управляемых удостоверений приложение-контейнер не требует управления учетными данными для обмена данными между службами. Вы можете предоставить определенные разрешения для удостоверения приложения контейнера для управления доступом на основе ролей.
При использовании управляемых удостоверений следует учитывать выбор модели изоляции. Например, предположим, что вы делитесь своими приложениями-контейнерами между всеми клиентами и развертываете базы данных для конкретного клиента. Необходимо убедиться, что одно приложение клиента не может получить доступ к другой базе данных клиента.
Дополнительные сведения см. в разделе "Управляемые удостоверения" в приложениях контейнеров Azure.
Соавторы
Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.
Основные авторы:
- Даниэль Ларсен | Главный инженер клиента, FastTrack для Azure
- Уилл Велида | Инженер клиента 2, FastTrack для Azure
Другие участники:
- Джон Даунс | Главный инженер программного обеспечения
- Чад Киттель | Главный инженер программного обеспечения, Корпорация Майкрософт
- Xuhong Liu | Старший инженер службы, FastTrack для Azure
- Аартхи Муруган | Старший руководитель программы, CS Tech Strategy App Innovation
- Кендалл Роден | Старший диспетчер программ, приложения контейнеров Azure
- Паоло Сальватори | Главный инженер клиента, FastTrack для Azure
- Арсен Владимирский | Главный инженер клиента, FastTrack для Azure
Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.