لقد قمت بتحديث مواقعي من 3.1.0.beta1 إلى 3.1.0.beta2، وبعد تهيئة الإصدار الجديد، ولكن قبل تدمير حاويات التطبيق القديمة وبدء حاويات جديدة، بدأ موقع واحد على الأقل من هذه المواقع في عرض صفحة الخطأ العامة للمستخدمين.
لم ألاحظ ذلك على موقع الاختبار الخاص بي أو المواقع الأخرى التي أديرها، ولكن من الممكن أن يكون قد حدث ولم أره.
في كلتا الحالتين، بالنسبة لي في حالة واحدة على الأقل، لم تنجح عملية التحديث “بدون انقطاع”.
تم تقسيم 9 مشاركات إلى موضوع جديد: مشاكل الترقية المستضافة ذاتيًا إلى 3.x: لا يمكن التراجع
تم دمج منشور في موضوع موجود: مشاكل الترقية المستضافة ذاتيًا إلى 3.x: لا يمكن التراجع
أود أن أكرر أنني لم أستخدم أداة التحديث الرسومية. لدي تثبيت متعدد الحاويات. لقد قمت بما يلي:
git pull
./launcher bootstrap app
./launcher destroy app && ./launcher start app
./launcher cleanup
(أستخدم app لتطبيق الويب حتى في التثبيتات متعددة الحاويات. أعرف أن هذه ليست الممارسة المعتادة. أكره كتابة web_only)
بعد فترة من بدء bootstrap وقبل تدمير التطبيق، عرض الإصدار القديم الذي يعمل على قاعدة البيانات الجديدة شاشة خطأ فقط. لا أتذكر المحتويات، ولم أقم بإنشاء فترة انقطاع أطول عن طريق التوقف لالتقاط لقطة شاشة قبل القيام بالتدمير/البدء، لكنها كانت مجرد نص على خلفية بيضاء ولم تكن صفحة صيانة النظام. لقد رأيت هذا فقط بضع مرات من قبل، عندما يقوم bootstrap بتشغيل db:migrate كجزء من إعادة البناء غير المتزامنة “بدون انقطاع”، يفشل البرنامج القديم الذي لا يزال قيد التشغيل بسبب عدم اتساق المخطط.
ما رأيته هو أي شيء يحدث في حالة عدم اتساق قاعدة البيانات. هذا أفضل بكثير من الاستمرار بسذاجة، مما يؤدي إلى كسر قاعدة البيانات! عندما نشرت، كان ذلك للتحذير من أن هذه كانت إحدى الحالات النادرة التي يؤدي فيها تطبيق تحديث نقطي (هنا من 3.1.0.beta1 إلى 3.1.0.beta2) إلى عدم توافق في المخطط بين كود 3.1.0.beta1 وقاعدة البيانات بعد تشغيل db:migrate الخاص بـ 3.1.0.beta2، كما يحدث نادرًا ولكن بشكل متقطع مع التحديثات العادية ذات الانقطاع المنخفض في النشر متعدد الحاويات.
تجربتي مختلفة عن الخطأ الذي تم الإبلاغ عنه مع ruby في أداة التحديث الرسومية. إنها مشكلة غير مرتبطة تمامًا. أدرك أن مشاركتي تم نقلها من الإعلان إلى سلسلة “مشاكل مع” عامة، لكنني أريد أن أوضح أن السبب الذي جعلني أنشرها في الإعلان كان لتحذير مستضيفي الخدمة الآخرين مثلي عندما يرون الإعلان بأن هذا التحديث المحدد كان يمكن أن يكون له هذا التأثير.
لم تكن رسالتي شكوى من خطأ، أو حتى مشكلة. لقد كان المقصود منها فقط إشعار بحالة طبيعية ولكنها نادرة مرتبطة بهذا الإصدار المحدد ولم يتم الإشارة إليها في ملاحظات الإصدار.
الشكاوى حول مدير docker الذي لا يتعرف على أنه لا يمكنه التحديث من داخل الصورة غير مرتبطة تمامًا بمحاولتي لتقديم إشعار مفيد لمسؤولي استضافة الخدمة الآخرين.
سيكون من المنطقي جدًا فصل هذه المشكلات غير المرتبطة في سلاسل منفصلة للمشكلات المستقلة. تعديل بواسطة @supermathie: تم
إعجاب واحد (1)
هل تقوم بترحيل على مرحلتين باستخدام Introducing Post Deployment Migration
هذا النمط ضروري إذا كنت تقوم، على سبيل المثال، بنشر أزرق/أخضر وتحتاج إلى أن يستمر الإصدار السابق في العمل.
إعجاب واحد (1)
أعتقد أن هذا يجيب على السؤال. برنامج launcher النصي لا يدعم SKIP_POST_DEPLOYMENT_MIGRATIONS
مرة أخرى، أنا لا أبلغ عن خطأ. أحاول فقط تحذير الآخرين الذين يستخدمون التثبيت القياسي متعدد الحاويات باستخدام العملية الموثقة العادية لاستخدام launcher مع تثبيت متعدد الحاويات بأن هذا يختلف عن تجربتهم المعتادة.
حقًا حقًا، بصدق، أعني ذلك، هذا ليس تقرير خطأ!
إذا أردت نشرًا أزرق/أخضر باستخدام launcher، فيجب عليّ تقديم طلب سحب (PR) لـ launcher لتنفيذه. 
إعجاب واحد (1)
لم أتوصل إلى “المشكلة” في عنوان الموضوع؛ فقد حدث ذلك عندما تم نقل تعليقي خارج موضوع الإعلان. لقد قمت الآن بتعديل العنوان لجعله واضحًا، آمل، أنني لا أشتكي من مشكلة.
إعجاب واحد (1)
كل شيء على ما يرام!
أشك في أن هناك عددًا قليلاً جدًا من المستخدمين الذين يقومون بتشغيل حاويات متعددة باللون الأزرق/الأخضر، ولكننا نرحب بالاقتراحات حول كيفية القيام بذلك.
وكذلك، كيفية العثور على الموضوع الذي ربطته؛ أشك في أنه ليس من السهل العثور عليه إذا لم يكن المرء يعرف بالفعل أنه موجود.
إعجابَين (2)
لقد رأيت وثيقة SKIP_POST_DEPLOYMENT_MIGRATIONS. ما فاتني حقًا هو هذا المنشور الذي يوضح كيفية إجراء عمليات نشر بدون توقف باستخدام launcher:
لذا الآن عليّ التفكير في ذلك، بعد أن علمت أنه ممكن. إذا قمت بذلك، سأقوم بتحديث MKJ's Opinionated Discourse Deployment Configuration بما أقوم به.
لقد كنت أواجه الكثير من المتاعب في الاستعداد لذلك عندما أقدم أربعة، وفي بعض الأشهر أربعة ونصف تسعات من التوفر على خدمة أديرها مجانًا في وقت فراغي. إنه شهادة على جودة تطوير Discourse أن أتمكن من القيام بذلك بناءً على سياسة “اجتياز الاختبارات”، بما في ذلك أشياء مثل دقيقة إضافية أو نحو ذلك من وقت التوقف الذي رأيته هذه المرة، وأحيانًا إعادة تشغيل المضيف لتحديثات الأمان.
3 إعجابات
يقوم برنامج Ansible النصي الذي يستخدمه dashboard.literatecomputing.com بتشغيل مهمة Rake بعد تشغيل الحاوية الجديدة لإجراء عمليات الترحيل اللاحقة. يعتمد على تشغيل SKIP_POST_DEPLOYMENT_MIGRATIONS في web_only.yml. أقوم بذلك فقط على المواقع التي أعرف أنها ستتم إدارتها بواسطة نصوصي البرمجية، لأنه إذا لم تفهم كيفية عملها، فقد تكون قنبلة موقوتة.
لاحظ أنه بالنسبة للعديد من الترقيات، فإن تهيئة الحاوية الجديدة لن تؤدي إلى تعطيل الأمور للحاوية قيد التشغيل، ولكن بالنسبة للبعض الآخر، فإنها تفعل ذلك. ليس من غير الشائع أن تقوم الترقية بترحيل قاعدة البيانات بحيث لا تتمكن الحاوية القديمة من استخدام قاعدة البيانات (بدون استخدام SKIP_POST_DEPLOYMENT_MIGRATIONS).
إعجابَين (2)