كما لاحظنا على مر السنين، في بعض الأحيان يفشل التحديث/الترقية بسبب التبعيات. أي إصدار Docker/نظام التشغيل.
فكرتي هي أن يقوم Discourse بتشغيل نوع من فحص التبعية للتأكد من استيفاء المتطلبات الأساسية. إذا فشل الفحص، فإنه يعطي بعض التفاصيل حول ما قد تكون هناك حاجة إليه وإحباط عملية التحديث/الترقية.
سيساعد ذلك في تقليل وقت تعطل المنتدى عن طريق إحباط تحديث/ترقية Core Discourse عن طريق إحباط العملية التي ستفشل.
إنهم يحاولون جاهدين القيام بذلك. عدد الأشياء التي يمكن أن تسوء كبير جدًا. في الغالب، إذا لم تحافظ على تحديث نظام التشغيل الخاص بك (وربما Docker)، فالخطأ خطأك.
إنهم يحاولون التحقق من إصدار Docker، والبرامج النصية التي أستخدمها تقوم بترقية Docker إذا كان من المعروف أنه سيئ (ربما يجب أن تقوم دائمًا بترقية Docker).
أعتقد أنهم قد يحسنون صنعًا إذا قاموا دائمًا بفرض ترقية سطر الأوامر إذا تغيرت الصورة الأساسية على الإطلاق. أنا في الغالب لا أستخدمه أبدًا لأن لوحة التحكم الخاصة بي تقوم بتحديث سطر الأوامر بنقرة واحدة.
تحديث deos docker_manager تحديث docker؟
أنا بالتأكيد لا أحاول إلقاء اللوم. الشيء المؤسف في الاستضافة الذاتية بشكل أكثر تحديدًا هو ليس بالضرورة فهم نظام تشغيل الخادم. معظم الناس يقومون بتثبيت نظام التشغيل ويحافظون عليه محدثًا بشكل عام. ولكن غالبًا مع الإصدارات طويلة الأمد (LTS) قد لا يعرفون أو يفهمون ترقية نظام التشغيل. خاصة إذا كانوا معتادين على الإصدارات المتجددة (rolling releases).
على سبيل المثال ، لاحظت شركة أساعدها بعد عدم التحديث لفترة من الوقت أن هناك تحديثًا متاحًا. لذلك قاموا بتحديث دوكر (Docker) من خلال واجهة المستخدم الرسومية (web UI). مما سمح لهم بعد ذلك بتحديث ديسكورس (Discourse).
نظرًا لأن أوبونتو (Ubuntu) طويل الأمد (LTS) لم يكن حديثًا بدرجة كافية ، فإن تحديث دوكر (Docker) لم يستوف الحد الأدنى من المتطلبات. ومع ذلك ، سمحت واجهة المستخدم الرسومية (web UI) بمحاولة التحديث. والتي بالطبع فشلت وأدت إلى تعطل الموقع.
لذلك حاولوا إعادة بناء سطر الأوامر (command line rebuild) والذي بالطبع فشل بسبب عدم استيفاء الحد الأدنى من المتطلبات.
إذا كان التحديث في الويب قد حدد أن إصدار دوكر (Docker) لم يكن الحد الأدنى. كان يمكن أن يوقف عملية التحديث مع إشعار بوجود تبعية لم يتم استيفاؤها دون تعطل الموقع.
ألقيت نظرة عامة لهم. حيث يبدو أنهم ربما يقومون بتشغيل أشياء أخرى على الخادم. لقد وجهتهم إلى مطالبة فنييهم بالنظر في ترقية الإصدار طويل الأمد (LTS) إلى إصدار أحدث. لأنني لم أكن أرغب في محاولة ترقية نظام التشغيل في حالة تعطيل أشياء أخرى يقومون بتشغيلها.
هل هناك طريقة سهلة لإعادة تشغيل الحاوية (container) قبل محاولة إعادة البناء عبر الويب وسط سطر الأوامر (web.
حاولت ./launcher start app
والذي فشل.
الشيء الآخر. نظرًا لكيفية تعطل موقع ديسكورس (discourse) ، هل يمكن أن ينجح تشغيل خادم جديد باستخدام آر سينك (rsync)؟ إنهم يقومون بتشغيل إصدار مستقر (stable) بدلاً من الاختبارات الموصى بها (tests passed).
إذا قاموا بتشغيل ‘:do-release-upgrade’ وترقية دوكر (Docker) يدويًا ، فهل سيكون ذلك فعالًا لترقية بوستجري (postgreq)؟
سيكون ذلك ضمن إصدار Ubuntu LTS المدعوم. ولكن فقط الإصدار (الإصدارات) المدعومة من قبل LTS. في هذه الحالة، دورة حياة LTS الخاصة بهم قد انتهت. لذلك فهو لا يدعم الحد الأدنى من إصدار Docker.
إصدارات Ubuntu LTS أعتقد أن لديها 4 سنوات من التحديثات.
ليس الأشخاص الذين أعمل معهم. لن يقوموا بتحديثه عندما أخبرهم أنه متأخر عن نهاية الدعم (EOL).
أنا متأكد من أن الأشياء التي تعمل داخل الحاوية لا يمكنها معرفة إصدار Docker الذي تعمل تحته.
ربما يمكنها ذلك. يبدو أنه يمكنك الحصول على هذا من داخل حاوية لمعرفة الإصدار الذي يعمل.
https://docs.docker.com/engine/api/v1.30/#operation/SystemVersion
لذا ربما يمكنهم القيام بعمل أفضل. يمكن أن يكون هذا شيئًا رائعًا لإضافته إلى لوحة المعلومات، إذا كان يعمل حقًا.
عادة ما يعمل. الاستثناء هو إذا تم ترحيل قاعدة البيانات.
إذا كان نظام التشغيل قديمًا، فعادةً ما أجد أنه من الأسهل والأكثر أمانًا الانتقال إلى جهاز افتراضي جديد. من الناحية المثالية، تقوم بذلك بينما لا يزال الخادم القديم يعمل. انظر نقل موقع Discourse إلى VPS آخر باستخدام rsync
إذا كان لديك نسخة احتياطية، يمكنك تخطي نسخ قاعدة البيانات وتخطي ترقية قاعدة البيانات، فقط استعادتها على قاعدة البيانات الجديدة.
هذا هو السبب في أنني قلت تحديث. في حالة نهاية الدعم (EOL)، يتطلب الأمر ترقية نظام التشغيل. لكنني أتفق معك في أن هناك مجموعة واسعة من الأشخاص الذين لا يتبعون التعليمات جيدًا. 
عندما تمت ترقيتي إلى مسؤول للشركة التي أساعدها مجانًا 
لقد أخبرتهم لأكثر من شهر متواصل أن منتدىهم سوف يتعطل في وقت ما لأنه لم يكن لديهم المساحة اللازمة لإجراء إعادة بناء التطبيق. كان لديهم خادم صغير الحجم (قبل 7 سنوات). على ما أذكر، كانت مساحته الإجمالية 25 جيجابايت. بالطبع لم يستمعوا. وانتهى بهم الأمر بدفع المال لشخص ما هنا لنقل المنتدى إلى خادم جديد. إجمالي وقت التعطل حوالي أسبوعين، ربما أكثر بقليل.
سيكون هذا رائعًا بالتأكيد إذا أمكن جعله يعمل. بالنسبة لأشخاص مثلك ومثلي الذين يعيشون هنا إلى حد ما، فإننا نبقي أنفسنا محدثين بشكل جيد مقارنة بالكثير من الأشخاص الذين يزورون فقط بعد ظهور مشكلة أو يبحثون عن إضافات ودعم آخر أقل أهمية.
حسنًا، سأنصحهم. ومع ذلك، لست متأكدًا من عمر النسخة الاحتياطية. لذا أتخيل أنه في حالتهم، سيلزم استكشاف rsync أو ترقية نظام التشغيل.
على خادمي الشخصي الذي كان يقترب من أن يكون قديمًا، قرأت الكثير وكنت حذرًا من عدم التحديث عبر الويب/سطر الأوامر. حتى أصبحت مرتاحًا لاستخدام إجراء rsync. وما زلت واجهت بعض المشكلات البسيطة التي ساعدتني أنت والمجتمع في تصحيحها.
