أنا على وشك ترقية خادم Discourse الخاص بنا في بيئة الإنتاج (نقوم باستضافته ذاتيًا على EC2 وفقًا لإرشادات التثبيت الرسمية) وأود التأكد من النهج الموصى به.
لا نملك زر الترقية مفعّلًا في واجهة المستخدم، لذا سيتم تنفيذه على مثيل EC2. الآن، أعتقد أن هناك طريقتين رئيسيتين للقيام بذلك:
إعادة بناء خادم EC2 الخاص بنا، والذي سيجلب نسخة جديدة من مستودع discourse_docker على GitHub ويستخدم القوالب الموجودة فيه، أي أن web.template.yml يشير حاليًا إلى صورة الأساس discourse/base:2.0.20260209-1300. ستؤدي هذه الطريقة إلى إزالة الخادم الحالي قيد التشغيل وبدء الخادم الجديد.
تسجيل الدخول إلى خادم EC2 الحالي وتنفيذ الأوامر التالية لإعادة بناء الصورة الحالية وإعادة تشغيل الحاوية:
./launcher rebuild app
لدي سؤالان:
أي نهج يجب استخدامه للصيانة العادية؟
إذا قمنا بتنفيذ أمر rebuild app، فهل يجلب ذلك فرع main من مستودع discourse_docker؟
لقد قرأت موقع https://releases.discourse.org وأستطيع أن أرى أن الإصدار 2026.3.0 لم يُصدر بعد، وفهمي هو أنه لا ينبغي لنا استخدام أحدث إصدارات الفرع الرئيسي (main) من الإصدار في بيئة الإنتاج لأنها لا تزال قيد التطوير النشط.
إذا كنت ترغب في الترقية إلى أحدث إصدار، فيمكنك القيام بذلك يدويًا من لوحة الإدارة.
أما إذا كنت ترغب في الترقية إلى إصدار esr، فكل ما عليك فعله هو تحديد esr في نهاية ملف containers/app.yml:
إذن، هل تعيين الإصدار كـ 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 التالي.