كيفية نشر تطبيق ASP.NET بدون توقف

Question

لنشر نسخة جديدة من موقعنا، نقوم بما يلي:

1. قم بضغط الرمز الجديد وتحميله على الخادم.
2. على الخادم المباشر، احذف كافة التعليمات البرمجية المباشرة من دليل موقع IIS على الويب.
3. قم باستخراج ملف zipfile الجديد إلى دليل IIS الفارغ الآن

هذه العملية كلها مكتوبة، وتحدث بسرعة كبيرة، ولكن لا يزال من الممكن أن تكون هناك فترة توقف تتراوح من 10 إلى 20 ثانية عندما يتم حذف الملفات القديمة، ويتم نشر الملفات الجديدة.

هل هناك أي اقتراحات بشأن طريقة التوقف لمدة 0 ثانية؟

Answer 1

أنت بحاجة إلى خادمين وموازن تحميل.إليك بالخطوات:

1. قم بتشغيل كل حركة المرور على الخادم 2
2. نشر على الخادم 1
3. خادم الاختبار 1
4. قم بتشغيل كل حركة المرور على الخادم 1
5. نشر على الخادم 2
6. خادم الاختبار 2
7. تحويل حركة المرور على كلا الخادمين

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

Answer 2

ال أداة نشر الويب من Microsoft يدعم هذا إلى حد ما:

يتيح دعم نظام ملفات Windows للمعاملات (TXF).عند تمكين دعم TXF ، تكون عمليات الملف ذرية ؛هذا هو ، إما ينجحون أو يفشلون تمامًا.هذا يضمن تكامل البيانات ويمنع البيانات أو الملفات من الموجودة في حالة "في منتصف الطريق" أو تالفة.في MS Deploy ، يتم تعطيل TXF افتراضيًا.

يبدو أن المعاملة مخصصة للمزامنة بأكملها.كما أن TxF هي إحدى ميزات Windows Server 2008، لذا فإن ميزة المعاملة هذه لن تعمل مع الإصدارات السابقة.

أعتقد أنه من الممكن تعديل البرنامج النصي الخاص بك لفترة التوقف 0 باستخدام المجلدات كإصدارات وقاعدة تعريف IIS:

• لمسار/عنوان url موجود:
  • طريق:\web\app\v2.0\
  • عنوان URL: http://app
• انسخ موقع الويب الجديد (أو المعدل) إلى الخادم ضمن
  • \web\app\v2.1\
• تعديل قاعدة تعريف IIS لتغيير مسار موقع الويب
  • من \ويب\التطبيق\2.0\
  • ل \web\app\v2.1\

توفر هذه الطريقة الفوائد التالية:

• في حالة وجود مشكلة في الإصدار الجديد، يمكنك العودة بسهولة إلى الإصدار 2.0
• للنشر على خوادم فعلية أو ظاهرية متعددة، يمكنك استخدام البرنامج النصي الخاص بك لنشر الملف.بمجرد حصول كافة الخوادم على الإصدار الجديد، يمكنك تغيير قواعد تعريف كافة الخوادم في نفس الوقت باستخدام أداة Microsoft Web Deployment Tool.

Answer 3

يمكنك تحقيق عدم نشر وقت التوقف عن العمل على خادم واحد من خلال استخدام توجيه طلب التطبيق في IIS كموازن تحميل البرامج بين موقعي IIS محليين على منافذ مختلفة.يُعرف هذا باسم أ استراتيجية النشر باللون الأزرق والأخضر حيث يتوفر موقع واحد فقط من الموقعين في موازن التحميل في أي وقت محدد.قم بالنشر إلى الموقع "المعطل"، وقم بتسخينه، وإحضاره إلى موازن التحميل (عادةً عن طريق اجتياز فحص صحة توجيه طلب التطبيق)، ثم خذ الموقع الأصلي الذي كان موجودًا، خارج "التجمّع" (مرة أخرى عن طريق فشل فحص الصحة).

يمكن العثور على البرنامج التعليمي الكامل هنا.

Answer 4

لقد مررت بهذا مؤخرًا وكان الحل الذي توصلت إليه هو إعداد موقعين في IIS والتبديل بينهما.

بالنسبة للتكوين الخاص بي، كان لدي دليل ويب لكل موقع A وB مثل هذا:C: Intranet Live A Interface C: intranet Live B Interface

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

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

Answer 5

باستخدام فئة ServerManager الخاصة بـ Microsoft.Web.Administration، يمكنك تطوير وكيل النشر الخاص بك.

الحيلة هي تغيير PhysicalPath الخاص بـ VirtualDirectory، مما يؤدي إلى تبديل ذري عبر الإنترنت بين تطبيقات الويب القديمة والجديدة.

انتبه إلى أن هذا قد يؤدي إلى تنفيذ AppDomains القديمة والجديدة بالتوازي!

المشكلة هي كيفية مزامنة التغييرات مع قواعد البيانات وما إلى ذلك.

من خلال الاستقصاء عن وجود AppDomains مع PhysicalPaths القديمة أو الجديدة، من الممكن اكتشاف وقت انتهاء AppDomains القديم، وما إذا كان AppDomains الجديد قد بدأ تشغيله.

لفرض بدء تشغيل AppDomain، يجب عليك تقديم طلب HTTP (يدعم IIS 7.5 ميزة التشغيل التلقائي)

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

(أستخدم ملف علامة في تطبيق الويب لتمكين سلوك انتظار Mutex) بمجرد تشغيل تطبيق الويب الجديد ، أحذف ملف العلامة.

Answer 6

حسنًا، بما أن الجميع يصوتون على الإجابة التي كتبتها في عام 2008*...

سأخبرك كيف نفعل ذلك الآن في عام 2014.لم نعد نستخدم مواقع الويب لأننا نستخدم ASP.NET MVC الآن.

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

كما أننا لا نعتمد على أحدث معالج من Microsoft - فهو بطيء جدًا، ويحتوي على الكثير من السحر المخفي، ويميل إلى تغيير اسمه.

وإليك كيف نفعل ذلك:

1. لدينا خطوة إنشاء منشور تقوم بنسخ ملفات DLL التي تم إنشاؤها إلى مجلد "bin-pub".

2. نحن نستخدم Beyond Compare (وهو أمر ممتاز**) للتحقق من الملفات التي تم تغييرها ومزامنتها (عبر FTP لأنه مدعوم على نطاق واسع) حتى خادم الإنتاج

3. لدينا عنوان URL آمن على موقع الويب يحتوي على زر ينسخ كل شيء في "bin-pub" إلى "bin" (أخذ نسخة احتياطية أولاً لتمكين التراجع السريع).في هذه المرحلة، يقوم التطبيق بإعادة تشغيل نفسه.بعد ذلك يتحقق ORM الخاص بنا مما إذا كان هناك أي جداول أو أعمدة تحتاج إلى إضافتها ويقوم بإنشائها.

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

تستغرق عملية النشر بأكملها من 5 ثوانٍ إلى 30 دقيقة، اعتمادًا على عدد الملفات التي تم تغييرها وعدد التغييرات المطلوب مراجعتها.

بهذه الطريقة لن تضطر إلى نسخ موقع ويب بأكمله إلى دليل مختلف، بل إلى مجلد bin فقط.لديك أيضًا سيطرة كاملة على العملية وتعرف بالضبط ما الذي يتغير.

**نقوم دائمًا بإجراء نظرة سريعة على التغييرات التي ننشرها - كإجراء فحص مزدوج في اللحظة الأخيرة، حتى نعرف ما يجب اختباره وإذا حدث أي عطل، فنحن جاهزون.نحن نستخدم Beyond Compare لأنه يتيح لك إمكانية تقسيم الملفات بسهولة عبر FTP.لن أفعل هذا أبدًا بدون BC، ليس لديك أي فكرة عما تقوم بالكتابة فوقه.

*قم بالتمرير إلى الأسفل لرؤيته :( راجع للشغل، لم أعد أوصي بمواقع الويب لأنها أبطأ في الإنشاء ويمكن أن تتعطل بشدة مع نصف الملفات المؤقتة المجمعة.لقد استخدمناها في الماضي لأنها سمحت بنشر أكثر مرونة لكل ملف على حدة.سريع جدًا في إصلاح مشكلة بسيطة ويمكنك أن ترى بالضبط ما تقوم بنشره (إذا كنت تستخدم Beyond Compare بالطبع - وإلا انسَ الأمر).

Answer 7

تتضمن طرق التوقف الصفرية الوحيدة التي يمكنني التفكير فيها الاستضافة على خادمين على الأقل.

Answer 8

أود تحسين إجابة جورج قليلاً، على النحو التالي، لخادم واحد:

1. استخدم مشروع نشر الويب لتجميع الموقع مسبقًا في ملف DLL واحد
2. قم بضغط الموقع الجديد، وتحميله على الخادم
3. قم بفك ضغطه إلى مجلد جديد موجود في مجلد يتمتع بالأذونات الصحيحة للموقع، بحيث ترث الملفات التي تم فك ضغطها الأذونات بشكل صحيح (ربما e:\web، مع المجلدات الفرعية v20090901، v20090916، إلخ)
4. استخدم IIS Manager لتغيير اسم المجلد الذي يحتوي على الموقع
5. احتفظ بالمجلد القديم لفترة من الوقت، حتى تتمكن من الرجوع إليه في حالة حدوث مشكلات

ستؤدي الخطوة 4 إلى إعادة تدوير العملية المنفذة لـ IIS.

يعد هذا وقت توقف صفري فقط إذا كنت لا تستخدم جلسات InProc؛استخدم وضع SQL بدلاً من ذلك إذا استطعت (والأفضل من ذلك، تجنب حالة الجلسة تمامًا).

بالطبع، يكون الأمر أكثر تعقيدًا عندما يكون هناك عدة خوادم و/أو تغييرات في قاعدة البيانات....

Answer 9

للتوسع في إجابة sklivvz، التي تعتمد على وجود نوع من موازن التحميل (أو مجرد نسخة احتياطية على نفس الخادم)

1. قم بتوجيه كل حركة المرور إلى الموقع/الخادم 2
2. اختياريًا، انتظر قليلاً للتأكد من أن أقل عدد ممكن من المستخدمين لديهم مهام سير عمل معلقة على الإصدار المنشور
3. قم بالنشر إلى الموقع/الخادم 1 وقم بتسخينه قدر الإمكان
4. تنفيذ عمليات ترحيل قاعدة البيانات بطريقة المعاملات (نسعى جاهدين لجعل ذلك ممكنًا)
5. قم بتوجيه كل حركة المرور على الفور إلى الموقع/الخادم 1
6. النشر إلى الموقع/الخادم 2
7. حركة المرور المباشرة إلى كلا الموقعين/الخوادم

من الممكن تقديم القليل من اختبار الدخان، عن طريق إنشاء لقطة/نسخة من قاعدة البيانات، ولكن هذا ليس ممكنًا دائمًا.

إذا كان ذلك ممكنًا ومطلوبًا، استخدم "اختلافات التوجيه"، مثل عناوين URL مختلفة للمستأجر (customerX.myapp.net) أو مستخدمين مختلفين، للنشر إلى مجموعة غير معروفة من خنازير غينيا أولاً.إذا لم يفشل أي شيء، أطلق سراحه للجميع.

نظرًا لأن عمليات ترحيل قاعدة البيانات متضمنة، فإن الرجوع إلى الإصدار السابق غالبًا ما يكون مستحيلًا.

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

Answer 10

هذه هي الطريقة التي أفعل ذلك:

الحد الأدنى المطلق لمتطلبات النظام:
1 خادم مع

• 1 موازن تحميل/وكيل عكسي (على سبيل المثال.nginx) يعمل على المنفذ 80
• 2 ASP.NET-Core/monoverse-proxy/fastcgi chroot-jails أو حاويات الإرساء تستمع على منفذي TCP مختلفين
  (أو حتى تطبيقين فقط للوكيل العكسي على منفذي TCP مختلفين دون أي وضع حماية)

سير العمل:

بدء المعاملة myupdate

try
    Web-Service: Tell all applications on all web-servers to go into primary read-only mode 
    Application switch to primary read-only mode, and responds 
    Web sockets begin notifying all clients 
    Wait for all applications to respond

    wait (custom short interval)

    Web-Service: Tell all applications on all web-servers to go into secondary read-only mode 
    Application switch to secondary read-only mode (data-entry fuse)
    Updatedb - secondary read-only mode (switches database to read-only)

    Web-Service: Create backup of database 
    Web-Service: Restore backup to new database
    Web-Service: Update new database with new schema 

    Deploy new application to apt-repository 
    (for windows, you will have to write your own custom deployment web-service)
    ssh into every machine in array_of_new_webapps
    run apt-get update
    then either 
    apt-get dist-upgrade
    OR
    apt-get install <packagename>
    OR 
    apt-get install --only-upgrade <packagename>
    depending on what you need
    -- This deploys the new application to all new chroots (or servers/VMs)

    Test: Test new application under test.domain.xxx
    -- everything that fails should throw an exception here
    commit myupdate;

    Web-Service: Tell all applications to send web-socket request to reload the pages to all clients at time x (+/- random number)
    @client: notify of reload and that this causes loss of unsafed data, with option to abort 

    @ time x:  Switch load balancer from array_of_old_webapps to array_of_new_webapps 
    Decomission/Recycle array_of_old_webapps, etc.

catch
        rollback myupdate 
        switch to read-write mode
        Web-Service: Tell all applications to send web-socket request to unblock read-only mode
end try 

Answer 11

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

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