მრავალ-ტენანcyjული იზოლაცია (Multi-Tenancy Isolation)

Ultimate Multisite: Multi-Tenancy 1.2.0 მხარს უჭერს თითოეული სუბსაიტის მონაცემთა ბაზას და ფაილის სისტემის იზოლაციას სუვერენული ტენანტებისთვის. ეს ინარჩუნებს ტენანტის მონაცემების ცალკეობას, đồng thời ინარჩუნებს ქსელის დონის პრო비ჯენინგს (provisioning), ბილინგს (billing) და ადმინისტრირებას.

იზოლაციის სტრატეგია (Isolation strategy)

გამოიყენეთ სუვერენული იზოლაცია იმ მომხმარებლებისთვის, რომლებსაც სჭირდებათ უფრო ძლიერი მონაცემთა განცალკევება, სპეციალური ფაილის სისტემის შენახვის ადგილი ან ცალკე ჰოსტის ბარიერის დადგენა.

ყოველი სუვერენული ტენანტისთვის უნდა არსებოდეს:

• სპეციალური ტენანტის მონაცემთა ბაზა ან ბაზის პრეፊქსის სტრატეგია, რომელიც დამტკიცებულია ჰოსტისთვის.
• ცალკე ფაილის სისტემის ძირეული დირექტორია (tenant filesystem root).
• ტენანტის რეესტრის ჩანაწერი, რომელიც აკავშირებს საიტს მის მონაცემთა ბაზასთან, ძირითად გზასთან (root path), ჰოსტнейმთან და იზოლაციის მოდელთან.
• მიგრაციის გადამოწმების შედეგი იმის შემდეგ, სანამ ტენანტი "ოპერაციულ" (live) იქნება.

მონაცემთა ჰოსტის ბაინდინგი (Database host binding)

ვერსია 1.2.0 ცვლის დეფოლტს ერთი და იმავე მანქანაზე არსებული ჰოსტის ბაინდინგის ქცევას სუვერენული ინსტალაციებისთვის. ერთი და იმავე მანქანის მნიშვნელობები, როგორიცაა localhost, ნორმალიზდება ისე, რომ Bedrock, FrankenPHP-სა და კონტეინერიზებულ WordPress ინსტალაციებს შეეძლოთ უფლებების მიცემა და გადამოწმება ჰოსტის სტრინგის მიმართ, რომელსაც MySQL რეალურად ხედავს.

როდესაც სუვერენული ტენანტის კონფიგურირებას აკეთებთ:

1. დააყენეთ მონაცემთა ჰოსტი იმ მნიშვნელობით, რომელიც საჭიროა ტენანტის 运行时 (runtime) დროისთვის.
2. გამოიყენეთ localhost ადგილობრივი სოკეტის ინსტალაციებისთვის მაშინ, როდესაც ჰოსტი ადგილობრივ კავშირებს ელოდება.
3. გამოიყენეთ 127.0.0.1 ან მხოლოდ სერვისის ჰოსტის სახელი იმ შემთხვევაში, თუ მონაცემთა სერვერი ამ ჰოსტს უფლებებს აძლევს.
4. გაუშვით მიგრაციის გადამოწმება ჰოსტის ბაინდინგის შეცვლის შემდეგ.

თუ გადამოწმების შედეგად გამოჩნდება უფლებების უარყოფა (grant failures), შეადარეთ ტენანტის DB მომხმარებლების უფლებები კონფიგურირებულ ჰოსტ ბაინდინგს. user@localhost-ისთვის მიცემული უფლება განსხვავებულია [email protected] ან user@%-ისგან.

ფაილის სისტემის ძირეული დირექტორია (Filesystem root)

ტანტენტის जड़ (root) უნდა იყოს სტაბილური გადატვირთვების და დეპლოייმენტების დროს. თავიდან აიციleyin დროებითი mount path-ები. Bedrock-ს სტილის ინსტალებებისთვის, დაადასტურეთ, რომ ტანტენტის root მიუთითებს WordPress-ის ვებ-რუტზე, რომელსაც ტანტენტის ბBootstrap ელოდება, და არა მხოლოდ პროექტის root-ზე.

მომზადების თანმიმდევრობა (Provisioning order)

ახალი სუვერენული ტანტენტებისთვის გამოიყენეთ ეს თანმიმდევრობა:

1. შექმენით ტანტენტის რეესტრის ჩანაწერი (tenant registry entry).
2. შექმენით ტანტენტის მონაცემთა ბაზა და მონაცემთა ბაზის მომხმარებელი (database user).
3. გაუშვით ტანტენტის სქემა (schema) Bootstrap-ი.
4. შექმენით ტანტენტის მომხმარებლები (tenant users).
5. დააკონფიგურიруეთ ტანტენტის ფაილის სისტემის გზები (filesystem paths).
6. გაუშვით მიგრაციის გადამოწმება (migration verification).
7. გადართეთ მარშრუტები ან DNS-ი გადამოწმების წარმატებით დასრულების შემდეგ.

ეს თანმიმდევრობა ხელს უშლის იმას, რომ ნაწილობრივ იზოლირებული ტანტენტებს ტრაფიკი არ მიუწვდეთ სანამ მონაცემთა ბაზის მწერლობა (writer), მომხმარებლები და ფაილის სისტემა მზად იქნება.

სუვერენული მომხმარებლის მართვის ნაკადები (Sovereign customer management flows)

Ultimate Multisite v2.13.0-ში, როდესაც სუვერენული რეჟიმი ჩართულია, მომხმარებლის მართვის მოქმედებები ძირითadic ვებსაიტზე რჩება. ტანტენტი მაინც შეიძლება იმუშაოს როგორც იზოლირებული WordPress ინსტალაცია, მაგრამ მომხმარებელთან დაკავშირებული ქმედებები, რომლებიც დამოკიდებულია ქსელურ ბილინგზე (billing), წევრობაზე ან საერთო ანგარიშებზე მონაცემებზე, უნდა გაუგზავნოს მომხმარებელი ძირითadic ვებსაიტზე და არა იმის დასრულების მცდელობისთვის, რომ ეს ქმედება ტანტენტის runtime-ში თავად შესრულდეს.

ძირითადი ვებსაიტის ნაკადი ვრცელდება შემდეგზე:

• შეკვეთაზე და გეგმის ცვლილებებზე (Checkout and plan changes).
• ანგარიშის მიმოხილვაზე და მომხმარებლის პროფილის ქმედებებზე.
• ბილინგის მისამართების განახლება და გადახდის მართვის ეკრანებზე.
• ინვოისებისა და გადახდის ისტორიის ნახვებზე.
• ვებსაიტის მართვის ქმედებებზე, როგორიცაა ვებსაიტების დამატება ან წაშლა.
• შაბლონების (Template) შეცვლაზე.
• დომეინის 맵ინგსა და პრიმატ ძირითადი დომეინის ცვლილებებზე.

როდესაც მომხმარებელი ამ ქმედებებს ერთ-ერთი მათგანის სოლიდური ტენანტიდან იწყებს, Ultimate Multisite აგებს შესაბამის მთავარი საიტის URL-ს და ინახავს წყარო ტენანტს როგორც დაბრუნების მიზანს, თუ ეს უსაფრთხოა. ეს საშუალებას აძლევს მომხმარებლებს შეასრულონ მართული ქმედება ქსელის ჩანაწერებთან და შემდეგ დაბრუნდნენ ტენანტის კონტექსტში, senza გაბில்லிინგის ან წევრობის მდგომარეობის დუბლირების სოლიდურ მონაცემთა ბაზაში.

ოპერატორებისთვის პრაქტიკული წესი ასეთია: მთავარ საიტზე უნდა დარჩეს ბილინგის (billing), ანგარიშის (account), ჩეკაუტის (checkout), ინვოისის (invoice), შაბლონის (template) და დომეინის მართვის გვერდები სოლიდურ ქსელებისთვის. ტენანტების Dashboard-ებს შეუძლიათ ამ გვერდებზე გადა link-ი, მაგრამ მთავარი საიტი რჩება ქმედების წყაროდ.