Docker لـ WordPress: لماذا تغير الحاويات المعزولة كل شيء

يضع استضافة WordPress التقليدية مواقع متعددة على خادم واحد. إنهم يتشاركون PHP، ويتشاركون الوصول إلى نظام الملفات، وغالبًا ما يتشاركون خادم قاعدة بيانات. هذا جيد حتى لا يكون كذلك - وعندما لا يكون كذلك، فإنه يمثل مشكلة خطيرة.

يوفر PAGEnza كل موقع WordPress في حاوية Docker خاصة به. يشرح هذا المنشور ما يعنيه ذلك عمليًا ولماذا يهم وكالات إدارة مواقع العملاء المتعددة.

مشكلة الاستضافة المشتركة

في خطة استضافة مشتركة نموذجية أو حتى VPS أساسي مع تثبيتات WordPress متعددة:

تنازع الموارد: موقع واحد يحصل على زيادة في حركة المرور يبطئ كل موقع آخر على الخادم. مكون إضافي ضعيف التحسين على الموقع أ يقلل من أداء الموقع ب.

تسرب الأمان: إذا تم اختراق تثبيت WordPress واحد - عبر مكون إضافي به ثغرة، أو كلمة مرور ضعيفة، أو إصدار أساسي قديم - يمكن للمهاجم الذي يكتسب الوصول إلى نظام الملفات غالبًا قراءة الملفات من مواقع أخرى على نفس الخادم.

تعارض إصدارات PHP: يحتاج الموقع أ إلى PHP 7.4 لمكون إضافي قديم. يحتاج الموقع ب إلى PHP 8.2 لإصدار أحدث. في الاستضافة المشتركة، تختار واحدًا.

تعرض قاعدة البيانات: تعني خوادم قواعد البيانات المشتركة أن إذن مستخدم واحد تم تكوينه بشكل غير صحيح يمكن أن يكشف بيانات مواقع أخرى.

تحل حاويات Docker كل هذه المشكلات على مستوى البنية التحتية.

ما هي الحاوية فعليًا

حاوية Docker هي عملية خفيفة الوزن ومعزولة لها ما يلي:

• نظام الملفات (لا يمكن للحاوية رؤية الملفات خارج حدودها)
• مكدس الشبكة (عنوان IP الخاص بها، منافذها الخاصة)
• مساحة العمليات (لا يمكنها رؤية عمليات الحاويات الأخرى)
• حدود الموارد (حدود وحدة المعالجة المركزية والذاكرة)

إنها تشارك نواة المضيف مع الحاويات الأخرى، ولكن كل شيء فوق النواة معزول. إنها ليست آلة افتراضية كاملة - تبدأ في ثوانٍ، وليس دقائق، وتستخدم جزءًا صغيرًا من الموارد.

بالنسبة لـ WordPress، تقوم حاوية واحدة بتشغيل: Nginx، و PHP-FPM، وملفات WordPress. تعمل قاعدة البيانات في حاوية منفصلة، متصلة فقط بحاوية WordPress المحددة تلك.

كيف يوفر PAGEnza موقعًا

عند إنشاء موقع عميل جديد في PAGEnza، إليك ما يحدث في أقل من 45 ثانية:

1. يتم تشغيل حاوية Docker جديدة من صورة WordPress أساسية
2. يتم تكوين WordPress بقاعدة بيانات جديدة على مثيل MariaDB المشترك (معزول ببيانات اعتماد تلك الحاوية)
3. يتم تثبيت وتفعيل مكون PAGEnza الإضافي تلقائيًا
4. يتم تكوين مضيف افتراضي Nginx مع اسم النطاق الفرعي للعميل
5. يتم إصدار SSL عبر Let's Encrypt
6. يتم تسجيل الحاوية في الوكيل العكسي بقواعد التوجيه الصحيحة

يحصل العميل على عنوان URL مثل clientname.pagenza.com الذي يكون مباشرًا في غضون 45 ثانية من النقر على "إنشاء موقع". لا يوجد تكوين خادم يدوي، ولا SSH، ولا فترة انتظار DNS (لاسم النطاق الفرعي - انتشار DNS للنطاق المخصص منفصل).

عزل الحاوية عمليًا

حدود الذاكرة: كل حاوية لها حد ذاكرة قابل للتكوين. إذا تسبب مكون إضافي مارق في حدوث زيادة في الذاكرة على موقع عميل واحد، فلا يمكنه استهلاك الذاكرة المخصصة للحاويات الأخرى. قد يتباطأ الموقع أو يعرض خطأ 503 - ولكنه لن يؤثر على العملاء الآخرين.

عزل نظام الملفات: ملفات WordPress للعميل أ غير مرئية تمامًا لحاوية العميل ب. لا يوجد مسار لمكون إضافي تم اختراقه على موقع العميل أ إلى ملفات العميل ب.

عزل الشبكة: تتواصل الحاويات فقط من خلال جسور شبكة محددة. تقبل حاوية قاعدة البيانات للعميل أ اتصالات فقط من حاوية WordPress للعميل أ - وليس من أي حاوية أخرى على النظام.

PHP لكل حاوية: نظرًا لأن كل حاوية تشغل مثيل PHP-FPM الخاص بها، يمكنك تشغيل إصدارات PHP مختلفة لعملاء مختلفين. يعمل المكون الإضافي القديم للعميل أ الذي يحتاج إلى PHP 7.4 بشكل جيد جنبًا إلى جنب مع المكدس الحديث للعميل ب على PHP 8.2.

النطاقات المخصصة

الإعداد الافتراضي يمنح كل عميل اسم نطاق فرعي *.pagenza.com. للعملاء الذين يرغبون في نطاقهم الخاص، تكون العملية كالتالي:

1. يشير العميل إلى سجل A لنطاقه إلى عنوان IP لخادم PAGEnza
2. في لوحة تحكم PAGEnza، تدخل اسم النطاق المخصص
3. يتم تحديث تكوين الوكيل العكسي تلقائيًا
4. يتم إصدار SSL للنطاق المخصص عبر Let's Encrypt

يتم تحديث خيارات siteurl و home في WordPress لتتناسب معها. من منظور العميل، يعمل موقعه ببساطة على نطاقه - لا يوجد إعادة توجيه، ولا اسم نطاق فرعي مرئي للزوار.

ما يعنيه هذا للوكالات

الفائدة العملية للوكالات التي تدير مواقع عملاء متعددة:

سرعة الإعداد: يستغرق توفير موقع عميل جديد أقل من دقيقة. لا يوجد إعداد خادم، ولا cPanel، ولا تثبيت WordPress يدوي.

فصل العملاء: كل موقع عميل معزول حقًا. يؤثر العميل الذي يقوم بتثبيت مكون إضافي إشكالي على موقعه الخاص فقط.

قابلية التوسع: إضافة عميل جديد لا تتطلب توفير خادم جديد. تتكيف البنية التحتية للحاوية مع سعة المضيف، وإضافة المزيد من السعة هي مسألة إضافة المزيد من عقد المضيف.

التعافي من الكوارث: نظرًا لأن كل موقع يتم وضعه في حاوية، فإن النسخ الاحتياطي والاستعادة يعملان على مستوى الحاوية. استعادة موقع عميل واحد لا يؤثر على أي عملاء آخرين.

المقايضة هي أن استضافة الحاويات تكلف أكثر لكل موقع من الاستضافة المشتركة. ولكن بالنسبة للوكالات التي تكون فيها موثوقية الموقع وفصل العملاء غير قابلة للتفاوض، فإن الاقتصاديات تعمل - خاصة عند احتساب وفورات وقت التوفير.