تطبيق ويب أساسي

Azure App Service
Azure Monitor
Azure SQL Database

توفر هذه المقالة بنية أساسية مخصصة للتعرف على تشغيل تطبيقات الويب على Azure App Service في منطقة واحدة.

هام

لا يقصد بهذه البنية أن تستخدم لتطبيقات الإنتاج. تهدف إلى أن تكون بنية تمهيدية يمكنك استخدامها لأغراض التعلم وإثبات المفهوم (POC). عند تصميم تطبيق Azure App Service للإنتاج، راجع تطبيق الويب المتكرر للمنطقة الأساسية المتوفرة بشكل كبير.

هام

شعار GitHub يتم دعم الإرشادات من خلال تطبيق مثال يعرض تطبيق App Service الأساسي هذا على Azure. يمكن استخدام هذا التنفيذ كأساس ل POC الخاص بك لتجربة العمل مع Azure App Service.

بناء الأنظمة

رسم تخطيطي يوضح بنية App Service الأساسية.

الشكل 1: بنية خدمة تطبيقات Azure الأساسية

قم بتنزيل ملف Visio لهذه البنية.

‏‏سير العمل‬

  1. يصدر المستخدم طلب HTTPS إلى المجال الافتراضي لخدمة التطبيقات على azurewebsites.net. يشير هذا المجال تلقائيا إلى عنوان IP العام المضمن في App Service. يتم تأسيس اتصال TLS من العميل مباشرة إلى خدمة التطبيق. تتم إدارة الشهادة بالكامل بواسطة Azure.
  2. يضمن Easy Auth، إحدى ميزات Azure App Service، مصادقة المستخدم الذي يصل إلى الموقع باستخدام معرف Microsoft Entra.
  3. تعالج التعليمات البرمجية للتطبيق الذي تم نشره في App Service الطلب. على سبيل المثال، قد تتصل هذه التعليمة البرمجية بمثيل قاعدة بيانات Azure SQL، باستخدام سلسلة الاتصال تم تكوينه في App Service الذي تم تكوينه كإعداد تطبيق.
  4. يتم تسجيل المعلومات حول الطلب الأصلي إلى App Service واستدعاء قاعدة بيانات Azure SQL في Application Insights.

المكونات

  • معرف Microsoft Entra هو خدمة إدارة الهوية والوصول المستندة إلى السحابة. يوفر وحدة تحكم هوية واحدة لإدارة الأذونات والأدوار للمستخدمين الذين يصلون إلى تطبيق الويب الخاص بك. وهو يتكامل مع App Service ويبسط المصادقة والتخويل لتطبيقات الويب.
  • App Service هي نظام أساسي مدار بالكامل لإنشاء تطبيقات الويب ونشرها وتوسيع نطاقها.
  • Azure Monitor هي خدمة مراقبة تجمع بيانات تتبع الاستخدام وتحللها وتعمل عليها عبر عملية التوزيع.
  • قاعدة بيانات Azure SQL هي خدمة قاعدة بيانات ارتباطية مدارة للبيانات الارتباطية.

التوصيات والاعتبارات

ترتبط المكونات المدرجة في هذه البنية بأدلة خدمة Azure Well-Architected. دليل الخدمة تفاصيل التوصيات والاعتبارات لخدمات محددة. يوسع هذا القسم هذا التوجيه من خلال تمييز توصيات واعتبارات Azure Well-Architected Framework الرئيسية التي تنطبق على هذه البنية. لمزيد من المعلومات، يرجى مراجعةMicrosoft Azure Well-Architected Framework.

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

الموثوقيه

تضمن الموثوقية أن التطبيق الخاص بك يمكن أن يفي بالالتزامات التي تتعهد بها لعملائك. لمزيد من المعلومات، راجع قائمة اختيار مراجعة التصميم للموثوقية.

نظرا لأن هذه البنية غير مصممة لتوزيع الإنتاج، يوضح التالي بعض ميزات الموثوقية الهامة التي تم حذفها في هذه البنية:

  • تم تكوين خطة خدمة التطبيقات للطبقة Standard ، والتي لا تحتوي على دعم منطقة توفر Azure. تصبح App Service غير متوفرة في حالة وجود أي مشكلة في المثيل أو الحامل أو مركز البيانات الذي يستضيف المثيل.
  • تم تكوين قاعدة بيانات Azure SQL للطبقة Basic ، والتي لا تدعم تكرار المنطقة. وهذا يعني أنه لا يتم نسخ البيانات عبر مناطق توفر Azure، مما يخاطر بفقدان البيانات الملتزم بها في حالة انقطاع الخدمة.
  • قد تؤدي عمليات التوزيع إلى هذه البنية إلى وقت تعطل مع عمليات نشر التطبيق، حيث تتطلب معظم تقنيات التوزيع إعادة تشغيل جميع المثيلات قيد التشغيل. قد يواجه المستخدمون 503 أخطاء أثناء هذه العملية. تتم معالجة هذا في بنية الأساس من خلال فتحات التوزيع. تصميم التطبيق الدقيق وإدارة المخطط ومعالجة تكوين التطبيق ضرورية لدعم نشر الفتحة المتزامنة. استخدم POC هذا لتصميم نهج نشر الإنتاج المستند إلى الفتحة والتحقق من صحته.
  • لم يتم تمكين التحجيم التلقائي في هذه البنية الأساسية. لمنع مشكلات الموثوقية بسبب نقص موارد الحوسبة المتاحة، ستحتاج إلى الإفراط في التزويد للتشغيل دائما مع حساب كاف للتعامل مع الحد الأقصى للسعة المتزامنة.

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

إذا كان حمل العمل هذا سيتطلب في النهاية بنية متعددة المناطق نشطة-نشطة أو نشطة-سلبية، فشاهد تطبيق ويب متعدد المناطق متوفر بشكل كبير للحصول على إرشادات حول نشر حمل العمل المستضاف على App Service عبر مناطق متعددة.

الأمان

ويوفر عامل الأمان ضمانات للحماية من الهجمات المتعمدة واستغلال البيانات والأنظمة القيمة الخاصة بك. لمزيد من المعلومات، راجع قائمة اختيار مراجعة التصميم للأمان.

نظرا لأن هذه البنية غير مصممة لتوزيع الإنتاج، يوضح التالي بعض ميزات الأمان الهامة التي تم حذفها في هذه البنية، بالإضافة إلى توصيات واعتبارات الموثوقية الأخرى:

  • لا تنفذ هذه البنية الأساسية خصوصية الشبكة. يمكن الوصول إلى مستويات البيانات والإدارة للموارد، مثل Azure App Service وAzure SQL Server، عبر الإنترنت العام. يؤدي حذف الشبكات الخاصة إلى زيادة سطح الهجوم للبنية الخاصة بك بشكل كبير. لمعرفة كيف يضمن تنفيذ الشبكات الخاصة ميزات الأمان التالية، راجع قسم الشبكات في تطبيق الويب المتكرر للمنطقة الأساسية المتوفرة بشكل كبير:

    • نقطة دخول آمنة واحدة لحركة مرور العميل
    • تتم تصفية حركة مرور الشبكة على مستوى الحزمة وعلى مستوى DDoS.
    • يتم تصغير النقل غير المصرح للبيانات عن طريق الاحتفاظ بحركة المرور في Azure باستخدام Private Link
    • يتم تجميع موارد الشبكة منطقيا وعزلها عن بعضها البعض من خلال تجزئة الشبكة.
  • لا تتضمن هذه البنية الأساسية توزيع Azure Web Application Firewall. تطبيق الويب غير محمي ضد عمليات الاستغلال والثغرات الأمنية الشائعة. راجع تنفيذ الأساس لمعرفة كيفية تنفيذ جدار حماية تطبيق الويب باستخدام Azure Application Gateway في بنية Azure App Services.

  • تخزن هذه البنية الأساسية أسرارا مثل سلسلة الاتصال Azure SQL Server في إعدادات التطبيق. بينما يتم تشفير إعدادات التطبيق، عند الانتقال إلى الإنتاج، ضع في اعتبارك تخزين الأسرار في Azure Key Vault لزيادة الحوكمة. الحل الأفضل هو استخدام الهوية المدارة للمصادقة وليس لديك أسرار مخزنة في سلسلة الاتصال.

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

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

  • لا تحتاج إلى تمكين Microsoft Defender for App Service في مرحلة إثبات المفهوم. عند الانتقال إلى الإنتاج، يجب تمكين Defender for App Service لإنشاء توصيات أمان يجب عليك تنفيذها لزيادة وضع الأمان والكشف عن تهديدات متعددة لخدمة التطبيقات الخاصة بك.

  • تتضمن Azure App Service نقطة نهاية SSL على مجال azurewebsites.net فرعي دون أي تكلفة إضافية. تتم إعادة توجيه طلبات HTTP إلى نقطة نهاية HTTPS بشكل افتراضي. بالنسبة إلى عمليات نشر الإنتاج، ستستخدم عادة مجالا مخصصا مقترنا ببوابة التطبيق أو إدارة واجهة برمجة التطبيقات أمام نشر App Service.

  • استخدم آلية المصادقة المتكاملة لخدمة التطبيقات ("EasyAuth"). يبسط EasyAuth عملية دمج موفري الهوية في تطبيق الويب الخاص بك. وهو يعالج المصادقة خارج تطبيق الويب الخاص بك، لذلك لا يتعين عليك إجراء تغييرات كبيرة في التعليمات البرمجية.

  • استخدم الهوية المدارة لهويات حمل العمل. الهوية المدارة تلغي حاجة المطورين إلى إدارة بيانات اعتماد المصادقة. تصادق البنية الأساسية على SQL Server عبر كلمة المرور في سلسلة الاتصال. ضع في اعتبارك استخدام الهوية المدارة للمصادقة على Azure SQL Server.

للحصول على بعض اعتبارات الأمان الأخرى، راجع تأمين تطبيق في Azure App Service.

التميز التشغيلي

يغطي التميز التشغيلي عمليات التشغيل التي تحافظ على تشغيل التطبيق في الإنتاج. لمزيد من المعلومات، راجع قائمة اختيار مراجعة التصميم للتميز التشغيلي.

توفر الأقسام التالية إرشادات حول تكوين تطبيق App Service ومراقبته ونشره.

تكوينات التطبيق

نظرا لأن البنية الأساسية غير مخصصة للإنتاج، فإنها تستخدم تكوين App Service لتخزين قيم التكوين والأسرار. تخزين الأسرار في تكوين App Service أمر جيد لمرحلة PoC. أنت لا تستخدم أسرارا حقيقية ولا تتطلب إدارة الأسرار التي تتطلبها أحمال عمل الإنتاج.

فيما يلي توصيات واعتبارات التكوين:

  • ابدأ باستخدام تكوين App Service لتخزين قيم التكوين سلسلة الاتصال في إثبات عمليات نشر المفهوم. يتم تشفير إعدادات التطبيق سلسلة الاتصال وفك تشفيرها قبل إدخالها في التطبيق عند بدء تشغيله.
  • عند الانتقال إلى مرحلة الإنتاج، قم بتخزين أسرارك في Azure Key Vault. يعمل استخدام Azure Key Vault على تحسين حوكمة الأسرار بطريقتين:
    • يتيح لك إضفاء الطابع الخارجي على تخزين البيانات السرية إلى Azure Key Vault مركزية تخزين البيانات السرية. لديك مكان واحد لإدارة الأسرار.
    • باستخدام Azure Key Vault، يمكنك تسجيل كل تفاعل مع الأسرار، بما في ذلك في كل مرة يتم فيها الوصول إلى سر.
  • عند الانتقال إلى الإنتاج، يمكنك الحفاظ على استخدامك لكل من Azure Key Vault وتكوين App Service باستخدام مراجع Key Vault.

التشخيص والمراقبة

أثناء مرحلة إثبات المفهوم، من المهم الحصول على فهم للسجلات والمقاييس المتاحة ليتم التقاطها. فيما يلي توصيات واعتبارات للمراقبة في مرحلة إثبات المفهوم:

  • تمكين تسجيل التشخيص لجميع مصادر سجل العناصر. يساعدك تكوين استخدام جميع إعدادات التشخيص على فهم السجلات والمقاييس التي يتم توفيرها لك خارج الصندوق وأي فجوات ستحتاج إلى إغلاقها باستخدام إطار عمل تسجيل في التعليمات البرمجية للتطبيق الخاص بك. عند الانتقال إلى الإنتاج، يجب إزالة مصادر السجل التي لا تضيف قيمة وتضيف ضوضاء وتكلفة إلى متلقي سجل حمل العمل الخاص بك.
  • تكوين التسجيل لاستخدام Azure Log Analytics. يوفر لك Azure Log Analytics نظاما أساسيا قابلا للتطوير لمركزية التسجيل الذي يسهل الاستعلام فيه.
  • استخدم Application Insights أو أداة أخرى لإدارة أداء التطبيقات (APM) لإصدار بيانات تتبع الاستخدام والسجلات لمراقبة أداء التطبيق.

التوزيع

يسرد التالي إرشادات حول نشر تطبيق App Service.

  • اتبع الإرشادات الواردة في CI/CD ل Azure Web Apps باستخدام Azure Pipelines لأتمتة نشر التطبيق الخاص بك. ابدأ في بناء منطق التوزيع الخاص بك في مرحلة PoC. يتيح لك تنفيذ CI/CD في وقت مبكر من عملية التطوير تكرار التطبيق الخاص بك بسرعة وأمان أثناء الانتقال نحو الإنتاج.
  • استخدم قوالب ARM لنشر موارد Azure وتبعياتها. من المهم بدء هذه العملية في مرحلة PoC. أثناء الانتقال نحو الإنتاج، تريد القدرة على نشر البنية الأساسية تلقائيا.
  • استخدم قوالب ARM مختلفة ودمجها مع خدمات Azure DevOps. يتيح لك هذا الإعداد إنشاء بيئات مختلفة. على سبيل المثال، يمكنك نسخ سيناريوهات تشبه الإنتاج أو بيئات اختبار التحميل فقط عند الحاجة وتوفير التكلفة.

لمزيد من المعلومات، راجع قسم DevOps في Azure Well-Architected Framework.

الحاويات

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

وحدة التحكم

أثناء مرحلة POC، كن مرتاحا مع مستوى تحكم Azure App Service كما هو مكشوف من خلال خدمة Kudu. تعرض هذه الخدمة واجهات برمجة تطبيقات التوزيع الشائعة، مثل عمليات نشر ZIP، وتعرض السجلات الأولية ومتغيرات البيئة.

إذا كنت تستخدم حاويات، فتأكد من فهم قدرة Kudu على فتح جلسة SSH إلى حاوية لدعم قدرات تصحيح الأخطاء المتقدمة.

كفاءة الأداء

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

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

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

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

نشر هذا السيناريو

يتم دعم الإرشادات من خلال تطبيق مثال يعرض تطبيق App Service الأساسي على Azure.

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

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

وحدات Microsoft Learn: