كيفية عزل مواقع عملاء WordPress بدون Multisite

العزل (Isolation) هو إحدى تلك الكلمات التي تبدو محسومة حتى يطرح أحد العملاء السؤال الصعب: إذا تم اختراق موقع آخر على هذا التثبيت أو تعرضت بياناته للتلف، هل سيتعطل موقعي أيضا؟ إذا كانت إجابتك تعتمد على قاعدة بيانات مشتركة، فإن الإجابة الصادقة هي “ربما”. يمشي هذا الدليل بك عبر سير عمل الإعداد من أجل isolate wordpress client sites بشكل حقيقي (بيانات منفصلة، شفرة برمجية منفصلة، ونطاق فشل منفصل) بينما لا تزال تدير تثبيت WordPress واحدا.

ماذا يعني “العزل” في الواقع

العزل ليس خاصية واحدة. إنه ثلاث خصائص، وتوفر Multisite واحدة منها تقريبا.

• عزل البيانات: لا يمكن قراءة صفوف ومستخدمين وخيارات tenant معين أو إتلافها من خلال سياق tenant آخر.
• عزل الشفرة البرمجية: يمكن لكل tenant تشغيل الـ themes والـ plugins الخاصة به بإصداراتها الخاصة، لذلك لا يمس التحديث أو الـ plugin المعيب في العميل أ (Client A) العميل ب (Client B) أبدا.
• عزل نطاق الفشل: عندما يتعطل tenant معين (خطأ فادح، جدول تالف، استعادة فاشلة)، يتوقف نطاق الضرر عند ذلك الـ tenant.

تشارك Multisite قاعدة بيانات واحدة ومجلد wp-content واحدا عبر كل موقع فرعي. يتم فصل المواقع الفرعية فقط بواسطة معرف المدونة (blog ID) وبادئة الجدول داخل قاعدة البيانات الفردية هذه. يمنحك ذلك شكلا ضعيفا من فصل البيانات ولا شيء آخر: كل موقع فرعي يشغل نفس الـ plugins والـ themes من نفس المجلد، ووجود جدول تالف واحد أو خطأ plugin فادح يقع داخل نفس نطاق الفشل مثل أي شخص آخر. البادئات تفصل الصفوف. إنها لا تفصل المخاطر. وبالتالي فإن wordpress client site isolation without multisite يتطلب نهجا مختلفا تماما.

عزل قاعدة البيانات: بادئة، MySQL مخصصة، أو SQLite

عزل قاعدة البيانات هو المحور الذي يحتوي على معظم الخيارات، لذا اختر بعناية لتحقيق wordpress tenant database isolation الفعال.

• MySQL مشتركة، بادئة فريدة لكل tenant (الـ plugin المجاني): يمنح GrabWP Tenancy كل tenant بادئة جدول فريدة في قاعدة البيانات المشتركة بالإضافة إلى مجلد تحميلات منفصل. هذا فصل حقيقي على مستوى الصفوف وهو أسرع طريقة لإنشاء العديد من مواقع العملاء، لكن الـ tenants لا يزالون يعيشون في قاعدة بيانات واحدة، لذا فهو عزل جزئي.
• قاعدة بيانات MySQL مخصصة لكل tenant (نسخة Pro): تمنح نسخة GrabWP Tenancy Pro كل tenant قاعدة بيانات MySQL الخاصة به. هذا عزل كامل للبيانات مع عدم وجود أي مخاطر متقاطعة بين الـ tenants في طبقة قاعدة البيانات: أي قفل، أو جدول منتفخ، أو فهرس تالف يبقى داخل قاعدة بيانات ذلك العميل الواحد.
• SQLite لكل tenant (نسخة Pro): بالنسبة للـ tenants الخفيفة أو القابلة للنقل، يمكن لنسخة Pro دعم الـ tenant بملف قاعدة بيانات SQLite الخاص به، مما يجعل الـ tenant مستقلا بذاته ويسهل نقله.

نظرا لأن نسخة Pro تدعم الترحيل عبر قواعد البيانات، فهذه ليست قرارات نهائية لا يمكن التراجع عنها. يمكنك بدء عميل على نموذج البادئة المشتركة ونقل ذلك الـ tenant إلى قاعدة بيانات MySQL أو SQLite مخصصة لاحقا دون إعادة بنائه. هذا يسهل عليك per-tenant wordpress isolation خطوة بخطوة.

عزل الشفرة البرمجية عبر مجلد wp-content لكل tenant

عزل البيانات هو نصف القصة فقط. إذا كان عميلان يتشاركان مجلد wp-content واحدا، فإنهما يتشاركان مجموعة واحدة من ملفات الـ plugin والـ theme، مما يعني أن تحديث plugin لعميل واحد أو theme غير متوافق يصبح مشكلة للجميع.

يقوم الـ plugin المجاني بعزل التحميلات لكل tenant. تذهب نسخة Pro إلى أبعد من ذلك مع فصل كامل لمجلد wp-content: حيث يتم عزل الـ themes والـ plugins والتحميلات لكل tenant، وكل منها تحت مجلد المحتوى الخاص به. هذا هو ما يتيح للعميل أ (Client A) تشغيل إصدار قديم ومثبت من منشئ الصفحات (page builder) بينما يشغل العميل ب (Client B) أحدث إصدار، بدون ملفات مشتركة وبدون تعارض في الإصدارات. يمكن لنسخة Pro أيضا وضع موقع بيانات الـ tenant خارج wp-content/uploads تماما، وهو أمر مفيد عندما تريد تخزين الـ tenant على وحدة تخزين منفصلة.

توجيه كل tenant بدون DNS

العزل لا قيمة له إذا لم يتمكن العملاء من الوصول إلى مواقعهم، ولا ينبغي عليك لمس إعدادات DNS لكل tenant جديد. يقوم GrabWP Tenancy بتوجيه الـ tenants بطريقتين:

• التوجيه القائم على المسار (مجلد فرعي): الوصول إلى tenant عبر yoursite.com/site/client-a دون أي تغييرات في DNS على الإطلاق. البادئة site قابلة للتهيئة من خلال الثابت GRABWP_TENANCY_PATH_PREFIX إذا كنت تريد مقطعا مختلفا.
• توجيه النطاق المخصص: توجيه النطاق الخاص بالعميل إلى الـ tenant عندما يكونون جاهزين لعنوان URL يحمل علامتهم التجارية.

التوجيه القائم على المسار هو القوة الخفية لسير عمل العزل: يمكنك توفير واختبار وتسليم موقع عميل معزول بالكامل قبل وجود أي DNS. هناك أيضا عزل للتخزين المؤقت (cache) مدمج، لذلك لا تتصادم الـ tenants في البنية التحتية المشتركة. يقوم الـ plugin بتعطيل ملفات drop-ins الخاصة بالتخزين المؤقت للصفحات لكل طلب ويضيف بادئة لمعرف الـ tenant إلى مفاتيح التخزين المؤقت للكائنات (object-cache)، مما يمنع تعارض التخزين المؤقت بين الـ tenants على خلفية Redis أو Memcached مشتركة.

عزل نطاق الفشل عبر النسخ الاحتياطي والاستعادة لكل tenant

نطاق الفشل هو المحور الذي ينساه الناس حتى تقع حادثة. العزل الحقيقي يعني أنه يمكنك عمل نسخة احتياطية واستعادة عميل واحد دون المساس بأي عميل آخر.

توفر نسخة Pro عملية نسخ احتياطي مكونة من 7 خطوات واستعادة من 8 خطوات لكل tenant مع تقدم عبر AJAX، لذا فإن استعادة العميل أ هي عملية مستقلة. يمكنك جدولة النسخ الاحتياطية التلقائية (كل ساعة، مرتين يوميا، يوميا، أسبوعيا، كل أسبوعين، أو شهريا) مع تجاوزات لكل tenant، وتفريغها إلى S3. هذا المزيج هو ما يحول “المعزول” من ادعاء معماري إلى حقيقة تشغيلية: يمكن التراجع عن tenant واحد إلى حالة الأمس بينما يستمر تشغيل كل tenant آخر دون أن يمسه شيء.

إعداد tenant معزول، خطوة بخطوة

إليك سير العمل العملي لموقع عميل معزول بشكل حقيقي:

1. تثبيت GrabWP Tenancy على تثبيت WordPress الفردي الخاص بك وتفعيله.
2. إنشاء الـ tenant للعميل. في الـ plugin المجاني، يوفر هذا بادئة جدول فريدة ومجلدا منفصلا للتحميلات تلقائيا.
3. ترقية الـ tenant إلى العزل الكامل باستخدام نسخة Pro: تعيين قاعدة بيانات MySQL أو SQLite مخصصة له ومجلد wp-content الخاص به بحيث يتم فصل كل من البيانات والشفرة البرمجية.
4. توجيه الـ tenant باستخدام التوجيه القائم على المسار (yoursite.com/site/client-a) حتى تتمكن من البناء والاختبار بدون DNS، ثم إرفاق النطاق المخصص للعميل عند التسليم.
5. تعيين جدول النسخ الاحتياطي لذلك الـ tenant، وإضافة هدف تفريغ S3، وتشغيل نسخة احتياطية يدوية واحدة واختبار الاستعادة للتأكد من أن نطاق الفشل معزول حقا.
6. الاستنساخ من tenant أساسي عندما تحتاج إلى نقطة بداية قابلة للتكرار: يقوم الاستنساخ بنسخ جداول قاعدة البيانات (DB) والتحميلات مع استبدال عنوان URL التلقائي (ويتخطى الروابط الرمزية symlinks)، لذلك يبدأ العميل الجديد من حزمة البرامج القياسية (standard stack) الخاصة بك.

النتيجة هي تثبيت واحد يجب تحديثه ومراقبته، مع وجود كل عميل في بياناته وشفرته البرمجية وحدود استعادته الخاصة، مما يتيح لك isolate wordpress sites without multisite بكفاءة.

متى يكون العزل أكثر أهمية

لا يحتاج كل مشروع إلى قواعد بيانات مخصصة. لكن العزل يتوقف عن كونه خيارا عندما:

• تستضيف عمل عميل تكون مسؤولا عنه تعاقديا، حيث لا يمكن السماح لحادثة تخص عميلا واحدا بالتأثير على عميل آخر.
• يشغل العملاء إصدارات plugin أو theme متعارضة لا يمكن أن تتعايش في مجلد wp-content مشترك.
• تحتاج إلى حدود فشل واستعادة نظيفة لكل عميل، بحيث تكون الاستعادة السيئة أو الجدول التالف مشكلة لعميل واحد، وليس لكل قائمة عملائك.
• تريد بنية عزل بيانات يمكنك وصفها بصدق للعملاء الذين يسألون أين تعيش بياناتهم.

لإلقاء نظرة أعمق على الحالات التي ينهار فيها النموذج المشترك، راجع متى لا يجب استخدام WordPress Multisite والمقارنة الكاملة في Multisite مقابل multi-tenancy.

ابدأ الآن

ابدأ مع GrabWP Tenancy plugin المجاني للحصول على بادئات جداول فريدة، وتحميلات منفصلة، وتوجيه مسار بدون DNS. عندما يحتاج العميل إلى عزل كامل (MySQL أو SQLite مخصصة، فصل كامل لمجلد wp-content، ونسخ احتياطي واستعادة لكل tenant)، قم بالترقية إلى GrabWP Tenancy Pro مقابل $9.99/month.

مقالات ذات صلة

• قاعدة بيانات MySQL مخصصة مقابل SQLite لكل tenant: اختيار طريقة عزل قاعدة بيانات الـ tenant في WordPress
• عزل حقيقي لعملاء الوكالات في WordPress، بدون Multisite
• توقف عن المعاناة مع تعارضات إضافات WordPress Multisite: امنح كل عميل حزمة إضافات خاصة به