أود أن أكرر أنني لم أستخدم أداة التحديث الرسومية. لدي تثبيت متعدد الحاويات. لقد قمت بما يلي:
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: تم