والتي تقول قم بالتحديث كل بضعة أسابيع، كل بضعة أشهر يجب عليك التحديث عبر
إذا كنت تستضيف Discourse بنفسك، فأنت بحاجة من حين لآخر إلى تشغيل تحديث يدوي عبر سطر الأوامر للحصول على أحدث إصدارات الأمان وأحدث المكتبات. لا يتم التقاط هذه التحديثات في admin/update، وهذا هو السبب في أنك ستحتاج من حين لآخر إلى القيام بهذه الخطوة الإضافية.
هناك عدد قليل من المواضيع الأخرى التي تتحدث عن admin->update مقابل ssh/console update، ولا أحد منها يوضح أي التحديثات لا يمكن إجراؤها في المتصفح.
كانت تجربتي أنه في 9 أشهر من تشغيل Discourse، فشل تحديث واحد عبر الويب/المسؤول، ووجدت المقالة أعلاه، وقمت بتشغيل الأوامر المشار إليها في جلسة ssh.
هل هناك طريقة أفضل لمعرفة أي طريقة يجب استخدامها بخلاف “الطريقة الأسهل تفشل”؟
شكرا مقدما
عادتي الخاصة الآن هي استخدام سطر الأوامر دائمًا. في السابق، كنت أستخدم الواجهة على الويب، ولكن نظرًا لأنها قد لا تعمل ولأنها تمنحني تحكمًا ورؤية أقل، لم أعد أزعج نفسي بها.
لكن منتدياتي ذات حركة مرور منخفضة جدًا، ولا يُعد تعطلها لفترة قصيرة أمرًا كبيرًا.
ومن الجدير بالذكر أيضًا أنني مرتاح في استخدام سطر الأوامر. ولكن بعد ذلك، سيتعين على كل مسؤول في Discourse استخدام سطر الأوامر في مرحلة ما.
شكرًا، هذا مفيد، لقد تخيلت أن سطر الأوامر يمكن أن يكون أسرع (وقت تعطل أقل/مراقبة وقت العملية).
لقد اعتبرنا واجهة الويب/واجهة المستخدم الرسومية للتحديثات ميزة كبيرة جدًا، لأنه بقدر ما لدي عقود من الخبرة في البرمجة والإدارة على أنظمة يونكس/لينكس، فأنا أيضًا نقطة فشل فردية في المؤسسة، لذلك كان من المخيب للآمال أن أعرف أن بعض التحديثات تتطلب سطر الأوامر.
كل شيء على ما يرام، إنها منصة رائعة، أكثر من تستحق سعر الدخول
من الجيد الاستعداد للترقية عبر سطر الأوامر، حتى لو كنت على وشك محاولة الترقية عبر الويب. شخصيًا، أتحقق من هذا المنتدى مسبقًا لمعرفة ما إذا كان أي شخص يواجه صعوبات في الوقت الحالي. قد يحدث أن يكون الكود المصدري معطلاً مؤقتًا. أيضًا، أقوم دائمًا بعمل نسخة احتياطية وتنزيلها قبل البدء.
أفهم أن أفضل ممارسة إذا كان وقت التعطل الأدنى مهمًا هي تثبيت حاويتين.
لا أفهم Docker بالكامل (وهذا أقل ما يقال)، ولكني أفهم أنه إذا وجدت نفسك مع منتدى تم ترقيته جزئيًا ولا يعمل، يمكنك بطريقة ما بدء تشغيل الإصدار السابق للترقية أثناء انتظار المساعدة. (بحثت عن “إعادة تشغيل الحاوية القديمة” ولكنني لم أجد المعلومات الدقيقة لهذا.)
./launcher start app يجب أن يعيد الإصدار السابق لإعادة البناء إذا فشل في منتصف الطريق.
على الرغم من أنني أقوم بالتحديث من خلال واجهة المستخدم في معظم الأحيان. بهذه الطريقة لا يوجد وقت تعطل. في بعض الأحيان ستحتاج إلى التحديث من خلال سطر الأوامر، ولكن بشكل عام سيُطلب منك القيام بذلك بعد تحديث مدير docker وقبل محاولة تحديث Discourse نفسه.
عادةً، إذا كان هناك حاجة لإعادة بناء سطر الأوامر، فإن واجهة المستخدم (UX) ستحذرك وترفض إجراء الترقية بنفسها. ومع ذلك، لا يحدث هذا دائمًا.
لدي لوحة تحكم dashboard.literatecomputing.com تقوم بإعادة بناء سطر الأوامر بنقرة واحدة. على الرغم من أنني آمل أن يدفع لي الناس لاستخدامها (والحصول على دعمي)، لفترة محدودة يمكنك الانضمام إلى مجموعة التجربة المجانية واستخدامها مجانًا. إنها تعالج عددًا كبيرًا من المشكلات، مثل إزالة المكونات الإضافية التي تم نقلها إلى النواة، وترقيات Postgres، وإعادة تشغيل الحاوية القديمة إذا فشلت إعادة البناء، وترقية حاوية الويب فقط إذا كانت تثبيتًا من حاويتين، وما إلى ذلك.
نقطة عادلة، أنا أكثر قلقًا بعض الشيء، أقوم بعمل لقطة للنظام قبل وبعد الترقيات، بالإضافة إلى النسخ الاحتياطية لتطبيق Discourse. … ربما يجب أن أتعلم المزيد عن الاستعادة من النسخ الاحتياطية.
لم أستخدم لقطة شاشة بعد… لدي شعور بأنها خيار إضافي التكلفة.
لكنني أشعر أنه من المهم تنزيل هذا النسخ الاحتياطي: إذا تعطل المثيل تمامًا، وإذا تم إلغاء حسابي وقام المضيف بحذف كل ما كنت أستخدمه، فسأظل أمتلك منتدى، وبتنسيق يمكنني استعادته مع أي مضيف أختاره.
لقطات النظام (أعتقد) تتطلب توقفًا عن العمل أثناء أخذها وهي مبالغ فيها تمامًا. نسخة من ملف app.yml وملف النسخ الاحتياطي هي كل ما تحتاجه. إذا كانت النسخ الاحتياطية على S3، فكل ما تحتاجه هو ملف app.yml الخاص بك لتشغيل خادم جديد تمامًا واستعادة البيانات.
تتطلب اللقطات بالتأكيد فترة توقف، وتكلف لقطاتي بضعة دولارات شهريًا للاحتفاظ بها.
أقوم أيضًا بعمل نسخ احتياطية، ولكن بعد أن حاولت استعادة نسخة معطلة من discourse مرة واحدة من نسخة احتياطية تم إنشاؤها في وقت معروف أنه جيد، فإنني أستخدم حزامًا + أزرارًا.
