Մի քանի տնօրինակների անկախություն (Multi-Tenancy Isolation)
Ultimate Multisite: Multi-Tenancy 1.2.0-ը աջակցում է յուրաքանչյուր ենթատարածքի համար առանձին բազայի և ֆայլային համակարգի անկախության (isolation)՝ ինքնին տիրապետող հաճախորդների համար։ Սա պահպանում է հաճախորդի տվյալները առանձին, միևնույն ժամանակ պահպանելով ցանցային մակարդակի տրամադրումը (provisioning), հաշվարկները (billing) և վարչական գործողությունները։
Անկախության ռազմավարություն (Isolation strategy)
Օգտագործեք տիրապետող անկախություն (sovereign isolation) այն հաճախորդների համար, ովքեր պահանջում են ပိုմակարտ անվտանգության բաժանում, հատուկ ֆայլային տարածքի պահպանում կամ առանձին հոստիի սահման։
Յուրաքանչյուր տիրապետող տնօրինակ պետք է ունենա.
- Հատուկ տնօրինակի բազա (tenant database) կամ հոստիի համար հաստատված բազայի նախածանցի (database prefix strategy) ստեղծում։
- Հատուկ տնօրակի ֆայլային համակարգի արմատ (dedicated tenant filesystem root)։
- Տնօրակի գրանցման մուտքագրում (tenant registry entry), որը կապում է սайտը դրա բազայի, արմատական ուղու (root path), հոստի անունի (hostname) և անկախության մոդելի հետ։
- Միգրացիայի վավերացման արդյունք (migration verification result)՝ տնօրակը համարվելու կենդանի (live) լինելուց առաջ։
Բազայի հոստիի կապակցում (Database host binding)
Տարբերակ 1.2.0-ը փոխում է ստանդարտ «միևնույն մեքենայով» հոստիի կապակցման վարքագիծը տիրապետող (sovereign) ինստալացիաների համար։ Միևնույն մեքենայի արժեքները, ինչպիսին է localhost-ը, նորմալացվում են այնպես, որ Bedrock-ը, FrankenPHP-ը և կոնտեյներով (containerized) WordPress ինստալացիաները կարողանան թույլ տալ և ստուգել թույլտվությունները հոստիի տողի (host string) համապատասխան MySQL-ին։
Տիրապետող տնօրակ կազմաձևելիս.
- Սահմանեք բազայի հոստին այն արժեքով, որը պահանջում է տնօրակի runtime-ի (տեղական գործարկման)։
- Օգտագործեք
localhost-ը տեղական սոկետային ինստալացիաների համար, երբ հոստինը սպասում է տեղական կապեր։ - Օգտագործեք
127.0.0.1կամ միայն սերվիսի անուն (service hostname), միայն այն դեպքում, եթե բազայի սերվերը տալիս է այդ հոստինին իրավունքներ։ - Կատարեք միգրացիայի վավերացումը՝ հոստիի կապակցում փոխելուց հետո։
Եթե վավերացումը ցույց է տալիս թույլտվությունների բացակայություն (grant failures), համեմատեք տնօրակի բազայի օգտվողի (DB user) տրամադրված իրավունքները կազմաձևված հոստիի կապակցման հետ։ user@localhost-ին տրամադրված օգտվողը տարբեր է [email protected]-ից կամ user@%-ից։
Ֆայլային համակարգի արմատ (Filesystem root)
Անվտանգության արմատը (tenant root) պետք է կայուն լինի վերաբերում վերաբերում վերագործարկմաններին և տեղադրություններին։ Խուսափեք ժամանակավոր մոնտաժային ուղիներից։ Bedrock-ոիլի (Bedrock-style) տեղադրումների համար ստուգեք, որ անվտանգության արմատը ցույց է տալիս WordPress-ի վեբ արմատը, որը ենթադրվում է տենանտի բութստրափի (bootstrap) կողմից, այլ ոչ միայն նախագծի արմատը։
Հաստատման հերթականություն (Provisioning order)
Նոր սովրենային տենանտների համար օգտագործեք հետևյալ հերթականությունը.
- Ստեղծել տենանտի գրանցման մուտքը (tenant registry entry):
- Ստեղծել տենանտի բազան և բազայի օգտվողը։
- Բութստրափել տենանտի սխեման (schema)։
- Անվտանգության տենանտի օգտվողները (users) ստեղծել։
- Կազմաձևել տենանտի ֆայլային ուղիները (filesystem paths)։
- Կատարել մIGRATION-ի հաստատումը (migration verification)։
- Հաստատման անցնելուց հետո փոխել ռուտինգը կամ DNS-ը։
Այս հերթականությունը կանխում է, որ մասնակիորեն մեկուսացված տենանտները չստանան տրաֆիկ նախքան այնպես, երբ բազայի գրողը (writer), օգտվողները և ֆայլային համակարգը պատրաստ լինեն։
Սովրենային հաճախորդների կառավարման հոսքեր (Sovereign customer management flows)
Ultimate Multisite v2.13.0-ում, երբ «sovereign mode»-ը 켜ված է, հաճախորդների կառավարման գործողությունները մնում են հիմնական սայթի վրա։ Տենանտը կարող է դեռ աշխատել որպես մեկուսացված WordPress տեղադրում, բայց հաճախորդների հետ կապված գործողությունները, որոնք կախված են ցանցային հաշվարկներից (billing), անդամակցության (membership) կամ ընդհանուր հաշվի տվյալներից, պետք է հաճախորդին վերադարձնեն հիմնական սայթը՝ փոխանակ մեկուսացված runtime-ում գործողությունը ավարտելու փորձ անելու։
Հիմնական սայթի հոսքերը կիրառվում են հետևյալ դեպքերի համար.
- Checkout և պլանների փոփոխություններ։
- Հաշվի ընդհանուր տեսքը (Account overview) և հաճախորդի պրոֆիլի գործողությունները։
- Հաշվարկային հասցեի թարմացումներ և վճարումների կառավարման էջեր։
- Ինվոի (Invoice) և վճարումների պատմության տեսանյութերը։
- Սայթի կառավարման գործողություններ, ինչպիսիք են սայթերի ավելացումը կամ հեռացումը։
- Տեխնոլոգիական ձևաչափների (Template) փոփոխություն։
- Դոմենի քարտեզագրում և առաջնային տիրույթի (primary-domain) փոփոխություններ։
Երբ հաճախորդը որևէ այս գործողություն սկսում է իր ինքնուրույն տեխնիկական տարածուցված (sovereign) տեղից, Ultimate Multisite-ը կառուցում է համապատասխան հիմնական կայքի URL-ը և պահպանում է սկզբնական տեղին որպես վերադարձի թիրախ (return target), երբ դա անվտանգ է։ Սա թույլ է տալիս հաճախորդներին կատարել կառավարված գործողությունը՝ ցանցային գրանցումների համեմատ, այնուհետև վերադառնալ տեղի համատեքստին առանց բิลինգի կամ անդամակցության վիճակի կրկնվող տվյալներ մուտքագրելու։
Գործողների համար գործնական կանոնն այսպես է. պահպանեք հիմնական կայքում բิลինգի, հաշվի, գնումների (checkout), հաշվիվարկի (invoice), տեխնոլոգիական տողերի (template) և ադմինիստրացիայի (domain-management) էջերը՝ սոвереին ցանցերի համար։ Տեղային տեխնիկական վահանակները (Tenant dashboards) կարող են հղումներ կատարել այդ էջերին, բայց հիմնական կայքը մնում է գործողության ճշմարտության միակ աղբյուրը։