Перейти к основному содержимому

Изоляция многоарендных систем (Multi-Tenancy Isolation)

Ultimate Multisite: Multi-Tenancy 1.2.0 поддерживает изоляцию базы данных и файловой системы на уровне каждого субсайта для суверенных арендаторов. Это позволяет хранить данные арендатора отдельно, сохраняя при этом сетевое предоставление ресурсов, выставление счетов и администрирование.

Стратегия изоляции​

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

Каждый суверенный арендатор должен иметь:

  • Выделенную базу данных арендатора или стратегию префикса базы данных, одобренную хостом.
  • Выдельный корень файловой системы для арендатора.
  • Запись в реестре арендаторов, которая сопоставляет сайт с его базой данных, корневым путем, именем хоста и моделью изоляции.
  • Результат проверки миграции перед тем, как арендатор будет считаться активным (live).

Привязка к хосту базы данных (Database host binding)​

Версия 1.2.0 изменяет поведение по умолчанию при привязке к одной машине для суверенных установок. Значения типа localhost нормализуются таким образом, чтобы Bedrock, FrankenPHP и контейнеризированные установки WordPress могли предоставлять и проверять разрешения относительно строки хоста, которую видит MySQL на самом деле.

При настройке суверенного арендатора:

  1. Установите хост базы данных на значение, требуемое средой выполнения (runtime) арендатора.
  2. Используйте localhost для установок с локальными сокетами, когда хост ожидает локальных подключений.
  3. Используйте 127.0.0.1 или имя службы только тогда, когда сервер базы данных предоставляет привилегии этому хосту.
  4. Запустите проверку миграции после изменения привязки к хосту.

Если проверка показывает сбои в предоставлении разрешений, сравните разрешения пользователя в БД арендатора с настроенной привязкой к хосту. Пользователь, которому предоставлены права для user@localhost, отличается от [email protected] или user@%.

Корень файловой системы (Filesystem root)​

Корневая директория арендатора должна быть стабильной при перезапусках и развертываниях. Избегайте временных путей монтирования. Для установок в стиле Bedrock убедитесь, что корневая директория арендатора указывает на корень веб-приложения WordPress, ожидаемый загрузчиком (bootstrap) арендатора, а не только на корневую папку проекта.

Порядок развертывания​

Для новых суверенных арендаторов используйте следующий порядок:

  1. Создать запись в реестре арендатора.
  2. Создать базу данных и пользователя базы данных для арендатора.
  3. Загрузить схему (bootstrap) арендатора.
  4. Развернуть пользователей арендатора.
  5. Настроить пути файловой системы арендатора.
  6. Выполнить проверку миграции.
  7. Переключить маршрутизацию или DNS после успешной проверки.

Такой порядок гарантирует, что частично изолированные арендаторы не получат трафик до того, как база данных, пользователи и файловая система будут готовы.

Рабочие процессы управления суверенными клиентами​

Ultimate Multisite v2.13.0 сохраняет действия по управлению клиентами на основном сайте при включенном суверенном режиме. Арендатор все еще может работать как изолированная установка WordPress, но действия, связанные с клиентом и зависящие от сетевого биллинга, членства или общих данных учетной записи, должны возвращать клиента на основной сайт вместо попытки выполнить действие внутри среды выполнения (runtime) арендатора.

Основной рабочий процесс применяется к следующим действиям:

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

Когда клиент начинает одно из этих действий в суверенном тенанте Ultimate Multisite создает соответствующий URL основного сайта и сохраняет исходный тенант как целевой пункт возврата, когда это безопасно. Это позволяет клиентам выполнить управляемое действие с учетом сетевых записей, а затем вернуться в контекст тенанта, не дублируя при этом информацию о выставлении счетов или членстве в суверенной базе данных.

Для операторов практическое правило таково: страницы выставления счетов (billing), учетной записи (account), оформления заказа (checkout), счета (invoice), шаблона (template) и управления доменом (domain-management) должны оставаться доступными на основном сайте для суверенных сетей. Панели тенантов могут ссылаться на эти страницы, но основной сайт остается источником истины для выполнения действия.