تطبيق ويب متكرر في المنطقة للأساس متوفر بشكل كبير

تستند بنية الأساس هذه إلى بنية تطبيق الويب الأساسي وتوسعها لتوفير إرشادات مفصلة لتصميم تطبيق ويب آمن ومكرر للمنطقة ومتاح بشكل كبير على Azure. تعرض البنية نقطة نهاية عامة عبر بوابة تطبيق Azure مع جدار حماية تطبيق الويب. يقوم بتوجيه الطلبات إلى Azure App Service من خلال Private Link. يستخدم تطبيق App Service تكامل الشبكة الظاهرية والرابط الخاص للاتصال بأمان بخدمات Azure PaaS مثل Azure Key Vault وقاعدة بيانات Azure SQL.

بناء الأنظمة

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

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

المكونات

العديد من مكونات هذه البنية هي نفس بنية تطبيق الويب الأساسية. تسلط القائمة التالية الضوء على التغييرات التي تم إجراؤها على البنية الأساسية فقط.

• بوابة التطبيق هي موازن تحميل الطبقة 7 (HTTP/S) ومدير حركة مرور الويب. ويستخدم التوجيه المستند إلى مسار URL لتوزيع نسبة استخدام الشبكة الواردة عبر مناطق التوفر وإيقاف تحميل التشفير لتحسين أداء التطبيق.
• جدار حماية تطبيق الويب (WAF) هي خدمة سحابية أصلية تحمي تطبيقات الويب من الاستغلال الشائع مثل حقن SQL والبرمجة النصية عبر المواقع. يوفر WAF رؤية لحركة المرور من وإلى تطبيق الويب الخاص بك، مما يتيح لك مراقبة التطبيق الخاص بك وتأمينه.
• Azure Key Vault هي خدمة تخزن البيانات السرية ومفاتيح التشفير والشهادات وتديرها بأمان. وهو مركزية إدارة المعلومات الحساسة.
• شبكة Azure الظاهرية هي خدمة تمكنك من إنشاء شبكات ظاهرية خاصة معزولة وآمنة في Azure. بالنسبة لتطبيق ويب على App Service، تحتاج إلى شبكة فرعية للشبكة الظاهرية لاستخدام نقاط النهاية الخاصة للاتصال الآمن للشبكة بين الموارد.
• يتيح Private Link للعملاء الوصول إلى خدمات النظام الأساسي Azure كخدمة (PaaS) مباشرة من الشبكات الظاهرية الخاصة دون استخدام عنوان IP العام.
• Azure DNS هي خدمة استضافة لمجالات DNS التي توفر تحليل الاسم باستخدام البنية الأساسية ل Microsoft Azure. توفر مناطق DNS الخاصة طريقة لتعيين اسم المجال المؤهل بالكامل (FQDN) للخدمة إلى عنوان IP لنقطة نهاية خاصة.

الشبكات

أمان الشبكة هو جوهر البنية الأساسية لخدمات التطبيقات (راجع الشكل 2). من مستوى عال، تضمن بنية الشبكة ما يلي:

1. نقطة دخول آمنة واحدة لحركة مرور العميل
2. تمت تصفية حركة مرور الشبكة
3. البيانات المتنقلة مشفرة من طرف إلى طرف باستخدام TLS
4. يتم تصغير تسرب البيانات عن طريق الاحتفاظ بحركة المرور في Azure من خلال استخدام Private Link
5. يتم تجميع موارد الشبكة منطقيا وعزلها عن بعضها البعض من خلال تجزئة الشبكة

تدفقات الشبكة

الشكل 2: بنية الشبكة لتطبيق Azure App Service الأساسي

فيما يلي أوصاف للتدفق الوارد لحركة مرور الإنترنت إلى مثيل App Service والتدفق من App Service إلى خدمات Azure.

التدفق الوارد

1. يصدر المستخدم طلبا إلى IP العام لبوابة التطبيق.
2. يتم تقييم قواعد WAF. تؤثر قواعد WAF بشكل إيجابي على موثوقية النظام من خلال الحماية من الهجمات المختلفة، مثل البرمجة النصية عبر المواقع (XSS) وحقن SQL. تقوم بوابة تطبيق Azure بإرجاع خطأ إلى الطالب إذا تم انتهاك قاعدة WAF وتوقفت المعالجة. إذا لم يتم انتهاك أي قواعد WAF، تقوم بوابة التطبيق بتوجيه الطلب إلى تجمع الواجهة الخلفية، والذي في هذه الحالة هو المجال الافتراضي لخدمة التطبيقات.
3. ترتبط منطقة privatelink.azurewebsites.net DNS الخاصة بالشبكة الظاهرية. تحتوي منطقة DNS على سجل A يقوم بتعيين المجال الافتراضي ل App Service إلى عنوان IP الخاص لنقطة النهاية الخاصة لخدمة التطبيقات. تسمح منطقة DNS الخاصة المرتبطة هذه ل Azure DNS بحل المجال الافتراضي إلى عنوان IP لنقطة النهاية الخاصة.
4. يتم توجيه الطلب إلى مثيل App Service من خلال نقطة النهاية الخاصة.

تدفق خدمات App Service إلى Azure PaaS

1. تقدم App Service طلبا إلى اسم DNS لخدمة Azure المطلوبة. قد يكون الطلب إلى Azure Key Vault للحصول على سر أو تخزين Azure للحصول على ملف مضغوط للنشر أو قاعدة بيانات Azure SQL أو أي خدمة Azure أخرى تدعم Private Link. توجه ميزة تكامل الشبكة الظاهرية لخدمة التطبيقات الطلب من خلال الشبكة الظاهرية.
2. مثل الخطوة 3 في التدفق الوارد، تحتوي منطقة DNS الخاصة المرتبطة على سجل A يقوم بتعيين مجال خدمة Azure إلى عنوان IP الخاص لنقطة النهاية الخاصة. مرة أخرى، تسمح منطقة DNS الخاصة المرتبطة هذه ل Azure DNS بحل المجال إلى عنوان IP لنقطة النهاية الخاصة للخدمة.
3. يتم توجيه الطلب إلى الخدمة من خلال نقطة النهاية الخاصة.

الدخول إلى App Services

بوابة التطبيق هي مورد إقليمي يلبي متطلبات بنية الأساس هذه. بوابة التطبيق هي موازن تحميل للطبقة 7 قابل للتطوير والإقليمي يدعم ميزات مثل جدار حماية تطبيق الويب وإيقاف تحميل TLS. ضع في اعتبارك النقاط التالية عند تنفيذ Application Gateway للدخول إلى Azure App Services.

• انشر Application Gateway وقم بتكوين نهج WAF باستخدام مجموعة قواعد تديرها Microsoft. استخدم وضع الوقاية للتخفيف من هجمات الويب، التي قد تتسبب في عدم توفر خدمة أصل (خدمة التطبيقات في البنية).
• تنفيذ تشفير TLS من طرف إلى طرف.
• استخدم نقاط النهاية الخاصة لتنفيذ الوصول الخاص الوارد إلى App Service.
• ضع في اعتبارك تنفيذ التحجيم التلقائي لبوابة التطبيق للتكيف بسهولة مع تدفقات حركة المرور الديناميكية.
• ضع في اعتبارك استخدام الحد الأدنى لعدد مثيلات المقياس الذي لا يقل عن ثلاثة، واستخدم دائما جميع مناطق التوفر التي تدعمها منطقتك. بينما يتم نشر Application Gateway بطريقة متوفرة بشكل كبير، حتى بالنسبة لمثيل مقياس واحد، قد يستغرق إنشاء مثيل جديد عند الفشل ما يصل إلى سبع دقائق. يساعد نشر مثيلات متعددة عبر مناطق التوفر على ضمان تشغيل مثيل أثناء إنشاء مثيل جديد عند الفشل.
• تعطيل الوصول إلى الشبكة العامة على App Service لضمان عزل الشبكة. في Bicep، يتم إنجاز ذلك عن طريق تعيين publicNetworkAccess: 'Disabled' ضمن properties/siteConfig.

التدفق من خدمات التطبيقات إلى خدمات Azure

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

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

في هذه البنية، تحتوي قاعدة بيانات Azure SQL وAzure Storage وKey Vault على نقاط نهاية عامة معطلة. تستخدم جدران حماية خدمة Azure فقط للسماح بنسبة استخدام الشبكة من خدمات Azure الأخرى المعتمدة. يجب تكوين خدمات Azure الأخرى بنقاط نهاية خاصة، مثل Azure Cosmos DB وAzure Redis Cache. في هذه البنية، لا يستخدم Azure Monitor نقطة نهاية خاصة، ولكنه قد يستخدمها.

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

ضع في اعتبارك النقاط التالية عند تنفيذ تكامل الشبكة الظاهرية ونقاط النهاية الخاصة.

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

تجزئة الشبكة الظاهرية وأمانها

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

ضع في اعتبارك النقاط التالية عند تنفيذ تجزئة الشبكة الظاهرية والأمان.

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

مثال على مخطط الشبكة الفرعية الظاهرية يمكن أن يكون:

مرجع Azure-Samples\app-service-baseline-implementation

الاعتبارات

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

موثوقيه

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

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

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

Application Gateway

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

خدمات التطبيق

• نشر ما لا يقل عن ثلاثة مثيلات من خدمات التطبيقات مع دعم منطقة التوفر.
• تنفيذ نقاط نهاية التحقق من الصحة في تطبيقاتك وتكوين ميزة التحقق من صحة خدمة التطبيقات لإعادة توجيه الطلبات بعيدا عن المثيلات غير الصحية. لمزيد من المعلومات حول فحص App Service Health، راجع مراقبة مثيلات App Service باستخدام التحقق من الصحة. لمزيد من المعلومات حول تنفيذ نقاط نهاية التحقق من الصحة في تطبيقات ASP.NET، راجع عمليات التحقق من الصحة في ASP.NET Core.
• سعة التزويد الزائد لتكون قادرا على معالجة حالات فشل المنطقة.

قاعدة بيانات SQL

• انشر Azure SQL DB General Purpose أو Premium أو Business Critical مع تمكين التكرار في المنطقة. تدعم المستويات General Purpose وPremium و Business Critical تكرار المنطقة في Azure SQL DB.
• تكوين النسخ الاحتياطية ل SQL DB لاستخدام التخزين المتكرر للمنطقة (ZRS) أو التخزين المتكرر للمنطقة الجغرافية (GZRS).

مساحة تخزين Blob

• ينسخ Azure Zone-Redundant Storage (ZRS) بياناتك بشكل متزامن عبر ثلاث مناطق توفر في المنطقة. إنشاء حسابات تخزين ZRS القياسية أو حسابات تخزين GZRS القياسية لضمان نسخ البيانات عبر مناطق التوفر.
• إنشاء حسابات تخزين منفصلة للتوزيع وأصول الويب والبيانات الأخرى بحيث يمكنك إدارة الحسابات وتكوينها بشكل منفصل.

كفاءة الأداء

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

تناقش الأقسام التالية قابلية التوسع للمكونات الرئيسية في هذه البنية.

Application Gateway

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

App Service

• استخدم الخطط القياسية أو الأعلى مع ثلاثة مثيلات عاملة أو أكثر للحصول على قابلية وصول عالية.
• قم بتمكين التحجيم التلقائي للتأكد من أنه يمكنك التوسع صعودا وهبوطا لتلبية الطلب.
• ضع في اعتبارك فتح تذكرة دعم لزيادة الحد الأقصى لعدد العاملين إلى ضعف عدد المثيلات إذا كانت App Service تستخدم باستمرار نصف عدد المثيلات القصوى. الحد الأقصى لعدد المثيلات الافتراضي يصل إلى 30 لخطة Premium App Service و10 لخطة قياسية.
• ضع في اعتبارك نشر طوابع متعددة للتطبيق عندما تبدأ App Service في الوصول إلى الحدود العليا.
• اختر خطة Azure App Service المناسبة التي تلبي متطلبات حمل العمل.
• أضف Azure CDN إلى Azure App Service لخدمة المحتوى الثابت.
• ضع في اعتبارك App Service Environment إذا كان الجيران المزعجون مصدر قلق.

SQL Server

يعد تحجيم موارد قاعدة البيانات موضوعا معقدا خارج نطاق هذه البنية. خذ بعين الاعتبار الموارد التالية عند تحجيم قاعدة البيانات الخاصة بك،

• تغيير حجم موارد قاعدة البيانات ديناميكيا بأقل وقت تعطل
• التوسع باستخدام Azure SQL Database
• استخدام النسخ المتماثلة للقراءة فقط لإلغاء تحميل أحمال عمل الاستعلام للقراءة فقط

إرشادات أخرى حول قابلية التوسع

• راجع حدود الاشتراك والحصص النسبية للتأكد من أن الخدمات تتدرج حسب الطلب.
• ضع في اعتبارك التخزين المؤقت للأنواع التالية من البيانات لزيادة الأداء وقابلية التوسع:
  • بيانات الحركة شبه الثابتة.
  • حالة جلسة العمل.
  • إخراج HTML. يمكن أن يكون هذا مفيدا في تطبيقات تعرض إخراج HTML المعقد.

الأمان

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

App Service

• تعطيل أساليب المصادقة المحلية لنشر موقع FTP وSCM
• إيقاف تشغيل تصحيح الأخطاء عن بعد.
• استخدم أحدث إصدار من TLS.
• تمكين Microsoft Defender for App Service.
• قم باستخدام أحدث إصدارات الأنظمة الأساسية المدعومة ولغات البرمجة والبروتوكولات وإطارات الأعمال.
• ضع في اعتبارك بيئة خدمة التطبيقات إذا كنت تحتاج إلى عزل أعلى أو وصول آمن إلى الشبكة.

التشفير

يحتاج تطبيق ويب الإنتاج إلى تشفير البيانات أثناء النقل باستخدام HTTPS. يعتمد بروتوكول HTTPS على بروتوكول أمان طبقة النقل (TLS) ويستخدم مفاتيح عامة وخاصة للتشفير. يجب تخزين شهادة (X.509) في Key Vault والسماح لبوابة التطبيق باسترداد المفتاح الخاص. بالنسبة للبيانات الثابتة، تقوم بعض الخدمات بتشفير البيانات تلقائيا، بينما تسمح لك خدمات أخرى بتخصيصها.

نقل البيانات

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

1. يرسل المستخدم طلب HTTPS إلى تطبيق الويب.
2. يصل طلب HTTPS إلى بوابة التطبيق.
3. تستخدم بوابة التطبيق شهادة (X.509) في Key Vault لإنشاء اتصال TLS آمن مع مستعرض الويب الخاص بالمستخدم. تقوم بوابة التطبيق بفك تشفير طلب HTTPS بحيث يمكن لجدار حماية تطبيق الويب فحصه.
4. تنشئ بوابة التطبيق اتصال TLS مع App Service لإعادة تشفير طلب المستخدم. توفر App Service الدعم الأصلي ل HTTPS، لذلك لا تحتاج إلى إضافة شهادة إلى App Service. ترسل بوابة التطبيق حركة المرور المشفرة إلى App Service. تقوم App Service بفك تشفير نسبة استخدام الشبكة، ويعالج تطبيق الويب الطلب.

ضع في اعتبارك التوصيات التالية عند تكوين تشفير البيانات أثناء النقل.

• إنشاء الشهادة أو تحميلها إلى Key Vault. يتطلب تشفير HTTPS شهادة (X.509). تحتاج إلى شهادة من مرجع مصدق موثوق به لمجالك المخصص.
• تخزين المفتاح الخاص إلى الشهادة في Key Vault.
• اتبع الإرشادات الواردة في منح الإذن للتطبيقات للوصول إلى مخزن مفاتيح Azure باستخدام Azure RBAC والهويات المدارة لموارد Azure لتوفير وصول بوابة التطبيق إلى المفتاح الخاص بالشهادة. لا تستخدم نهج الوصول إلى Key Vault لتوفير الوصول. تتيح لك نهج الوصول فقط منح أذونات واسعة النطاق وليس فقط لقيم محددة.
• تمكين التشفير من طرف إلى طرف. App Service هي تجمع الواجهة الخلفية لبوابة التطبيق. عند تكوين إعداد الواجهة الخلفية لتجمع الواجهة الخلفية، استخدم بروتوكول HTTPS عبر المنفذ الخلفي 443.

البيانات في الراحة

• تشفير البيانات الحساسة في قاعدة بيانات Azure SQL باستخدام تشفير البيانات الشفاف. تشفر البيانات الشفافة قاعدة البيانات بالكامل والنسخ الاحتياطية وملفات سجل المعاملات ولا تتطلب أي تغييرات على تطبيق الويب الخاص بك.
• تقليل زمن انتقال تشفير قاعدة البيانات. لتقليل زمن انتقال التشفير، ضع البيانات التي تحتاج إلى تأمينها في قاعدة البيانات الخاصة بها وتمكين التشفير لقاعدة البيانات هذه فقط.
• فهم دعم التشفير المضمن. يقوم Azure Storage تلقائيا بتشفير البيانات الثابتة باستخدام التشفير من جانب الخادم (AES 256 بت). يقوم Azure Monitor تلقائيا بتشفير البيانات الثابتة باستخدام المفاتيح التي تديرها Microsoft (MMKs).

إدارة الهوية والوصول

يقوم أساس App Service بتكوين المصادقة والتخويل لهويات المستخدم (المستخدمين) وهويات حمل العمل (موارد Azure) وينفذ مبدأ الامتياز الأقل.

هويات المستخدم

• استخدم آلية المصادقة المتكاملة لخدمة التطبيقات ("EasyAuth"). يبسط EasyAuth عملية دمج موفري الهوية في تطبيق الويب الخاص بك. وهو يعالج المصادقة خارج تطبيق الويب الخاص بك، لذلك لا يتعين عليك إجراء تغييرات كبيرة في التعليمات البرمجية.
• تكوين عنوان URL للرد للمجال المخصص. يجب إعادة توجيه تطبيق الويب إلى https://<application-gateway-endpoint>/.auth/login/<provider>/callback. استبدل <application-gateway-endpoint> بعنوان IP العام أو اسم المجال المخصص المقترن ببوابة التطبيق. استبدل <provider> بموفر المصادقة الذي تستخدمه، مثل "aad" لمعرف Microsoft Entra. يمكنك استخدام وثائق Azure Front لإعداد هذا التدفق باستخدام Application Gateway أو إعداد Application Gateway.

هويات حمل العمل.

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

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

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

يتبع النشر لتطبيق App Service الأساسي الإرشادات الواردة في CI/CD ل Azure Web Apps باستخدام Azure Pipelines. بالإضافة إلى هذه الإرشادات، تأخذ البنية الأساسية لخدمات التطبيقات في الاعتبار أن التطبيق وحساب تخزين النشر مؤمنان بالشبكة. ترفض البنية الوصول العام إلى App Service. وهذا يعني أنه لا يمكنك النشر من خارج الشبكة الظاهرية. يوضح لك الأساس كيفية نشر التعليمات البرمجية للتطبيق داخل الشبكة الظاهرية باستخدام عوامل التوزيع المستضافة ذاتيا. يركز إرشادات النشر التالية على نشر التعليمات البرمجية للتطبيق وعدم نشر تغييرات البنية الأساسية أو قاعدة البيانات.

الشكل 3: نشر تطبيقات Azure App Service

تدفق النشر

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

2. يلتقط عامل التوزيع المستضاف ذاتيا طلب الوظيفة الجديد من خلال الاستقصاء. يقوم بتنزيل الوظيفة وبنية البيانات الاصطناعية.

3. يقوم عامل النشر المستضاف ذاتيا بتحميل الملف المضغوط إلى حساب التخزين من خلال نقطة النهاية الخاصة لحساب التخزين.

4. يستمر المسار، ويلتقط عامل مدار مهمة لاحقة. يقوم العامل المدار بإجراء استدعاء CLI لتحديث appSetting WEBSITE_RUN_FROM_PACKAGE إلى اسم ملف النشر المضغوط الجديد لفتحة التقسيم المرحلي.

   az webapp config appsettings set -g MyResourceGroupName -n MyUniqueApp --slot staging --settings WEBSITE_RUN_FROM_PACKAGE=UriToNewZip
   

5. تسحب Azure App Service ملف النشر المضغوط الجديد من التخزين عبر نقطة النهاية الخاصة بحساب التخزين. تتم إعادة تشغيل المثيل المرحلي مع الحزمة الجديدة لأنه تم تعيين WEBSITE_RUN_FROM_PACKAGE إلى اسم ملف مختلف.

6. يستأنف المسار ويشغل أي اختبارات دخان أو ينتظر الموافقة. إذا تم تمرير الاختبارات أو الموافقة عليها، يقوم المسار بتبديل فتحات التقسيم المرحلي والإنتاج.

توزيع الإرشادات

يسلط التالي الضوء على إرشادات التوزيع الرئيسية لبنية الأساس.

• استخدم التشغيل من الحزمة لتجنب تعارضات التوزيع. عند تشغيل تطبيقك مباشرة من حزمة في Azure App Service، لا يتم نسخ الملفات الموجودة في الحزمة إلى دليل wwwroot. بدلاً من ذلك، يتم تحميل حزمة ZIP نفسها مباشرة كدليل wwwroot للقراءة فقط. هذا يلغي تعارضات تأمين الملفات بين النشر ووقت التشغيل ويضمن تشغيل التطبيقات المنشورة بالكامل فقط في أي وقت
• قم بتضمين أرقام الإصدارات في ملفات الحزمة المضغوطة المنشورة. يؤدي تحديث WEBSITE_RUN_FROM_PACKAGE appSetting إلى حزمة التوزيع باسم ملف مختلف إلى التقاط App Services للإصدار الجديد تلقائيا وإعادة تشغيل الخدمة.
• استخدم فتحات النشر لنشر التعليمات البرمجية المرنة.
• فكر في استخدام مزيج من العوامل المدارة والمستضافة ذاتيا.
  • استخدم العوامل المستضافة ذاتيا لتحميل ملف الحزمة المضغوط إلى حساب التخزين عبر نقطة النهاية الخاصة. يبدأ العامل الاتصال بالبنية الأساسية لبرنامج ربط العمليات التجارية من خلال الاستقصاء بحيث لا يكون مطلوبا فتح الشبكة لاستدعاء وارد.
  • استخدم العوامل المدارة للوظائف الأخرى في البنية الأساسية لبرنامج ربط العمليات التجارية.
• أتمتة عمليات نشر البنية الأساسية باستخدام البنية الأساسية كتعليق برمجي (IaC).
• تحقق باستمرار من صحة حمل العمل لاختبار أداء ومرونة الحل بأكمله باستخدام خدمات مثل Azure Load Testing وAzure Chaos Studio.

التكوين

تتطلب التطبيقات كل من قيم التكوين والأسرار. استخدم الإرشادات التالية لإدارة التكوين والأسرار.

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

مراقبة‬

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

لمراقبة تطبيق الويب الخاص بك، تحتاج إلى جمع وتحليل المقاييس والسجلات من التعليمات البرمجية للتطبيق والبنية الأساسية (وقت التشغيل) والنظام الأساسي (موارد Azure). لمزيد من المعلومات، راجع سجل نشاط Azure وسجلات موارد Azure وسجلات التطبيق.

مراقبة النظام الأساسي

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

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

  مورد Azure	أوصاف المقاييس والسجلات
  Application Gateway	مقاييس Application Gateway ووصف السجلات
  جدار حماية تطبيق الويب	مقاييس جدار حماية تطبيق الويب ووصف السجلات
  App Service	أوصاف سجلات ومقاييس App Service
  قاعدة بيانات Azure SQL	مقاييس وسجلات قاعدة بيانات Azure SQL
  CosmosDB	مقاييس Azure Cosmos DB ووصف السجلات
  Key Vault	مقاييس Key Vault ووصف السجلات
  مخزن البيانات الثنائية الكبيرة	مقاييس Azure Blob Storage ووصف السجلات
  Application Insights	مقاييس Application Insights ووصف السجلات
  عنوان IP العام	مقاييس عنوان IP العام ووصف السجلات

• فهم تكلفة جمع المقاييس والسجلات. بشكل عام، كلما زادت المقاييس والسجلات التي تجمعها، زادت تكاليفها. لمزيد من المعلومات، راجع حسابات وخيارات تكلفة Log Analytics والأسعار لمساحة عمل Log Analytics.

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

  • نظرة عامة على تنبيهات Azure Monitor
  • تنبيهات بوابة التطبيق
  • تنبيهات App Service
  • تنبيهات قاعدة بيانات Azure SQL
  • تنبيهات تخزين Blob
  • تنبيهات Key vault

Application Gateway

تراقب بوابة التطبيق صحة الموارد في تجمع الواجهة الخلفية الخاصة بها. استخدم سجلات الوصول إلى بوابة التطبيق لجمع معلومات مثل الطابع الزمني ورمز استجابة HTTP ومسار URL. لمزيد من المعلومات، راجع التحقيق الصحي الافتراضي لبوابة التطبيق وسجلات صحة الخلفية والتشخيص.

App Service

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

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

قاعدة البيانات

• نتائج تحليلات قاعدة بيانات المستخدم. بالنسبة لقواعد بيانات Azure SQL، يجب تكوين SQL Insights في Azure Monitor. تستخدم نتائج تحليلات قاعدة البيانات طرق عرض الإدارة الديناميكية لعرض البيانات التي تحتاجها لمراقبة الصحة وتشخيص المشكلات وضبط الأداء. لمزيد من المعلومات، راجع مراقبة قاعدة بيانات Azure SQL باستخدام Azure Monitor.
• إذا كانت بنيتك تتضمن Cosmos DB، فلن تحتاج إلى تمكين أو تكوين أي شيء لاستخدام رؤى Cosmos DB.

الإدارة

تستفيد تطبيقات الويب من نهج Azure من خلال فرض قرارات البنية والأمان. يمكن أن يجعل نهج Azure (1) من المستحيل نشر (رفض) أو (2) من السهل الكشف عن (تدقيق) انحراف التكوين عن الحالة المطلوبة المفضلة لديك. يساعدك هذا في التقاط عمليات نشر البنية الأساسية كتعليق برمجي (IaC) أو تغييرات مدخل Azure التي تنحرف عن البنية المتفق عليها. يجب وضع جميع الموارد في البنية الخاصة بك ضمن Azure Policy governance. استخدم النهج المضمنة أو مبادرات النهج حيثما أمكن لفرض طبولوجيا الشبكة الأساسية وميزات الخدمة والأمان وقرارات المراقبة، على سبيل المثال:

• يجب أن تعطل App Service الوصول إلى الشبكة العامة
• يجب أن تستخدم خدمة التطبيقات تكامل الشبكة الظاهرية
• يجب أن تستخدم App Service Azure Private Link للاتصال بخدمات PaaS
• يجب أن يكون لدى App Service أساليب مصادقة محلية معطلة لنشر موقع FTP وSCM
• يجب أن يكون تصحيح الأخطاء عن بعد في App Service متوقفا عن التشغيل
• إعادة تسمية النهج إلى "يجب أن تستخدم تطبيقات App Service أحدث إصدار من TLS"
• يجب تمكين Azure Defender لـ App Service
• يجب تمكين جدار حماية تطبيق ويب (WAF) لـ Application Gateway

راجع المزيد من النهج المضمنة للخدمات الرئيسية مثل Application Gateway ومكونات الشبكات وخدمة التطبيقات وKey Vault والمراقبة. من الممكن إنشاء نهج مخصصة أو استخدام نهج المجتمع (مثل من مناطق هبوط Azure) إذا كانت النهج المضمنة لا تغطي احتياجاتك بالكامل. تفضل النهج المضمنة عند توفرها.

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

الموارد ذات الصلة

• دليل الارتباط الخاص في Virtual WAN
• تكبير حجم تطبيق في «Azure App Service»
• ترحيل App Service إلى دعم منطقة التوفر
• توسيع نطاق Application Gateway v2 وWAF v2