Skip to main content

Ізоляцыя для мноства акаунтаў (Multi-Tenancy Isolation)

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

Стратэгія ізаляцыі​

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

Кожны суверенный акаунт павінен мець:

  • Асобную базу даных для акаунту ці стратэгію префікса базавых даных, запраўленую для хоста.
  • Асобны корынны прасторы файлавага прастору для акаунту.
  • Запіс у рэгістры акаунтаў, які звязвае сайт з яго базавай даней, корынным шляхам, імем ізаляцыйнай мадэллю.
  • Результат перапраўкі міграцыі перад тым, як акаунт пачаце паказваць на ўваход.

Звязь хоста базы даных (Database host binding)​

У версіі 1.2.0 змянена паводзіны па умолчанию для звязявання хоста аднаго і таго ж апарата для суверенных установок. Значэнні, якія ўключаюць "localhost", нормалізуюцца так, каб Bedrock, FrankenPHP і контейнераваныя устаноўкі WordPress могли даваць і праверджаць допуск прав на хост-сувязь, які бачыць MySQL.

Пры наладзе суверенного акаунту:

  1. Уставайце хост базы даных у значэнне, патрабаванае для працы акаунту.
  2. Выкорыстоўвай localhost для локальных сокета установок, калі хост чакае локальных з'яў.
  3. Выкорыстоўвай 127.0.0.1 або імя службы толькі таму, калі сервер базы даных надае прывілегіі гэтому хосту.
  4. Запусці пераправку міграцыі пасля змены звязявання хоста.

Калі праверка паказвае непасłaваныя допуск прав, параўняй допуск прав для корыстальніка базы даных акаунту з наладзе звязявання хоста. Корыстальнік, яму нададзены доступ для user@localhost, адрозны відэ [email protected] або user@%.

Корынны прастір файлавага прастору (Filesystem root)​

Коренева директорыя агантира (tenant root) павінна быць стабільнай пры перезапуску і разгольніцці. Пазбегай выкарыенных шляхоў для монтyngу. Для установок у стылі Bedrock праверце, што коран директоры адказвае на WordPress web root, які чакае бэст-старт (bootstrap) агантира, а не толькі на коран праекта.

Порядок прагрэсіі (Provisioning order)​

Для новых суверенных агантираў выкарыстоўвай гэты порядок:

  1. Стварыць запіс у рэгістры агантираў (tenant registry entry).
  2. Стварыць базу даных агантира і карыстальніка базы даных.
  3. Бэст-старт (Bootstrap) схемы агантира.
  4. Прагрэсіраваць корыстальнікаў агантира.
  5. Настройваць шляхі файловай сістэмы агантира.
  6. Выканаць праверку міграцыі.
  7. Змяніць маршруты прыладзіння (routing) або DNS пасля перавыхаду праверкі.

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

Працесі адпаведзе кліентаў суверенных агантираў (Sovereign customer management flows)​

Ultimate Multisite v2.13.0 патрабуе выконваць дзеянні кіравання кліента на асноўным сайце, калі практыкаваны рэжым суверенальнага ўстаноўкі (sovereign mode). Агантир можа працягваць працаваць як ізаляваную устаноўку WordPress, але дзеянні, якія завяршаюцца з кліентам і залежыць ад сеткавай тарыфікацыі, адоптыўнасці (membership) ці спяльнай дадзеных карыстальніцтва, павінны паказваць кліента на асноўны сайт, а не спрабаваць завяршыць дзеянне ў інтэрнальным працоўным агантиры.

Працес асноўнага сайту прымяняецца для:

  • Праверкі заказу (Checkout) і змены планавання.
  • Огляду карыстальніцтва і дзеянняў профилю кліента.
  • Падрыхтоўка адрасы ў рахункавай дакументацыі і экрана кіравання плацяжамі.
  • Глядальні паведамленні пра рахункі і гісторыі плацяжў.
  • Дзеянні кіравання сайтам, такія як дадавання або удаленне сайта.
  • Змена шаблона (Template switching).
  • Мапіраванне доменаў (Domain mapping) і змены асноўнага домена.

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

Для аператараў практычная палягвы такая: pages "Billing", "Account", "Checkout", "Invoice", "Template" і "Domain Management" павінны быць даступныя на асноўным саце для суверенных сеткі. Даштары тэнантских дэшкав могуць спасылацца на гэтыя pages, але асноўльны сайт застаецца вызначальным джаваным (source of truth) для гэтага дзеяння.