انقل مثيل Discourse الخاص بك إلى خادم مختلف

[Discourse]

هذا دليل لنقل مثيل Discourse الخاص بك من خادم إلى آخر، بما في ذلك جميع الإعدادات والبيانات. ينطبق هذا الدليل على مثيلات Discourse المستضافة ذاتيًا والتي تستخدم Docker.

مستوى المستخدم المطلوب: مسؤول النظام

يتضمن هذا الإجراء تغييرات في النطاق ونظام أسماء النطاقات (DNS). تأكد من حصولك على حق الوصول إلى كل من الخادم المصدر والخادم الوجهة.

يرشدك هذا الدليل خلال عملية ترحيل مثيل Discourse الخاص بك من خادم إلى آخر، مما يضمن الحفاظ على بياناتك وإعداداتك وتكوينك.

إخلاء مسؤولية أضافه @pfaffman 2025-09-12T05:00:00Z.

هذه التعليمات لا تعمل بشكل جيد الآن لأنك تستخدم https و Let’s Encrypt، مما يتطلب أن يشير نظام أسماء النطاقات (DNS) إلى الخادم الجديد حتى يتمكن من طلب المفاتيح. ما أوصي به هو اتباع نقل موقع Discourse إلى خادم افتراضي خاص آخر باستخدام rsync (ربما باستخدام --exclude postgres* ثم عمل نسخة احتياطية واستعادة قاعدة البيانات من سطر الأوامر.) هذا مفيد لأنه إذا كنت تعرف كيف، يمكنك تعديل نظام أسماء النطاقات المحلي الخاص بك للإشارة إلى الخادم الجديد حتى تتمكن من اختبار عمله بينما لا يزال باقي الإنترنت يرى الموقع القديم.

الملخص

ستقوم بتنفيذ الخطوات الرئيسية التالية في هذا الدليل:

1. عمل نسخة احتياطية لمثيل Discourse الحالي الخاص بك (الخادم المصدر).
2. نقل ملف النسخ الاحتياطي إلى مثيل Discourse الهدف الخاص بك (الخادم الوجهة).
3. استعادة النسخة الاحتياطية على الخادم الوجهة.
4. تحديث إعدادات نظام أسماء النطاقات (DNS) (إذا كان ذلك قابلاً للتطبيق).

تعديل إعدادات نظام أسماء النطاقات (DNS) (عند الضرورة)

إذا كنت تستخدم نفس النطاق للخادم الجديد، فقم بتقليل زمن البقاء (TTL) لسجل DNS الخاص بك مقدمًا. يضمن هذا الحد الأدنى من وقت التوقف أثناء انتشار سجلات DNS المحدثة. إذا كنت ستستخدم نطاقًا جديدًا، يمكن تخطي هذه الخطوة.

تسجيل الدخول وإعداد الخادم المصدر

1. سجل الدخول إلى مثيل Discourse المصدر الخاص بك باستخدام حساب لديه صلاحيات المسؤول.
2. تأكد من أن كل من الخادم المصدر والخادم الوجهة يستخدمان:
   • نفس إصدار Discourse.
   • نفس مجموعة المكونات الإضافية (Plugins).
3. قم بترقية إصدار Discourse على كلا الخادمين عن طريق زيارة /admin/upgrade.

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

إنشاء النسخة الاحتياطية وتنزيلها

1. انتقل إلى /admin/backups على مثيل Discourse المصدر الخاص بك.
2. انقر فوق الزر Backup لإنشاء نسخة احتياطية:
   
   
3. عند المطالبة، قم بالتأكيد بالنقر فوق Yes.
4. بمجرد اكتمال النسخ الاحتياطي، انتقل إلى علامة التبويب Backup files، وحدد موقع النسخة الاحتياطية التي تم إنشاؤها حديثًا.
5. انقر فوق Download لتلقي بريد إلكتروني يحتوي على رابط تنزيل. انقر على الرابط الموجود في البريد الإلكتروني لحفظ ملف النسخ الاحتياطي محليًا.
   
   

قبل المتابعة، راجع ملف app.yml الخاص بك للتأكد من أن أي إعدادات اختيارية، مثل تكوينات شبكة توصيل المحتوى (CDN)، أو المكونات الإضافية المثبتة، أو دعم HTTPS، متسقة بين الخوادم المصدر والوجهة.

استعادة النسخة الاحتياطية على الخادم الوجهة

لاستعادة النسخة الاحتياطية عبر سطر الأوامر، راجع التوثيق ذي الصلة.

1. سجل الدخول كمسؤول إلى مثيل Discourse الوجهة الخاص بك.
2. انتقل إلى /admin/backups/settings، وقم بتمكين الإعداد allow restore.
3. انتقل إلى /admin/backups وانقر فوق علامة التبويب Backup files. قم بتحميل ملف النسخ الاحتياطي الذي قمت بتنزيله سابقًا بالنقر فوق الزر Upload:
   
   
4. بعد اكتمال التحميل، انقر فوق قائمة ⋮ (المزيد من الخيارات) بجوار النسخة الاحتياطية التي تم تحميلها، ثم انقر فوق Restore:
   
   
5. قم بالتأكيد بالنقر فوق Yes عند المطالبة.

ستبدأ عملية الاستعادة. قد يستغرق هذا بعض الوقت اعتمادًا على حجم قاعدة البيانات الخاصة بك. بعد اكتمال العملية، سيتم تسجيل خروجك تلقائيًا.

الانتهاء وتسجيل الدخول

1. سجل الدخول إلى مثيل Discourse الوجهة الخاص بك باستخدام بيانات اعتماد المسؤول الخاصة بك.
2. إذا تم عمل نسخة احتياطية للموقع باستخدام HTTPS، فتأكد من تمكين HTTPS على الخادم الجديد. إذا لم يتم تكوينه بشكل صحيح، استخدم وحدة تحكم Rails لتعطيل الإعداد “force https” مؤقتًا.
3. أعد تمكين أي تكوينات اختيارية عن طريق تعديل ملف app.yml وإعادة بناء المثيل الخاص بك. قد يشمل ذلك:
   • تمكين دعم شبكة توصيل المحتوى (CDN).
   • تثبيت مكونات إضافية إضافية.
   • تعيين تكوينات HTTPS.

المشاكل والحلول الشائعة

فشل استعادة ملف النسخ الاحتياطي

• تحقق من تطابق إصدارات Discourse و PostgreSQL بين الخوادم المصدر والوجهة.

عدم القدرة على تسجيل الدخول بعد الاستعادة (مع تمكين HTTPS)

• استخدم وحدة تحكم Rails لتعطيل force https مؤقتًا عن طريق تشغيل:

  SiteSetting.force_https = false
  

[bayardo.rivas]

هل هذا الدليل لا يزال صالحًا بعد 11 عامًا؟

أقوم بتشغيل Discourse الخاص بي على Ubuntu وأريد ترقية نظام التشغيل من 20.04 LTS → 24.04 LTS بأقل وقت تعطل. إنه موجود في AWS.

[merefield (Robert)]

@bayardo.rivas

هل ما زال صالحًا بعد 11 عامًا؟

هذا متشائم بعض الشيء

@Discourse

آخر تعديل بواسطة @SaraDev 2024-11-21T00:47:52Z

[Jagster (Jakke Flemming)]

أم أن الأمر… واقعي؟ أي بسبب هذه الأنواع من الأشياء:

@Discourse

تحقق من تطابق إصدارات Discourse و PostgreSQL بين الخوادم المصدر والوجهة.

[bayardo.rivas]

من أعتقد أنه من الصواب أن أقلق وأسأل عما إذا كان هذا مثل الوثائق. لقد قمت مؤخرًا بترقية منتدى Discourse الخاص بي وواجهت بعض المشكلات التي أدت إلى تعطل النظام، كنت أقوم فقط بالترقية من إصدار إلى أحدث إصدار. شيء ما عن المكونات الإضافية الجديدة التي أصبحت الآن جزءًا من النظام الأساسي لـ Discourse.

أعتقد أن الانتقال إلى مثيل مختلف بنظام تشغيل أحدث هو تغيير كبير. إذا كنت سأجرب هذا النهج، فسأحب الحصول على كل التعليقات الممكنة.

أقدر أي تعليقات مفيدة. شكرًا.

[merefield (Robert)]

هذا الدليل خارج نطاق هذا التغيير المحدد إلى حد ما.

[bayardo.rivas]

شكرا لتعليقاتك.

[Gunnar (Gunnar Helliesen)]

إذا كنت لا تزال تستخدم Ubuntu 20.04، فهل تستخدم Docker و aufs؟

إذا كنت كذلك، فيجب عليك قراءة هذا قبل المتابعة:

Docker Upgrade Removed AUFS Storage Driver, Killed Discourse

I run a Discourse forum installation on Ubuntu 20.04.6 LTS. The Docker image uses AUFS for storage. Today, I installed upgrades via sudo apt upgrade. Now the Discourse forum is no longer accessible, and it appears to be because a Docker upgrade removed the AUFS storage driver. I see plenty of guides to configuring Docker to use Overlay2 instead, but I don’t see any guidance on how to migrate my existing Discourse installation to use Overlay2, especially now that I can’t start Docker to mount m…

[pfaffman (Jay Pfaffman)]

أعتقد ذلك، على الرغم من أنني لم ألقِ نظرة فاحصة. لا. سيفشل الموقع الجديد في الحصول على المفاتيح من Let’s Encrypt إذا لم يكن نظام أسماء النطاقات (DNS) يشير إليه. لذلك ستحتاج إلى عمل نسخة احتياطية، ونقل النسخة الاحتياطية، وتبديل نظام أسماء النطاقات (DNS) إلى الخادم الجديد، ثم إعادة البناء.

إذا كنت ترغب في تقليل وقت التوقف، فما أوصي به هو نقل موقع Discourse إلى VPS آخر باستخدام rsync. هذا ينسخ مفاتيح SSL الخاصة بك حتى يكون الخادم الجديد جاهزًا عند إعادة البناء.

ما لم تكن قد قمت بالترقية إلى Postgres 15 بالفعل (وربما حتى في هذه الحالة)، فما أوصي به (وما أفعله) هو --exclude postgres*، وإعادة البناء، ثم عمل نسخة احتياطية للموقع الرئيسي واستعادة تلك النسخة الاحتياطية على الخادم الجديد. عند استعادتها، قم بتبديل نظام أسماء النطاقات (DNS). تتضمن تعليمات rsync إيقاف تشغيل قاعدة البيانات حتى تتمكن من نسخ ملفات قاعدة البيانات الخام. هناك بعض الحالات التي لن يعمل فيها هذا بشكل جيد، لذلك في الغالب أقوم بإنشاء نسخة احتياطية لقاعدة البيانات فقط واستعادتها.

تعديل: أضفت هذا إلى المنشور الأصلي.

@Discourse

تم إضافة إخلاء مسؤولية بواسطة @pfaffman 2025-09-12T05:00:00Z.

هذه التعليمات لا تعمل بشكل جيد الآن لأنك تستخدم الآن https و Let’s Encrypt، والتي تتطلب أن يكون الخادم الجديد موجهًا بنظام أسماء النطاقات (DNS) إليه حتى يتمكن من طلب المفاتيح. ما أوصي به هو اتباع نقل موقع Discourse إلى VPS آخر باستخدام rsync (ربما باستخدام --exclude postgres* ثم عمل نسخة احتياطية واستعادة قاعدة البيانات من سطر الأوامر.) هذا ذكي لأنه إذا كنت تعرف كيفية القيام بذلك، يمكنك تعديل نظام أسماء النطاقات (DNS) المحلي الخاص بك للإشارة إلى الخادم الجديد حتى تتمكن من اختبار أنه يعمل بينما لا يزال باقي الإنترنت يرى الموقع القديم.

[nathank (Nathan Kershaw)]

شكراً جاي! لقد تساءلت لماذا واجهت بعض الصعوبات في مسألة عنوان URL / DNS / LetsEncrypt في الماضي (القريب) عند محاولة اتباع التعليمات الواردة في المنشور الأصلي.

لقد نجحت في النهاية باستخدام نطاق فرعي للموقع الجديد، والتأكد من أن موقعي المستعاد على الخادم الجديد كان يعمل، ثم إجراء تبديل سريع لنظام أسماء النطاقات / عناوين URL. لكن كل ذلك كان صعبًا ومؤلمًا بعض الشيء (خاصة إعادة التعيين لاحقًا!).

الآن أصبح من المنطقي سبب حاجتي إلى القيام بكل ذلك. ومن الجيد معرفة أن rsync يمكن أن يتجاوز بعض نقاط الألم.

أعتقد أن بعض التعليمات الواضحة هنا ستساعد الآخرين حقًا، حيث إن الأمر مربك بعض الشيء في الوقت الحالي - ولست متأكدًا من أفضل طريقة للقيام بذلك في المستقبل. هل يمكن دمج إخلاء المسؤولية الخاص بك في المنشور الأصلي كإعادة كتابة (ربما بواسطة @SaraDev؟).

[pfaffman (Jay Pfaffman)]

@nathank

لقد تساءلت لماذا واجهت بعض الصعوبات في مسألة عنوان URL / DNS / LetsEncrypt في الماضي (الأخير) عند محاولة اتباع التعليمات الواردة في المنشور الأصلي.

لهذا السبب اقترحت عدم اتباع هذه التعليمات.

@nathank

أعتقد أن بعض التعليمات الواضحة هنا ستساعد الآخرين حقًا، حيث إنها مربكة بعض الشيء في الوقت الحالي

أعتقد أن تجاهل هذه التعليمات أو حذفها واتباع موضوع rsync الذي ربطته هو ما سيساعد الناس.

هل فاتني شيء؟

[Ethsim2 (Ethan)]

أضيف هنا حالة شاذة (edge case) صادفتها أثناء الهجرة، في حال كانت مفيدة لغيري.

واجهت حالة شاذة متعلقة بـ Let’s Encrypt/SSL أثناء نقل نسخة Discourse مستقلة إلى خادم VPS جديد، لذا قمت بتوثيق خطوات التشخيص والاسترداد بدقة في حال كانت مفيدة لأي شخص آخر يتبع هذا الدليل.

في حالتي، لم يبدأ nginx داخل app لأن كلا ملفي .cer في /var/discourse/shared/standalone/ssl/ قد تحولا إلى ملفات بحجم صفر بايت:

PEM_read_bio_X509_AUX() failed

أدى إعادة البناء إلى محاولة إصدار الشهادة مرة أخرى، وبعد محاولات متكررة وصلت إلى حد معدل إصدار الشهادات (rate limit) الخاص بـ Let’s Encrypt. لم يكن نسخ ملفات الشهادات لا تزال صالحة من الخادم القديم كافياً بحد ذاته، لأن تشغيل app استبدلها مرة أخرى بملفات بحجم صفر بايت.

ما أصلح المشكلة في النهاية كان إيقاف app ونسخ كلا من دليل /var/discourse/shared/standalone/ssl/ العامل و حالة /var/discourse/shared/standalone/letsencrypt/ المقابلة من الخادم القديم، ثم تشغيل الحاوية مرة أخرى.

لقد وثقت التسلسل الكامل هنا:

server_migration_diagnosing_standard_ssl.md

هذه ملاحظات تشخيص/استرداد من هذه الهجرة الخاصة وليست بديلاً عن وثائق الهجرة أو HTTPS الرسمية.

هناك أيضاً موضوع أقدم على Meta يغطي وضع الفشل المتعلق بملفات .cer الفارغة:

Let's Encrypt - ملفات *.cer فارغة

لا أستطيع الاتصال بتثبيت قياسي مدته 30 دقيقة رابط. AWS Lightsail، ذاكرة 2 جيجابايت، Ubuntu 18.04 LTS x64 مع فتح المنفذ :443. المشكلة هي أن ملفات Let’s Encrypt *.cer فارغة. لماذا؟ سجلات nginx root:/var/log/nginx# ls -ltrh -rw-r–r-- 1 www-data www-data 0 Dec 6 05:45 error.letsencrypt.log -rw-r–r-- 1 www-data www-data 0 Dec 6 05:45 access.letsencrypt.log -rw-r–r-- 1 www-data www-data 1.8M Dec 6 08:19 error.log tail error.log PEM_read_bio_X509_AUX() failed (SSL: error:0909006C:PEM r…