Skip to main content

Изолација за повеќе најмувачи (Multi-Tenancy Isolation)

Ultimate Multisite: Multi-Tenancy 1.2.0 поддржува изолација на базата на податоци и файловата система за секој подсајт, што овозможува суверенни најмувачи. Ова ги држи податоците на најмувачот одделени додека се чува провизионирањето на ниво на мрежа, фактурирањето и администрацијата.

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

Користи суверенна изолација за клиентите кои бараат посилна одделена податочна изолација, посветено складиште за файлови или посебна граница на хостот.

Секој суверен најмувач треба да има:

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

Поврзување на хостот на базата на податоци (Database host binding)​

Верзија 1.2.0 менува стандардното пореќење на хостот на машина за суверен инсталации. Значиња како localhost се нормализираат така што Bedrock, FrankenPHP и контейнеризирани WordPress инсталации можат да даваат и да верификуваат дозволи против нивната истиски (host string) MySQL навистина ја гледа.

При конфигурација на суверен најмувач:

  1. Постави го хостот на базата на податоци на вредноста што е потребна за ранување на најмувачот (tenant runtime).
  2. Користи localhost за локални сокети инсталации кога хостот очекува локални поврзувања.
  3. Користи 127.0.0.1 или име на услугаски хост само кога серверот на базата на податоци му дава привилегии на тој хост.
  4. Изврши верификација на миграција по промена на поврзувањето на хостот.

Ако верификацијата покажува грешки во давањето дозволи, сравни ги давањето дозволи за корисник на базата на податоци со конфигурираното поврзување на хостот. Корисникот што му е даден за user@localhost е различен од [email protected] или user@%.

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

Корениот директориум на ломисе (tenant root) треба да биде стабилен при рестарти и деплојменти. Избегнувајте временски монтирачки патишта. За инсталации со стил Bedrock, потврдете дека корениот директориум на ломисот укажува на WordPress веб корен што го очекува бутстрапот на ломисот, а не само на проект корен.

Редослед на провизионирање (Provisioning order)​

За нови суверенни ломиси, користете овој ред:

  1. Создадете влез во регистрот на ломисите (tenant registry entry).
  2. Создадете базата на податоци за ломисот и корисникот на базата на податоци (database user).
  3. Бутстрапирајте ја шемата на ломисот (tenant schema).
  4. Провизионирајте ломисови корисници.
  5. Конфигурирајте ги патиштата на файлосистемот на ломисот.
  6. Извршете верификација на миграциите (migration verification).
  7. Префрлете рутингот или DNS по успешно завршена верификација.

Овој ред спречува деловично изолирани ломиси да добијат посебна трафикова преку пред тоа што базата на податоци, корисниците и файлосистемот не бидат подготвени.

Процеси за управување со суверенски клиенти (Sovereign customer management flows)​

Ultimate Multisite v2.13.0 задржува активностите за управување со клиентите на главниот сайт кога е овозможен суверен режим. Ломисот сè уште може да работи како изолирана инсталација на WordPress, но актуалните дела што зависат од мрежно биलिंग, членство или податоци од заеднички акаунти треба да го вратат клиентот на главниот сайт наместо да се обидат да завршат акцијата во време на работа на ломисот.

Процесот за главниот сайт се применува за:

  • Промена на плаќање и планови (Checkout and plan changes).
  • Преглед на акаунтот и дела со профилот на клиентот (Account overview and customer profile actions).
  • Ажурирање на адресата за биलिंग и екрани за управување со плаќање (Billing address updates and payment-management screens).
  • Прегледи на фактури и историја на плаќања (Invoice and payment-history views).
  • Активности за управување со сайтовите, како што е додадење или бришење сайт (Site management actions such as adding sites or deleting a site).
  • Промена на шаблони (Template switching).
  • Мапирање на домени и промена на примарниот домен (Domain mapping and primary-domain changes).

Кога корисникот започнува некоја од овие дејствија од суврен тенент, Ultimate Multisite гради соодветна URL на главната локација и зачувува изворниот тенент како целна точка за враќање (return target), кога е безбедно. Ова им овозможува на корисниците да завршат управуваното дејствие против мрежни записи, а потоа да се вратат во контекстот на тенентот без да дуплираат фактурирање или состојба на членство во суврен базата на податоци.

За операторите, практичните правила се: оставете страниците за фактурирање (billing), акаунт (account), чекаут (checkout), фактура (invoice), шаблон (template) и управување со домен (domain-management) достапни на главната локација за сувренте мрежи. Тенентските дашбордови можат да вршат линк кон овие страници, но главната локација останува изворот на вистинка (source of truth) за дејствието.