Перейти до основного вмісту

Ізоляція багатоорендованих систем (Multi-Tenancy Isolation)

Ultimate Multisite: Multi-Tenancy 1.2.0 підтримує ізоляцію бази даних та файлової системи для суверенних орендодавців (tenants). Це дозволяє тримати дані орендарів окремо, зберігаючи при цьому налаштування мережі, білінг та адміністрування.

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

Використовуйте суверенну ізоляцію для клієнтів, яким потрібне сильніше розділення даних, виділене сховище файлової системи або окремий межу хоста.

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

  • Виділену базу даних орендаря або стратегію префікса бази даних, затверджену для хоста.
  • Виділений корінь файлової системи орендаря (tenant filesystem root).
  • Запис у реєстрі орендарів, який відображає сайт на його базу даних, кореневий шлях, доменне ім'я та модель ізоляції.
  • Результат перевірки міграції перед тим, як орендар буде вважатися активним (live).

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

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

При налаштуванні суверенного орендаря:

  1. Встановіть хост бази даних на значення, необхідне для середовища виконання (runtime) орендаря.
  2. Використовуйте localhost для локальних сокетних інсталяцій, коли хост очікує локальні з'єднання.
  3. Використовуйте 127.0.0.1 або лише ідентифікатор сервісу (service hostname) лише тоді, коли сервер бази даних надає привілеї цьому хосту.
  4. Запустіть перевірку міграції після зміни прив'язки хоста.

Якщо результати перевірки показують помилки надання прав, порівняйте надання прав користувачу бази даних орендаря з налаштованою прив'язкою хоста. Користувач, якому надано права для user@localhost, відрізняється від [email protected] або user@%.

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

Коренева директорія орендаря має бути стабільною після перезавантажень та розгортань. Уникайте тимчасових шляхів монітування (mount paths). Для інсталяцій у стилі Bedrock переконайтеся, що коренева директорія орендаря вказує на корінь веб-сайту WordPress, який очікує бутстрап орендаря, а не лише на корінь проєкту.

Порядок налаштування (Provisioning order)​

Для нових суверенних орендарів використовуйте такий порядок:

  1. Створити запис у реєстрі орендаря (tenant registry entry).
  2. Створити базу даних орендаря та користувача бази даних.
  3. Бутстрапувати схему орендаря.
  4. Запросити користувачів орендаря.
  5. Налаштувати шляхи файлової системи орендаря.
  6. Провести перевірку міграції (migration verification).
  7. Змінити маршрутизацію або DNS після успішної перевірки.

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

Потоки управління суверенними клієнтами (Sovereign customer management flows)​

Ultimate Multisite v2.13.0 зберігає дії з управління клієнтами на головному сайті, коли режим суверенізованого режиму (sovereign mode) увімкнено. Орендар все одно може працювати як ізольована інсталяція WordPress, але дії, що стосуються клієнта і залежать від мережевого білінгу, членства чи даних спільного облікового запису, повинні повертати клієнта на головний сайт замість спроби завершити дію всередині середовища виконання орендаря.

Потік для головного сайту застосовується до:

  • Оформлення замовлень та змін плану.
  • Перегляд огляду облікового запису та дій про профіль клієнта.
  • Оновлення адрес білінгу та екранів управління платежами.
  • Перегляди рахунків-фактур та історії платежів.
  • Дії з управління сайтом, такі як додавання або видалення сайтів.
  • Зміна шаблону (Template switching).
  • Мапування доменів та зміни основних доменів.

Коли клієнт починає одну з цих дій із суверенного тенанта, Ultimate Multisite створює відповідний URL головного сайту та зберігає вихідний тенант як цільовий пункт повернення, коли це безпечно. Це дозволяє клієнту завершити керовану дію проти записів мережі, а потім повернутися до контексту тенанта без дублювання стану білінгу чи членства у суверенній базі даних.

Для операторів практичне правило таке: сторінки білінгу, облікового запису, оформлення замовлення (checkout), рахунку-фактури, шаблону та управління доменом мають залишатися доступними на головному сайті для суверенних мереж. Дашборди тенантів можуть посилатися на ці сторінки, але головний сайт залишається джерелом істини для виконання дії.