تحرير

Share via

WordPress على Azure

Azure App Service
Azure Front Door
Azure Kubernetes Service (AKS)
Azure Web Application Firewall
Azure Private Link

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

تتناول هذه المقالة عمليات توزيع WordPress على Azure. يوفر إرشادات حول ما يجب مراعاته وتنفيذه للمساعدة في ضمان تثبيت آمن وقابل للتطوير وفعال من حيث التكلفة.

نصائح عامة حول الأمان والأداء في WordPress

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

سواء كنت تستخدم جهازا ظاهريا (VM) أو Azure App Service لبنية الاستضافة الخاصة بك، أو إذا كنت تستخدم بعض الحلول الأخرى، فإن هذه التلميحات قابلة للتطبيق.

استخدام Azure Web Application Firewall

يساعد Web Application Firewall على تأمين موقع الويب الخاص بك ضد الهجمات الشائعة المستندة إلى الويب. وهو بمثابة عامل تصفية بين موقع الويب الخاص بك والإنترنت. بهذه السعة، يراقب Web Application Firewall نسبة استخدام الشبكة الواردة ويحظر الطلبات الضارة التي يمكنها استغلال الثغرات الأمنية في التعليمات البرمجية لموقع الويب الخاص بك. يساعد جدار حماية تطبيق الويب على حماية موقعك على الويب من مجموعة من الهجمات، بما في ذلك حقن SQL والبرمجة النصية عبر المواقع (XSS) وتزوير الطلب عبر المواقع (CSRF).

يجب عليك استخدام Web Application Firewall على Azure Front Door للحصول على حماية مركزية لتطبيقات الويب الخاصة بك. Azure Front Door هي شبكة تسليم محتوى تساعد على تزويد المستخدمين في جميع أنحاء العالم بوصول سريع وموثوق وآمن إلى محتوى الويب الثابت والديناميكي لتطبيقاتك. يساعد نشر جدار حماية تطبيق الويب على Azure Front Door على الدفاع عن خدمات الويب الخاصة بك ضد عمليات الاستغلال والثغرات الأمنية الشائعة.

إزالة المكونات الإضافية والنسق غير المستخدمة

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

إلغاء تحميل المحتوى الثابت بعيدا عن معالج PHP

لتقليل الحمل على معالج PHP، يجب إلغاء تحميل المحتوى الثابت، مثل الصور ومقاطع الفيديو وملفات CSS. يساعد إلغاء تحميل المحتوى الثابت على تحسين أداء موقع الويب وتقليل تحميل الخادم. عندما يزور مستخدم موقع ويب، يعالج الخادم التعليمات البرمجية PHP وينشئ محتوى HTML ديناميكيا. تعد هذه العملية كثيفة الموارد. ومع ذلك، لا يتغير المحتوى الثابت بشكل متكرر، لذلك يمكنك تقديم محتوى ثابت مباشرة من نظام ملفات الخادم أو شبكة تسليم المحتوى. من خلال إلغاء تحميل هذه الأصول، يمكنك تقليل الحمل على وحدة المعالجة المركزية وذاكرة الوصول العشوائي الخاصة بالخادم. ينتج عن هذا التكوين أوقات تحميل أسرع للصفحة، وتحسين أداء موقع الويب، وتجربة مستخدم أفضل.

هناك أيضا فوائد أخرى لخدمة موارد ثابتة من خدمة شبكة تسليم المحتوى مثل Azure Front Door. على سبيل المثال، عند إلغاء تحميل المحتوى الثابت، يمكنك تقليل زمن الانتقال وزيادة سرعة موقع الويب عن طريق وضع الخوادم بالقرب من المواقع الجغرافية للمستخدمين.

ملاحظة

للمساعدة في تأمين أصل باستخدام Azure Front Door باستخدام نقطة نهاية خاصة، تحتاج إلى استخدام Premium SKU ل Azure Front Door. لمزيد من المعلومات، راجع تأمين أصلك باستخدام Private Link.

إبطال ذاكرة التخزين المؤقت لشبكة تسليم المحتوى

بالنسبة لعمليات تثبيت WordPress الكبيرة التي تستخدم شبكة تسليم محتوى، مثل Azure Front Door أو Azure Content Delivery Network، تحتاج إلى تنفيذ منطق إبطال ذاكرة التخزين المؤقت. كلما حدث حدث جديد، تحتاج إلى إبطال ذاكرة التخزين المؤقت في شبكة تسليم المحتوى للصفحة المتأثرة. تتضمن أمثلة الأحداث نشر مقالة جديدة وتحديث صفحة موجودة وإضافة تعليق. يحتاج منطق الإبطال إلى تحديد موقع جميع عناوين URL التي يؤثر عليها التغيير. على وجه التحديد، يحتاج المنطق إلى البحث عن الصفحات التي تم إنشاؤها ديناميكيا وإبطالها، مثل الفئات والأرشيفات، في ذاكرة التخزين المؤقت لشبكة تسليم المحتوى. مع بعض النسق المثبتة والمكونات الإضافية، يمكن أن يؤثر حتى تغيير طفيف على كل صفحة.

إحدى الطرق السهلة لتنفيذ منطق الاكتشاف هي استخدام مكون إضافي يتيح التشغيل اليدوي لإبطال ذاكرة التخزين المؤقت لجميع عناوين URL. ولكن يمكن أن يؤدي إبطال جميع عناوين URL في وقت واحد إلى ارتفاع نسبة استخدام الشبكة في موقع WordPress. للحصول على مثال لمنطق إبطال ذاكرة التخزين المؤقت لشبكة تسليم المحتوى، راجع ذاكرة التخزين المؤقت Flush Azure ونشر تنفيذ الربط على GitHub.

تمكين المصادقة الثنائية

تزيد المصادقة الثنائية من أمان التثبيت وتساعد على حماية حسابات المسؤولين من الوصول غير المصرح به والهجمات. للاستفادة من المصادقة الثنائية، يمكنك استخدام مكون إضافي مثل المكون الإضافي لمصادقة miniOrange. من بين ميزات أخرى، يوفر لك هذا المكون الإضافي طريقة لتكوين Microsoft Authenticator كطريقة مصادقة ثنائية للمستخدمين الذين يسجلون الدخول إلى موقع WordPress كمسؤولين.

تعطيل الوصول إلى XML-RPC

XML-RPC هو بروتوكول بعيد يوفر طريقة لتطبيقات الجهات الخارجية للتفاعل مع خادم موقع الويب الخاص بك. ومع ذلك، فإن هذا البروتوكول هو أيضا هدف شائع للمتسللين، الذين يستخدمونه لإطلاق هجمات القوة الغاشمة أو استغلال الثغرات الأمنية في نظام إدارة المحتوى الخاص بك. إذا كنت تستخدم Azure Front Door، يمكنك تعطيل XML-RPC عن طريق إعداد قاعدة رفض لعناوين URL بالتنسيق /xmlrpc.php.

تقييد الوصول إلى لوحة الإدارة

بشكل افتراضي، يمكن لأي شخص لديه بيانات اعتماد حسابك وعنوان URL الصحيح الوصول إلى لوحة إدارة WordPress، والتي تحتوي على التنسيق /wp-login.php أو /wp-admin. ونتيجة لذلك، يمكن للمتسللين والجهات الفاعلة الضارة الأخرى محاولة تخمين بيانات الاعتماد الخاصة بك، أو تنفيذ جلسة اختطاف، أو شن هجمات القوة الغاشمة، أو استغلال الثغرات الأمنية في WordPress للوصول.

يمكن أن يساعد Web Application Firewall في منع بعض الهجمات، ولكن يفضل العديد من المسؤولين تقييد الوصول إلى لوحة إدارة WordPress على مستوى الشبكة.

على سبيل المثال، يمكنك حظر الوصول إلى عناوين URL الخاصة في Azure Front Door. يمكنك بعد ذلك استخدام Azure Application Gateway لتوفير وصول داخلي من شبكة خاصة تستخدم مخططا محوريا. تدعم المثيلات الداخلية لبوابة التطبيق قواعد جدار حماية تطبيق الويب وقواعد Azure Front Door. تساعد هذه القواعد في حماية تثبيت WordPress من الهجمات الداخلية. إذا كان بإمكانك تحمل مخاطر هجوم داخلي، يمكنك استخدام مثيل داخلي من Azure Load Balancer بدلا من Application Gateway. يعمل Load Balancer في الطبقة الرابعة من نموذج Open Systems Interconnection (OSI).

رسم تخطيطي للبنية يوضح الوصول العام المحظور إلى لوحة إدارة WordPress. توفر الشبكة الظاهرية الخاصة في تخطيط الشبكة المحورية وصولا داخليا.

تنزيل Visio file لهذه البنية.

تتطلب بعض مكونات WordPress الإضافية عناوين URL بالتنسيق /wp-admin/admin-ajax.php ليتم الوصول إليها بشكل عام وإزالتها من قاعدة الرفض هذه.

تخزين البيانات السرية في Azure Key Vault

للمساعدة في ضمان أمان عمليات توزيع WordPress على Azure، نوصي بتخزين الأسرار، مثل كلمات مرور قاعدة البيانات وشهادات TLS أو SSL، في Key Vault. تساعد هذه الخدمة المستندة إلى السحابة على توفير تخزين وإدارة آمنة لمفاتيح التشفير والشهادات والأسرار.

يساعد Key Vault تطبيقاتك وخدماتك المعتمدة على الوصول إلى الأسرار بأمان. لا تحتاج إلى تخزينها في نص عادي داخل صورة حاوية WordPress أو في التعليمات البرمجية للتطبيق.

ضبط الأداء

لتحسين أداء WordPress، يجب ضبط الإعدادات المختلفة واستخدام المكونات الإضافية. يمكن أن تكون المكونات الإضافية التالية مفيدة لتصحيح أخطاء تثبيتات WordPress:

  • يوفر Query Monitor تصنيفا تفصيليا للوقت المستغرق في كل استعلام SQL والإجراءات الأخرى. تتضمن الأمثلة أخطاء PHP، والسنانير والإجراءات، وكتل محرر الحظر، والبرامج النصية وأوراق الأنماط المدرجة في قائمة الانتظار، واستدعاءات واجهة برمجة تطبيقات HTTP.
  • يوفر Laps تصنيفا تفصيليا لكيفية قضاء الوقت في تحميل صفحة WordPress.

استضافة تحديات WordPress

مع بنية تطبيق WordPress، هناك العديد من تحديات الاستضافة، بما في ذلك:

  • ⁧⁩قابلية التوسع⁧⁩. يجب أن تكون بنية الاستضافة قادرة على التوسع خلال فترات ذروة نسبة استخدام الشبكة.
  • تخزين ReadWriteMany (RWX). بشكل افتراضي، يخزن WordPress جميع الأصول الثابتة والمكونات الإضافية ورمز مصدر النسق /wp-content/ في الدليل. أثناء التوسيع، يجب أن تكون جميع العقد قادرة على القراءة من هذا الدليل والكتابة إليه.
  • فئة تخزين عمليات الإدخال/الإخراج في الثانية (IOPS). يتكون WordPress من أكثر من 1000 ملف .php صغير يشير إليه معالج PHP ويحمله ويعمل أثناء الطلبات الواردة. مع بعض البروتوكولات، يمكن أن يؤدي تحميل العديد من الملفات الصغيرة إلى زيادة الحمل. ثم يكون الأداء الإجمالي أبطأ من تحميل ملف واحد بنفس الحجم الإجمالي. ونتيجة لذلك، يحتاج حل التخزين إلى دعم عمليات الإدخال والإخراج في الثانية (IOPS) العالية.
  • إبطال ذاكرة التخزين المؤقت. عندما يكون هناك نشاط جديد في التطبيق، مثل عند نشر مقالة جديدة، تحتاج إلى إبطال ذاكرة التخزين المؤقت عبر جميع العقد.
  • وقت إنشاء ذاكرة التخزين المؤقت. بالنسبة للمستخدم الأول لعقدة معينة، يمكن أن يكون وقت الاستجابة بطيئا حتى يتم إنشاء ذاكرة التخزين المؤقت.

خيارات استضافة WordPress على Azure

يمكن تشغيل WordPress على App Service وAzure Kubernetes Service (AKS) وأجهزة Azure الظاهرية. حجم التثبيت هو عامل مهم في المضيف الذي تحدده. بالنسبة للتثبيتات الصغيرة إلى المتوسطة، تعد App Service خيارا فعالا من حيث التكلفة. ومع ذلك، بالنسبة للتثبيتات الأكبر، يجب أن تفكر في استضافة AKS أو VM.

WordPress على App Service

توفر Microsoft حلا مدارا بالكامل لتشغيل WordPress على App Service على أجهزة Linux الظاهرية. للحصول على معلومات مفصلة، راجع إنشاء موقع WordPress. هذا الحل:

  • تم تصميمه لمساعدتك على نشر تثبيت WordPress بسرعة وسهولة.
  • مثالي لعمليات تثبيت WordPress صغيرة إلى متوسطة الحجم.
  • يوفر قابلية التوسع والموثوقية والأمان للنظام الأساسي Azure دون الحاجة إلى تكوين أو إدارة معقدة.
  • يقوم بإجراء تحديثات ونسخ احتياطية ومراقبة تلقائية للمساعدة في ضمان توفر موقعك دائما.

لمزيد من المعلومات، راجع WordPress على App Service.

أحمال العمل كثيفة التخزين

يمكن أن تكون عمليات تثبيت WordPress الكبيرة كثيفة التخزين. في هذه السيناريوهات، يجب عليك استخدام حل تخزين مع فئة IOPS عالية وا زمن انتقال منخفض. نوصي ب Azure NetApp Files. يمكن أن تدعم Azure NetApp Files عمليات توزيع WordPress كثيفة التخزين. كما يوفر ميزات إضافية مثل حماية البيانات والنسخ الاحتياطي والاستعادة والنسخ المتماثل عبر المناطق والإصلاح بعد كارثة.

لنشر حاوية WordPress، يجب عليك استخدام AKS. باستخدام Azure NetApp Files، قم بتنفيذ التخزين عبر برنامج تشغيل Kubernetes Container Storage Interface (CSI). توفر Azure NetApp Files وضعا ReadWriteMany بحيث يمكن لجميع العقد القراءة والكتابة إلى نفس التخزين. لمزيد من المعلومات، راجع بنية AKS WordPress.

لتثبيت WordPress كبير يعمل على الأجهزة الظاهرية، يجب تحميل Azure NetApp Files عبر بروتوكول نظام ملفات الشبكة (NFS). لمزيد من المعلومات، راجع WordPress على الأجهزة الظاهرية.

حاوية WordPress غير قابلة للتغيير

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

يمكنك نشر إصدار حاوية غير قابل للتغيير من WordPress على أنظمة أساسية مختلفة، بما في ذلك Azure Container Apps وAKS وApp Service مع صورة حاوية مخصصة. يمكنك استضافة صورة الحاوية في Azure Container Registry.

المساهمون

هذه المقالة تحتفظ بها Microsoft. تمت كتابتها في الأصل من قِبل المساهمين التاليين.

الكاتب الرئيسي:

مساهمون آخرون:

  • أدريان كالينسكو | مهندس أول للحلول السحابية

لمشاهدة ملفات تعريف LinkedIn غير العامة، سجل الدخول إلى LinkedIn.

الخطوات التالية

وثائق المنتج:

وحدات التدريب: