مشاركة عبر


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 نسبة استخدام الشبكة الواردة ويحظر الطلبات الضارة التي يمكن أن تستغل الثغرات الأمنية في التعليمات البرمجية لموقع الويب الخاص بك. يساعد جدار حماية تطبيق الويب على حماية موقعك على الويب من مجموعة من الهجمات، بما في ذلك حقن 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.

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

تزيد المصادقة الثنائية من أمان التثبيت وتساعد على حماية حسابات المسؤولين من الوصول غير المصرح به والهجمات. للاستفادة من المصادقة الثنائية، يمكنك استخدام مكون إضافي مثل المكون الإضافي لمصادقة 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 لهذه البنية.

تتطلب بعض مكونات 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. يوفر ملخصا مرئيا يسهل فحصه، فإنه يتتبع تلقائيا أحداثا مثل تنفيذ PHP والعمليات الأساسية وأحمال المكونات الإضافية وأحمال النسق وحلقات النشر الرئيسية والأشرطة الجانبية واستعلامات قاعدة البيانات وطلبات الشبكة. يوضح هذا التصنيف التفصيلي كيفية قضاء الوقت في تحميل صفحة WordPress.

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

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

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

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

يمكن تشغيل WordPress على App Service وAzure Kubernetes Service (AKS) وAzure Virtual Machines. حجم التثبيت هو عامل مهم في المضيف الذي تحدده. بالنسبة للتثبيتات الصغيرة إلى المتوسطة، تعد 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.

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

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

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