ترقية تطبيق Service Fabric

تطبيق Azure Service Fabric عبارة عن مجموعة من الخدمات. أثناء الترقية، يقوم Service Fabric بمقارنة بيان التطبيق الجديد مع الإصدار السابق ويحدد الخدمات الموجودة في التطبيق التي تتطلب تحديثات. يقارن Service Fabric الإصدار في بيانات الخدمة بالإصدار في الإصدار السابق. إذا لم يتغير إصدار الخدمة، فلن تتم ترقية هذه الخدمة.

ملاحظة

لا يتم الاحتفاظ بـ ApplicationParameters عبر ترقية تطبيق. من أجل الاحتفاظ بمعلمات التطبيق الحالية، يجب على المستخدم الحصول على المعلمات أولاً وتمريرها إلى استدعاء واجهة برمجة تطبيقات الترقية كما هو موضح أدناه:

$myApplication = Get-ServiceFabricApplication -ApplicationName fabric:/myApplication
$appParamCollection = $myApplication.ApplicationParameters

$applicationParameterMap = @{}
foreach ($pair in $appParamCollection)
{
    $applicationParameterMap.Add($pair.Name, $pair.Value);
}

Start-ServiceFabricApplicationUpgrade -ApplicationName fabric:/myApplication -ApplicationTypeVersion 2.0.0 -ApplicationParameter $applicationParameterMap -Monitored -FailureAction Rollback

نظرة عامة على الترقيات المتداولة

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

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

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

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

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

فحوصات الحماية أثناء الترقيات

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

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

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

أوضاع الترقية

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

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

ترقية الخدمات الافتراضية

يمكن أيضا ترقية بعض معلمات الخدمة الافتراضية المحددة في بيان التطبيق كجزء من ترقية التطبيق. يمكن فقط تغيير معلمات الخدمة التي تدعم التغيير من خلال Update-ServiceFabricService كجزء من الترقية. سلوك تغيير الخدمات الافتراضية أثناء ترقية التطبيق كما يلي:

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

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

تلميح

يجب أن يكون إعداد تكوين نظام المجموعة EnableDefaultServicesUpgradeصحيحا لتمكين القاعدتين 2) و3) أعلاه (تحديث الخدمة الافتراضية وحذفها). يتم دعم هذه الميزة بدءا من الإصدار 5.5 من Service Fabric.

ترقية تطبيقات متعددة باستخدام نقاط نهاية HTTPS

يجب أن تكون حريصا على عدم استخدام نفس المنفذ لمثيلات مختلفة من نفس التطبيق عند استخدام HTTPS. والسبب هو أن Service Fabric لن تتمكن من ترقية الشهادة لأحد مثيلات التطبيق. على سبيل المثال، إذا كان التطبيق 1 أو التطبيق 2 كلاهما يريد ترقية الشهادة 1 إلى الشهادة 2. عند حدوث الترقية، قد تكون Service Fabric قد قامت بتنظيف تسجيل الشهادة 1 باستخدام http.sys على الرغم من أن التطبيق الآخر لا يزال يستخدمها. لمنع حدوث ذلك، يكتشف Service Fabric وجود مثيل تطبيق آخر مسجل بالفعل على المنفذ مع الشهادة (بسبب http.sys) ويقوم بإفشال العملية.

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

إذا رأيت فشل الترقية باستخدام https، فهذا يعني وجود تحذير خطأ يقول "API خادم HTTP لـ Windows لا يدعم شهادات متعددة للتطبيقات التي تشترك في منفذ.”

المخطط الانسيابي لترقية التطبيق

يمكن أن يساعدك المخطط الانسيابي التالي لهذه الفقرة على فهم عملية ترقية تطبيق Service Fabric. على وجه الخصوص، يصف التدفق كيف تساعد المهلات، بما في ذلك HealthCheckStableDuration، وHealthCheckRetryTimeout، وUpgradeHealthCheckInterval، في التحكم في وقت اعتبار الترقية في مجال تحديث واحد ناجحة أو فاشلة.

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

يرشدك Upgrading your Application Using Visual Studio خلال ترقية التطبيق باستخدام Visual Studio.

ترقية التطبيق باستخدام PowerShell ترشدك خلال ترقية التطبيق باستخدام PowerShell.

تحكم في كيفية ترقية التطبيق باستخدام ضوابط الترقية.

اجعل ترقيات تطبيقك متوافقة من خلال تعلم كيفية استخدام تسلسل البيانات.

تعرف على كيفية استخدام الوظائف المتقدمة أثناء ترقية تطبيقك بالرجوع إلى Advanced Topics.

أصلح المشكلات الشائعة في ترقيات التطبيق بالرجوع إلى الخطوات في Troubleshooting Application Upgrades.