ترقيات الإنتاج - الإجراء الصحيح الذي يجب اتباعه

مرحبًا،

أنا على وشك ترقية خادم Discourse الخاص بنا في بيئة الإنتاج (نقوم باستضافته ذاتيًا على EC2 وفقًا لإرشادات التثبيت الرسمية) وأود التأكد من النهج الموصى به.

لا نملك زر الترقية مفعّلًا في واجهة المستخدم، لذا سيتم تنفيذه على مثيل EC2. الآن، أعتقد أن هناك طريقتين رئيسيتين للقيام بذلك:

  • إعادة بناء خادم EC2 الخاص بنا، والذي سيجلب نسخة جديدة من مستودع discourse_docker على GitHub ويستخدم القوالب الموجودة فيه، أي أن web.template.yml يشير حاليًا إلى صورة الأساس discourse/base:2.0.20260209-1300. ستؤدي هذه الطريقة إلى إزالة الخادم الحالي قيد التشغيل وبدء الخادم الجديد.
  • تسجيل الدخول إلى خادم EC2 الحالي وتنفيذ الأوامر التالية لإعادة بناء الصورة الحالية وإعادة تشغيل الحاوية:
    • ./launcher rebuild app

لدي سؤالان:

  1. أي نهج يجب استخدامه للصيانة العادية؟
  2. إذا قمنا بتنفيذ أمر rebuild app، فهل يجلب ذلك فرع main من مستودع discourse_docker؟

لقد قرأت موقع https://releases.discourse.org وأستطيع أن أرى أن الإصدار 2026.3.0 لم يُصدر بعد، وفهمي هو أنه لا ينبغي لنا استخدام أحدث إصدارات الفرع الرئيسي (main) من الإصدار في بيئة الإنتاج لأنها لا تزال قيد التطوير النشط.

أي مساعدة ستكون موضع تقدير كبير. شكرًا.

إذا كنت ترغب في الترقية إلى أحدث إصدار، فيمكنك القيام بذلك يدويًا من لوحة الإدارة.
أما إذا كنت ترغب في الترقية إلى إصدار esr، فكل ما عليك فعله هو تحديد esr في نهاية ملف containers/app.yml:

params:
  version: esr

ثم أعد البناء.

يرجى التأكد من أن الشبكة تعمل بشكل صحيح.

إعجاب واحد (1)

شكرًا على الرد.

إذن، هل تعيين الإصدار كـ esr يتجاوز صورة الأساس المستخدمة في القوالب؟

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

إذا استخدمنا esr، فكيف يتم تحديثه عند دفع إصلاح حرج؟ مرة أخرى، هل نقوم ببساطة بإعادة البناء عبر برنامج التشغيل/مثيل EC2 جديد على أساس شهري لدمج أي تحديثات على إصدار esr؟

هل قرأت Understanding Discourse release channels و https://meta.discourse.org/t/configure-a-supported-tracking-branch-to-get-discourse-software-updates/17014؟ سأصف الفرق أكثر على أنه الحصول على أحدث التغييرات فورًا، أو استلامها بعد قليل. يمكن أن يكون هذا الخيار الأخير مفيدًا جدًا للتطبيقات المخصصة التي تحتاج إلى تكييف أولي. بخلاف ذلك، سأفضل الوصول إلى أحدث الميزات والإصلاحات. بالطبع، ينطوي هذا على خطر ظهور أخطاء جديدة، لكن الإصدار الذي تم تجميده قبل ثلاثة أسابيع يحتوي أيضًا على أخطاء قد تكون قد تم إصلاحها بالفعل في أحدث إصدار، لكنها عادةً لا تكون كبيرة بما يكفي لتبرير نقلها إلى آخر إصدار.

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

3 إعجابات

إذا كنت تستخدم إصدارًا قديمًا جدًا حاليًا، فقد تستفيد من تشغيل أمر git pull قبل أمر تشغيل المشغل.

إعجاب واحد (1)

آه، لقد فاتني منشور Configure a supported tracking branch to get Discourse software updates.

من الإجابات حتى الآن، أعتقد أنني سأستخدم الفرع release لأننا نقوم بتحديث شهري.

شكرًا جزيلاً على هذا.

إعجاب واحد (1)

إذن، لم تقم بتثبيت discourse-docker بعد.

إعجاب واحد (1)

أستخدم Discourse كمستودع معرفي شخصي، وأعيد بناءه تقريبًا يوميًا :rofl:

ظننت أنني سأضيف بدلاً من إنشاء موضوع جديد.

هل يعاني أي شخص آخر من مشاكل في التحديث من خلال التطبيق أو واجهة المستخدم؟

يبدو أنني أستطيع أحيانًا تحديث docker_manager من التطبيق المحمول، بينما يبلغ discourse نفسه دائمًا عن كونه في حالة “جاري التحديث”، ويجب عليّ الدخول إلى وحدة التحكم للتحديث.

أنا حاليًا على إصدار 2026 04 الأحدث حتى قبل بضع دقائق.

أي توضيح يُقدَّر.

شكرًا لكم!

مرة واحدة، قمت بتحديث لوحة إدارة discourse وفقدت العديد من مرفقات المنشورات. لم أعد أستخدم طريقة التحديث هذه بعد ذلك، واستخدمت rebuild للتحديث من حينها.