إشعار
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
Azure Container Apps هي خدمة استضافة حاويات بدون خادم مدارة بالكامل لنشر الخدمات المصغرة والتطبيقات الحاوية.
عند استخدام Azure، تعد الموثوقية مسؤولية مشتركة. توفر Microsoft مجموعة من الإمكانات لدعم المرونة والاسترداد. أنت مسؤول عن فهم كيفية عمل هذه الإمكانات في جميع الخدمات التي تستخدمها، وتحديد الإمكانات التي تحتاجها لتحقيق أهداف عملك وأهداف وقت التشغيل.
تصف هذه المقالة كيفية جعل تطبيقات الحاويات مقاومة لمختلف الانقطاعات والمشاكل المحتملة، بما في ذلك الأعطال المؤقتة، وانقطاعات مناطق التوفر، وانقطاعات المناطق، وصيانة الخدمة. كما يصف كيفية استخدام النسخ الاحتياطية للاسترداد من أنواع أخرى من المشاكل ويبرز معلومات أساسية حول اتفاقية مستوى الخدمة (SLA) لتطبيقات الحاويات.
توصيات نشر الإنتاج
لتتعلم كيفية نشر تطبيقات الحاويات لدعم متطلبات موثوقية الحل وكيف تؤثر الموثوقية على جوانب أخرى من بنيتك، راجع أفضل ممارسات البنية لتطبيقات الحاويات في إطار عمل Azure Well-Architected.
نظرة عامة على بنية الموثوقية
عند استخدام تطبيقات الحاويات، تقوم بنشر بيئة تعمل كوحدة نشر أساسية وتحدد حدودا آمنة حول مجموعة من تطبيقات الحاويات. البيئة هي المكان الذي تقوم فيه بتكوين الإعدادات الأساسية، بما في ذلك دعم منطقة التوفر وتكوين الشبكة. النوعان من البيئات هما ملفات تعريف عبء العمل، وبيئات الاستهلاك فقط. لمزيد من المعلومات، راجع هياكل الحوسبة والفوترة في تطبيقات الحاويات.
يمكنك نشر عدة تطبيقات في بيئة واحدة. كل تطبيق يشغل حاوية أو أكثر. يمكن للبيئة أيضا تشغيل وظيفة أو أكثر، والتي تمثل المهام غير التفاعلية. لمزيد من المعلومات، انظر الحاويات في تطبيقات الحاوياتوالوظائف في تطبيقات الحاويات.
كل تطبيق يحتوي على نسخة أو أكثر من النسخ التي تمثل النسخ الجارية للتطبيق. يمكنك التحكم في كيفية تكبير تطبيقك، بما في ذلك الحد الأدنى والأعلى لعدد النسخ المقلدة وكيف يضيف التطبيق ويزيل النسخ بشكل ديناميكي. يضمن جدولة المنصة التوزيع الأمثل بين المضيفين الفعليين مع تلبية متطلبات الحد الأدنى لعدد النسخ الخاصة بك. لمزيد من المعلومات، راجع تعيين قواعد التوسع في تطبيقات الحاويات.
تدعم تطبيقات الحاويات موثوقية تطبيقاتك باستخدام قدرات مختلفة:
المراقبة الصحية التلقائية: تقوم وحدة التحكم المدمجة بموازنة التحميل تلقائيا لحركة المرور عبر النسخ السليمة. إذا فشل النسخة في فحوصات الصحة أو أصبحت البنية التحتية الأساسية غير متاحة لفترة طويلة، تقوم الخدمة تلقائيا بإعادة تشغيل الحاويات الفاشلة أو إنشاء نسخ بديلة. كما يعيد توزيع الحركة بعيدا عن النسخ غير الصحية ويدير محاولات الشبكة في العنقود. لا تتطلب عملية الاسترداد التلقائي هذه أي تدخل من العميل وتحافظ على عدد النسخ المتماثلة المحددة. لمزيد من المعلومات، راجع فحوصات السلامة.
مرونة التطبيقات عبر DAPR: توفر تطبيقات الحاويات تكاملا محكما مع Dapr، وهو إطار عمل يدعم خدمات مصغرة من مستوى الإنتاج وتطبيقات الحاويات. يتضمن DAPR ميزات تساعد في تحسين المرونة، بما في ذلك التعامل مع الأعطال في خدمات أخرى. لمزيد من المعلومات، راجع الخدمات المصغرة مع تطبيقات الحاويات.
مرونة البنية التحتية لمكونات النظام: تشمل هذه المرونة مستوى التحكم، ووحدات التحكم في الدخول، ووقت تشغيل الحاويات. في المناطق التي لديها مناطق توافر، توفر تطبيقات الحاويات تكرارا للمناطق. لمزيد من المعلومات، راجع المرونة ضد فشل مناطق التوفر.
المرونة في مواجهة الأعطال العابرة
الأخطاء العابرة هي حالات فشل قصيرة متقطعة في المكونات. تحدث بشكل متكرر في بيئة موزعة مثل السحابة، وهي جزء طبيعي من العمليات. الأخطاء العابرة تصحح نفسها بعد فترة زمنية قصيرة. من المهم أن تتمكن تطبيقاتك من معالجة الأخطاء العابرة، عادة عن طريق إعادة محاولة الطلبات المتأثرة.
يجب أن تتبع جميع التطبيقات المستضافة على السحابة إرشادات معالجة الأخطاء العابرة ل Azure عند الاتصال بأي واجهات برمجة تطبيقات وقواعد بيانات ومكونات أخرى مستضافة على السحابة. لمزيد من المعلومات، راجع توصيات للتعامل مع الأخطاء العابرة.
تتعامل تطبيقات الحاوية تلقائيا مع العديد من الأخطاء العابرة من خلال آليات إعادة المحاولة على مستوى النظام الأساسي ومراقبة السلامة. لضمان أن تطبيقاتك مقاومة للأعطال المؤقتة، اتخذ الإجراءات التالية:
قم بتكوين مجسات صحية تتيح للمنصة اكتشاف والاستجابة لحالات الفشل الخاصة بالتطبيق. حدد عتبات الفشل وقيم المهلة المناسبة بناء على خصائص بدء تشغيل تطبيقك. على سبيل المثال، لتجنب إعادة تشغيل الحاويات المبكرة أثناء المشاكل المؤقتة، استخدم عتبة فشل 3 مع فترة 10 ثوان لمجسات الحيوية. لمزيد من المعلومات، راجع فحوصات السلامة.
استخدم سياسات مرونة اكتشاف الخدمة (المعاينة) لمنع فشل طلبات الخدمة واكتشافها واستعادتها بشكل استباقي. على سبيل المثال، عند استخدام نهج المرونة، يمكن إعادة محاولة كل طلب وارد إلى التطبيق تلقائيا إذا كان هناك خطأ عابر يمنع التطبيق من الاستجابة. لمزيد من المعلومات، راجع مرونة اكتشاف الخدمة (معاينة).
نفذ منطق إعادة المحاولة في تطبيقاتك لاستدعاءات الخدمات الخارجية، واتصالات قواعد البيانات، وطلبات واجهة برمجة التطبيقات (API).
إذا كان تطبيقك يستخدم Dapr للتكامل مع الخدمات السحابية، فاستخدم مرونة مكون Dapr (معاينة) لتكوين عمليات إعادة المحاولة والمهلات وقواطع الدائرة.
بالنسبة للتبعيات الأخرى، يجب أن يعالج تطبيقك الأخطاء العابرة. استخدم استراتيجيات التراجع الأسي وأنماط قاطع الدائرة عند استدعاء الخدمات الخارجية لمنع حالات الفشل المتتالية أثناء انقطاع الخدمة النهائية. ميزات اكتشاف الخدمة وتوازن التحميل المدمجة في تطبيقات الحاويات توجه تلقائيا حركة المرور بعيدا عن العينات الفاشلة، لكن سياسات إعادة المحاولة على مستوى التطبيق تضمن التعامل السليم مع المشاكل المؤقتة قبل أن تؤدي فحوصات الصحة على مستوى المنصة إلى إعادة تشغيل الحاويات.
صمم الوظائف لتكون مقاومة للأعطال المؤقتة، بما في ذلك الأعطال أثناء تنفيذ المهام أو في تبعياتها. صمم وظائفك لاستئناف العمل إذا تمت إعادة تشغيلها ، أو صمم من أجل القدرة بحيث يمكن إعادة تشغيلها بأمان.
المرونة في مواجهة حالات فشل منطقة التوفر
مناطق التوفر هي مجموعات منفصلة فعليا من مراكز البيانات داخل منطقة Azure. عند فشل منطقة واحدة، يمكن أن تفشل الخدمات إلى إحدى المناطق المتبقية.
عند إنشاء بيئة تطبيقات الحاويات، يمكنك تمكين تكرار المنطقة لتوزيع البنية التحتية الأساسية عبر عدة مناطق توفر في منطقة Azure المختارة. تقوم تطبيقات الحاوية تلقائيا بجدولة النسخ المتماثلة لتطبيقاتك عبر المناطق. يحدث هذا التوزيع بشكل شفاف، مما يعني أنك لست بحاجة لتحديد موقع المنطقة للنسخ الفردية.
يعزز تكرار المنطقة مرونة تطبيقك في مواجهة حالات الفشل على مستوى المنطقة من خلال ضمان نشر النسخ المتماثلة لتطبيق الحاوية عبر مناطق متعددة.
يوضح الرسم البياني التالي تطبيق حاويات احتياطي في المنطقة مع ثلاث نسخ مكررة. كل نسخة تعمل في منطقة توفر منفصلة.
المتطلبات
تحقق من دعم المنطقة. يتوفر تكرار المنطقة في جميع المناطق التي تدعم تطبيقات الحاويات ومناطق التوفر.
لمعرفة المناطق التي تدعم مناطق التوفر، راجع مناطق Azure التي تدعم منطقة التوفر.
لمعرفة المناطق التي تدعم تطبيقات الحاويات، انظر توفر المنتج حسب المنطقة.
استخدم ملفات تعريف عبء العمل. التكرار في المناطق متاح لجميع خطط تطبيقات الحاويات، بما في ذلك ملفات تحميل الاستهلاك وملفات عبء العمل المخصصة.
تمكين تكرار المنطقة أثناء إنشاء البيئة. لا يمكن تغيير هذا الإعداد بعد إنشاء البيئة.
نشر بيئة تطبيقات الحاويات في شبكة افتراضية. يجب أن تكون الشبكة الظاهرية في منطقة تدعم مناطق التوفر. تأكد من أن الشبكة الظاهرية تحتوي على شبكة فرعية ذات حجم مناسب. تحتاج بيئات الاستهلاك فقط إلى شبكة فرعية بنطاق
/23توجيه Inter-Domain بدون فئة (CIDR) أو أكبر، بينما تتطلب/27بيئات ملفات عبء العمل نطاق CIDR أو أكبر.اضبط الحد الأدنى لعدد النسخ على الأقل إلى اثنين لضمان التوزيع عبر مناطق توفر متعددة. فكر في تحديد حد أدنى لعدد النسخ إذا كانت هناك أي من الشروط التالية تنطبق:
يحتاج ذروة الحمل المتوقع إلى أكثر من نسختين متماثلتين.
يجب أن تكون صامدا أمام عدة انقطاعات في المنطقة في نفس الوقت.
تريد تقليل الوقت الذي تنتظره لإنشاء نسخ جديدة في مناطق أخرى أثناء انقطاع المنطقة.
التكلفة
لن تتحمل رسوما إضافية تتجاوز أسعار تطبيقات الحاويات القياسية عند تفعيل التكرار في المنطقة. أنت تدفع نفس الأسعار لموارد الحوسبة والطلبات وثواني vCore سواء تم تمكين تكرار المنطقة أم لا. لمزيد من المعلومات، راجع تسعير تطبيقات الحاوياتوفوترة تطبيقات الحاويات.
تكوين دعم منطقة التوفر
قم بإنشاء بيئة تطبيقات حاويات متكررة في المنطقة. للحصول على تعليمات النشر التي تغطي بوابة Azure، وAzure CLI، وAzure PowerShell، انظر إنشاء تطبيق حاوية احتياطي للمنطقة.
انتقل إلى انتشار متكرر في المنطقة. لا يمكنك تمكين تكرار المنطقة في بيئة تطبيقات الحاويات الحالية. لترقية البيئات الحالية التي ليست زائدة عن الحاجة للمناطق، أنشئ بيئة جديدة مع تفعيل تكرار المنطقة في منطقة مدعومة. ثم أعد نشر تطبيقات الحاويات الخاصة بك.
تعطيل تكرار المنطقة. لا يمكن تعطيل تكرار المنطقة بعد تفعيله أثناء إنشاء البيئة. إذا كنت تحتاج إلى نشر متكرر غير منطقي، فيجب عليك إنشاء بيئة جديدة دون تمكين خيار تكرار المنطقة أو النشر إلى منطقة لا تدعم مناطق التوفر.
تحقق من تكرار المنطقة. يمكنك استخدام بوابة Azure، وAzure CLI، وAzure PowerShell للتحقق من حالة تكرار المنطقة في بيئتك.
تخطيط القدرات وإدارتها
إذا أصبحت منطقة توفر غير متاحة، تستخدم منصة تطبيقات الحاويات قواعد المقياس الخاصة بك لتحديد متى يجب استبدال أي نسخ مفقودة في تلك المنطقة. من المهم ضبط قواعد الميزان بشكل صحيح حتى يتمكن المنسق من اتخاذ قرارات الجدولة المناسبة.
لتكوين قواعد المقياس بشكل صحيح، اتبع المبادئ التالية:
قم بتعيين حد أدنى لعدد النسخ المتماثلة التي يمكن أن يتحملها تطبيقك. قد يستغرق استبدال النسخ المفقودة فترة قصيرة لأن المنصة يجب أن تكتشف أن النسخ القديمة قد اختفت. ثم يجب أن تبدأ النسخ الجديدة وتعود بحالة مسبار جاهزية صحية قبل أن تتمكن من استقبال الطلبات الواردة. إذا لم تستطع تحمل أي فترة تحتوي على أقل من الحد الأدنى لعدد النسخ التي حددتها، فكر في التوفير الزائد للحفاظ على أداء تطبيقك حتى لو أصبحت المنطقة غير متاحة.
حدد طلبات الموارد والحدود لمساعدة جدولة تطبيقات الحاويات على اتخاذ قرارات تحديد المواقع المثلى عبر المناطق. يمكن أن تؤدي متطلبات الموارد غير المحددة بشكل كاف إلى فشل التوزيع أو التنسيب غير المتكافئ أثناء الحمل العالي.
لمزيد من المعلومات حول خيارات التكوين، راجع تعيين قواعد التحجيم.
السلوك عندما تكون جميع المناطق صحية
يصف هذا القسم ما يمكن توقعه عند تكوين موارد تطبيقات الحاويات لتكرار المنطقة وتشغيل جميع مناطق التوفر.
توجيه حركة المرور بين المناطق: مع تطبيقات الحاويات الاحتياطية في المناطق، تعمل المنصة في نموذج نشط-نشط حيث تخدم عدة نسخ حركة مرور في نفس الوقت. تقوم وحدة التحكم بتوزيع الطلبات الواردة عبر جميع النسخ السليمة، بغض النظر عن منطقتها، وتستخدم توازن الحمل الدائري بشكل افتراضي. كل منطقة تعالج الطلبات بشكل مستقل، ولا تعطي المنصة الأولوية لأي منطقة محددة لتوزيع المرور. تنشأ المجسات الصحية من جميع المناطق لضمان التقييم الصحي الدقيق لكل نسخة طبق الأصل من وجهات نظر متعددة.
تكرار البيانات بين المناطق: تطبيقات الحاويات لا تكرر بيانات التطبيقات بين المناطق لأنها مصممة لأحمال العمل بدون حالة. أي بيانات يخزنها تطبيقك في التخزين المؤقت، بما في ذلك التخزين المجهول بالحاوية والتخزين المكرر، يتم حذفها عند إيقاف الحاوية أو النسخة.
بالنسبة لمتطلبات البيانات ذات الحالة، قم بتحميل مشاركة ملف Azure Files التي تم تكوينها للتخزين المتكرر في المنطقة، أو استخدم خدمات Azure الأخرى مثل Azure Cosmos DB أو Azure SQL Database التي توفر إمكانات النسخ المتماثل عبر المناطق الخاصة بها.
يقوم النظام الأساسي بنسخ بيانات تعريف مستوى التحكم فقط بما في ذلك تكوينات التطبيق وقواعد القياس والأسرار عبر المناطق للحصول على قابلية وصول عالية. يتم سحب صور الحاوية من سجل الحاوية إلى كل منطقة حسب الحاجة عند إنشاء النسخ المتماثلة.
السلوك أثناء فشل المنطقة
يصف هذا القسم ما يمكن توقعه عند تكوين موارد تطبيقات الحاوية لتكرار المنطقة وهناك انقطاع في منطقة التوفر.
الكشف والاستجابة: Azure يكتشف تلقائيا فشل المناطق. تتوقف تطبيقات الحاويات على الفور عن جدولة النسخ المتماثلة الجديدة إلى المنطقة الفاشلة وتبدأ في إعادة توزيع نسبة استخدام الشبكة إلى النسخ المتماثلة السليمة في المناطق المتبقية. يتعامل النظام الأساسي مع جميع عمليات تجاوز الفشل تلقائيا دون الحاجة إلى تدخلك.
اخطار: لا تقوم Microsoft بإعلامك تلقائيا عندما تكون المنطقة معطلة. ومع ذلك، يمكنك استخدام Azure Service Health لفهم السلامة العامة للخدمة، بما في ذلك أي حالات فشل في المنطقة، ويمكنك إعداد تنبيهات حماية الخدمة لإعلامك بالمشكلات.
يمكنك أيضا مراقبة صحة تطبيقاتك من خلال مقاييس تطبيقات الحاويات في Azure Monitor. قم بتكوين التنبيهات عند سقوط عدد النسخ وطلب معدلات الفشل لتلقي إشعارات فورية عند حدوث مشاكل متعلقة بالمنطقة.
الطلبات النشطة: قد يتم إسقاط طلبات الطيران إلى النسخ المقلدة في المنطقة الفاشلة، أو قد تواجه مهلة أو أخطاء في الاتصال. يتم إلغاء أي تنفيذ مهام تعمل في المنطقة المتأثرة ويتم وسمها كفاشلة.
فقدان البيانات المتوقع: لا يحدث فقدان بيانات على مستوى منصة تطبيقات الحاويات لأن الخدمة مصممة لأحمال العمل بدون حالة. يتم فقد أي بيانات مخزنة في التخزين سريع الزوال داخل منطقة التوفر عند إنهاء النسخة المتماثلة، ويجب استخدام التخزين سريع الزوال فقط للبيانات المؤقتة.
توقعت فترة التوقف المتوقعة: تعاني التطبيقات من وقت توقف ضئيل أو معدوم أثناء أعطال المناطق. يعتمد التأثير الفعلي على إعدادات الفحص الصحي للتطبيق وعدد النسخ المتماثلة في المناطق الصحية. تأكد من اتباع العملاء إرشادات التعامل مع الأعطال المؤقتة لتقليل أي تأثيرات.
أي وظيفة تعمل في المنطقة المتأثرة يتم إلغاؤها ويتم وسمها على أنها فاشلة. إذا كنت بحاجة لأن تكون المهمة مقاومة لفشل المنطقة، قم بضبط إعادة التشغيل، أو ضبط التوازي بحيث تشغل المهمة نسخا متعددة من نفس التنفيذ. لمزيد من المعلومات، راجع تكوين الوظيفة المتقدم.
إعادة توجيه حركة المرور: تقوم مجسات الصحة في وحدة التحكم بالدخول باكتشاف النسخ غير القابلة للوصول بسرعة وإزالتها من مجموعة توازن الأحمال. اعتمادا على تكوين فحص الصحة في تطبيقك، تحدث عملية التجاوز هذه عادة خلال حوالي 30 ثانية. يتم توزيع نسبة استخدام الشبكة الواردة اللاحقة عبر النسخ المتماثلة السليمة المتبقية. يحدث هذا التحويل عبر الحركة بشكل شفاف للعملاء، الذين يستمرون في استخدام نفس رابط التطبيق.
إذا تم تفعيل التوافق في الجلسة ، وتوقفت المنطقة، يتم توجيه العملاء الذين تم توجيههم سابقا إلى نسخ في تلك المنطقة إلى نسخ جديدة لأن النسخ السابقة لم تعد متاحة. يتم فقدان أي حالة مقترنة بالنسخ المتماثلة السابقة.
لن تبدأ أي وظائف جديدة في المنطقة المعطوبة.
إدارة المشاكل: قد يتم إنشاء نسخ مقلدة جديدة في المناطق الصحية إذا تم تفعيل قواعد التدرج التلقائي بناء على زيادة الحمل.
استعادة المنطقة
عندما تتعافى منطقة توافر الخدمات من الفشل، تعيد تطبيقات الحاوية تلقائيا دمج المنطقة في الخدمة النشطة دون الحاجة إلى تدخلك. تكتشف أجهزة الصحة في المنصة متى تصبح البنية التحتية في المنطقة المستردة متاحة وتبدأ تطبيقات الحاويات في جدولة نسخ جديدة لتلك المنطقة بناء على تكوين التوسع الخاص بك. تستمر النسخ الموجودة في المناطق الصحية في خدمة حركة المرور أثناء عملية إعادة الدمج، مما يساعد في منع انقطاع الخدمة.
تعيد تطبيقات الحاويات توازن توزيع النسخ المتماثلة تدريجيا عبر جميع المناطق المتوفرة كجزء من عمليات القياس العادية. يحدث هذا التوازن التلقائي عندما يتم إنشاء نسخ مقلدة بسبب أحداث تدرج أو عندما يتم استبدال النسخ غير الصحية. لا يفرض النظام الأساسي إعادة التوزيع الفوري للنسخ المتماثلة السليمة الموجودة، مما يمنع إعادة تشغيل الحاوية غير الضرورية ويحافظ على استقرار التطبيق أثناء الاسترداد.
اختبار فشل المنطقة
يدير النظام الأساسي لتطبيقات الحاويات توجيه نسبة استخدام الشبكة وتجاوز الفشل وإرجاع الفشل لتطبيقات الحاويات الزائدة عن الحاجة في المنطقة. تتم إدارة هذه الميزة بالكامل، لذلك لا تحتاج إلى بدء عمليات فشل منطقة التوفر أو التحقق من صحتها.
للتحقق من قدرة تطبيقك على مقاومة فشل المناطق، قم بمحاكاة الاضطرابات على مستوى المنطقة في طبقة التطبيق باستخدام أساليب اختبار محكمة. أوقف أو أزل النسخ من مناطق محددة عن طريق تصغير تطبيقك، وراقب كيف تتعامل النسخ المتبقية مع الحمل المتزايد. راقب المقاييس الرئيسية أثناء اختبار المرونة، بما في ذلك عدد النسخ المقلدة، ونسب نجاح الطلبات، وأوقات الاستجابة، وسلوك التدرج التلقائي. تأكد من أن الحد الأدنى من عدد النسخ يحافظ على توفر الخدمة عند إزالة النسخ وتحقق من أن قواعد التوسع يمكنها تحمل الحمل الزائد على النسخ المتبقية. اختبر إعدادات فحص الصحة الخاص بك عن طريق فشل نقاط نهاية الصحة عمدا للتأكد من أن المنصة تزيل الحالات غير الصحية من التدوير خلال الأطر الزمنية المتوقعة.
القدرة على الصمود في وجه الإخفاقات على مستوى المنطقة
تطبيقات الحاويات هي خدمة منطقة واحدة. إذا أصبحت المنطقة غير متاحة، فلن تتوفر بيئتك وتطبيقاتك أيضا.
حلول مخصصة متعددة المناطق للمرونة
لتقليل مخاطر فشل منطقة واحدة يؤثر على تطبيقك، يمكنك نشر البيئات عبر مناطق متعددة. تساعد الخطوات التالية على تعزيز المرونة:
قم بنشر تطبيقاتك في بيئات في كل منطقة. كل بيئة تتطلب تكوين شبكة افتراضية خاصة بها، وتنطبق متطلبات الشبكة الفرعية بشكل مستقل على كل نشر إقليمي. يجب أن تكون صور الحاويات متاحة من جميع المناطق، ويمكنك تحقيق ذلك باستخدام Azure Container Registry مع تفعيل التكرار الجغرافي.
قم بتكوين نهج موازنة التحميل وتجاوز الفشل باستخدام خدمة مثل Azure Front Door أو Azure Traffic Manager.
قم بنسخ بياناتك عبر المناطق بحيث يمكنك استرداد حالة التطبيق الأخيرة.
النسخ الاحتياطي والاستعادة
لا توفر تطبيقات الحاويات إمكانات نسخ احتياطي مضمنة لتطبيقاتك أو بياناتك. كنظام أساسي لاستضافة الحاويات عديمة الحالة ، تتوقع Container Apps أن تقوم التطبيقات بإدارة استراتيجيات استمرارية البيانات واستردادها من خلال الخدمات الخارجية. حاويات التطبيقات وأنظمة الملفات المحلية الخاصة بها سريعة الزوال، ويتم فقد أي بيانات مخزنة محليا عند إعادة تشغيل النسخ المتماثلة أو نقلها.
المرونة أثناء تحديثات التطبيق
استخدم إدارة المراجعة لنشر التحديثات على تطبيقك دون توقف. يمكنك إنشاء نسخ جديدة بصور حاوية محدثة وإجراء عملية تحويل باستخدام استراتيجية نشر زرقاء وأخضر، أو تحويل حركة المرور تدريجيا باستخدام قواعد تقسيم الحركة. خلال تحديثات التطبيقات، تحافظ المنصة على الحد الأدنى من عدد النسخ من خلال إنشاء حاويات جديدة قبل إيقاف القديمة، مما يساعد على منع انقطاعات الخدمة.
لمزيد من المعلومات، راجع تحديث ونشر التغييرات في تطبيقات الحاويات.
المرونة في صيانة الخدمة
تقوم تطبيقات الحاويات بإجراء صيانة تلقائية للنظام الأساسي لتطبيق تحديثات الأمان ونشر ميزات جديدة وتحسين موثوقية الخدمة. تستخدم المنصة تحديثات متجددة عبر مجالات الأعطال ومناطق التوفر لتقليل الاضطرابات في التطبيقات الجارية. خلال فترات الصيانة، تستمر الحاويات في العمل دون انقطاع لأن التحديثات تطبق على البنية التحتية الأساسية على مراحل.
يمكنك تحديد نوافذ الصيانة الخاصة بك، وهي فترات زمنية تريد إجراء الصيانة فيها على تطبيقاتك. ضع في اعتبارك أن التحديثات الحرجة قد تحدث خارج فترات الصيانة الخاصة بك. لمزيد من المعلومات، راجع صيانة خطط لتطبيقات الحاويات.
اتفاقية مستوى الخدمة
تصف اتفاقية مستوى الخدمة (SLA) لخدمات Azure التوفر المتوقع لكل خدمة والشروط التي يجب أن يفي بها الحل الخاص بك لتحقيق توقع التوفر هذا. لمزيد من المعلومات، راجع اتفاقيات مستوى الخدمة للخدمات عبر الإنترنت.
مستوى مستوى الخدمة لتوفر تطبيقات الحاويات يعتمد على قواعد الحجم التي تضعها على تطبيقاتك.