ملٹی ٹیننسی آئیزولیشن (Multi-Tenancy Isolation)
Ultimate Multisite: Multi-Tenancy 1.2.0 اب خودمختار تنانٹس کے لیے فی سابساাইট ڈیٹا بیس اور فائل سسٹم آئیزولیشن کو سپورٹ کرتا ہے۔ یہ نیٹ ورک لیول پر پروویژننگ، بلنگ اور انتظامیہ برقرار رکھتے ہوئے تنانٹ ڈیٹا کو الگ رکھتا ہے۔
آئیزولیشن کی حکمت عملی (Isolation strategy)
ان کسٹمرز کے لیے خودمختار آئیزولیشن کا استعمال کریں جنہیں زیادہ مضبوط ڈیٹا علیحدگی، مخصوص فائل سسٹم اسٹوریج، یا ایک الگ ہوسٹ حد درکار ہوتی ہے۔
ہر خودمختار تنانٹ کے پاس یہ ہونا چاہیے:
- ایک مخصوص تنانٹ ڈیٹا بیس یا ہوسٹ کے لیے منظور شدہ ڈیٹا بیس پریفکس کی حکمت عملی۔
- ایک مخصوص تنانٹ فائل سسٹم روٹ (root).
- ایک تنانٹ رجسٹرڈ اندراج جو سائٹ کو اس کے ڈیٹا بیس، روٹ پاتھ، ہوسٹ نیم اور آئیزولیشن ماڈل سے جوڑتا ہے۔
- تنانٹ کو لائیو سمجھنے سے پہلے مائگریشن کی تصدیق کا نتیجہ۔
ڈیٹا بیس ہوسٹ باائنڈنگ (Database host binding)
نسخه 1.2.0 اب خودمختار انسٹال کے لیے ڈیفالٹ "اسی مشین پر ہوسٹ باائنڈنگ" کے رویے کو تبدیل کرتا ہے۔ localhost جیسے اسی مشین کے ویلیوز کو نارملائز کیا جاتا ہے تاکہ Bedrock، FrankenPHP اور کنٹینرائزڈ WordPress انسٹالز MySQL جو اصل میں دیکھ رہا ہے اس ہوسٹ سٹرنگ کے خلاف اجازتیں دے سکیں اور تصدیق کر سکیں۔
جب آپ ایک خود مختار تنانٹ کی ترتیب دے رہے ہوں تو:
- ڈیٹا بیس ہوسٹ کو تنانٹ رن ٹائم (runtime) کی ضرورت کے مطابق ویلیو پر سیٹ کریں۔
- مقامی کنکشنز کی توقع ہونے پر لوکل سکیٹ انسٹالز کے لیے
localhostکا استعمال کریں۔ - صرف تب
127.0.0.1یا سروس ہوسٹ نیم کا استعمال کریں جب ڈیٹا بیس سرور اس ہوسٹ کو مراعات (privileges) دے۔ - ہوسٹ باائنڈنگ تبدیل کرنے کے بعد مائگریشن کی تصدیق چلائیں۔
اگر تصدیق رپورٹ اجازتوں میں ناکامی دکھاتی ہے، تو تنانٹ ڈی بی صارف کی اجازتوں کا موازنہ ترتیب دی گئی ہوسٹ باائنڈنگ سے کریں۔ user@localhost کو دی گئی اجازتیں [email protected] یا user@% سے مختلف ہوتی ہیں۔
فائل سسٹم روٹ (Filesystem root)
تننت رُٹ (tenant root) کو ری سٹارٹ اور ڈپلائیمنٹ کے دوران مستحکم رکھنا چاہیے۔ عارضی ماؤنٹ پاتھ سے گریز کریں۔ Bedrock طرز کی انسٹالیشنز کے لیے، اس بات کی تصدیق کریں کہ تنین رُٹ وہ WordPress ویب رُٹ پر پوائنٹ کرتا ہے جس کی توقع تنین بوٹ سکرپٹ (tenant bootstrap) کرتی ہے، نہ صرف پروجیکٹ رُٹ پر۔
پروویژن ترتیب (Provisioning order)
نئے سوورین تنینز کے لیے، اس ترتیب کا استعمال کریں:
- تنین رجسٹری اندراج (tenant registry entry) بنائیں۔
- تنین ڈیٹا بیس اور ڈیٹا بیس صارف (database user) بنائیں۔
- تنین اسکیمہ کو بوٹ سٹرپ (Bootstrap the tenant schema) کریں۔
- تنین صارفین (tenant users) فراہم کریں۔
- تنین فائل سسٹم پاتھز (filesystem paths) کو ترتیب دیں۔
- مائگریشن کی تصدیق چلائیں۔
- تصدیق پاس ہونے کے بعد روٹنگ یا DNS تبدیل کریں۔
یہ ترتیب اس بات کو یقینی بناتی ہے کہ ڈیٹا بیس رائٹر، صارفین اور فائل سسٹم تیار ہونے سے پہلے جزوی طور پر الگ کیے گئے تنینز کو ٹریفک نہ ملے گا۔
سوورین کسٹمر مینجمنٹ فلو (Sovereign customer management flows)
Ultimate Multisite v2.13.0 میں جب سوورین موڈ فعال ہوتا ہے تو کسٹمر مینجمنٹ کے اقدامات مرکزی سائٹ پر رکھے جاتے ہیں۔ ایک تنین اب بھی ایک الگ شدہ WordPress انسٹال کے طور پر چل سکتا ہے، لیکن نیٹ ورک بلنگ، ممبرشپ یا شیئرڈ اکاؤنٹ ڈیٹا پر منحصر کسٹمر سے متعلق اقدامات کو تنین رن ٹائم کے اندر مکمل کرنے کی کوشش کرنے کے بجائے اسے مرکزی سائٹ پر واپس بھیجنا چاہیے جہاں وہ ہو سکتے ہیں۔
مرکزی سائٹ کا فلو مندرجہ ذیل چیزوں پر لاگو ہوتا ہے:
- چیک آؤٹ اور پلان میں تبدیلیاں۔
- اکاؤنٹ کا جائزہ اور کسٹمر پروفائل کے اقدامات۔
- بلنگ ایڈریس کی اپ ڈیٹس اور ادائیگی کے انتظام کے اسکرینز۔
- انوائس اور ادائیگی کے ہسٹری ویوز۔
- سائٹ مینجمنٹ کے اقدامات جیسے سائٹس شامل کرنا یا کسی سائٹ کو حذف کرنا۔
- ٹیمپلیٹ سوئچنگ۔
- ڈومین میپنگ اور پرائمری ڈومین میں تبدیلیاں۔
جب کوئی کسٹمر کسی سوورین ٹینٹ سے ان میں سے کوئی عمل شروع کرتا ہے، تو Ultimate Multisite اس کے مطابق مین سائٹ کا URL بناتا ہے اور جب یہ محفوظ ہو تو سورس ٹینٹ کو ریٹرن ٹارگٹ کے طور پر برقرار رکھتا ہے۔ یہ صارفین کو نیٹ ورک ریکارڈز کے خلاف مینیجڈ عمل مکمل کرنے کی اجازت دیتا ہے، پھر بغیر بلنگ یا ممبرشپ اسٹیٹ کو سوورین ڈیٹا بیس میں دوبارہ دہرائے مین سائٹ کے سیاق و سباق میں واپس جانے کی سہولت فراہم کرتا ہے۔
آپریٹرز کے لیے عملی اصول یہ ہے: سوورین نیٹ ورکس کے لیے بلنگ، اکاؤنٹ، چیک آؤٹ، انوائس، ٹیمپلیٹ اور ڈومین مینجمنٹ کے صفحات کو مین سائٹ پر دستیاب رکھیں۔ ٹ یننٹ ڈیش بورڈ ان صفحات سے لنک کر سکتے ہیں، لیکن عمل کا سورس آف ٹروتھ (حقیقت کا ذریعہ) اب بھی مین سائٹ رہتا ہے۔