تصدير نسخة احتياطية من Discourse الحالي (حاليًا، تم تكوين النسخة الاحتياطية للحفظ على S3، لكنني أفهم أن هذا سيكون نسخة احتياطية يدوية للملفات)
استيراد النسخة الاحتياطية إلى Discourse الجديد (يدويًا لأنه لا يمكنه التقاطها من S3 كما أفهم)
أنا عالق قليلاً في كيفية تنفيذ الخطوة 1 نظرًا لوجود بعض القيود التي أملكها: لدي اسم نطاق واحد وأريد الاحتفاظ بنفس اسم النطاق للخادم الجديد، ولا أريد أي توقف (هدفي هو إكمال إعداد الخادم الجديد، استعادة النسخة الاحتياطية، ثم أخيرًا تغيير إدخال DNS ليشير إلى الخادم الجديد، مما يتجنب أي توقف لأن كلا الخادمين سيعملان في نفس الوقت).
كما أفهم، عند إعداد خادم Discourse الجديد، يمكنني نسخ ملف app.yml من الخادم الحالي إلى الخادم الجديد ثم تشغيل discourse-setup. المشكلة التي أراها هنا هي أنه عند القيام بذلك، سيستخدم نفس اسم DNS مثل الخادم الحالي (وهو ما أريده)، لكنني أتوقع مشكلتين أحاول حلها:
لن يقوم lets-encrypt بإنشاء شهادة SSL للخادم الجديد لأن اسم النطاق لا يزال يشير إلى الخادم القديم.
بدون شهادة SSL (إعداد الخادم القديم مضبوط لاستخدام SSL فقط، وهو ما سيتم نقله في app.yml)، لن يبدأ الخادم.
لقد حاولت الاتصال بخادم Discourse باستخدام إعادة توجيه اسم DNS، ولكن إذا لم يتطابق عنوان URL المُدخل مع إعدادات app.yml، فلن يعمل إما NGINX أو Discourse، وستحصل على خطأ في المتصفح أثناء محاولة الاتصال. لذا، بدون واجهة ويب، لا يمكنني بدء عملية الاستعادة.
إذن، كيف يمكنني إكمال إعداد خادم Discourse الجديد باستخدام app.yml الخاص بالخادم الحالي، ثم استعادة النسخة الاحتياطية متبوعة بتبديل DNS؟ أم هل هناك طريقة أسهل للقيام بذلك؟
إذا لم تكن تنوي استخدام نفس وعاء S3، فهناك إعداد مخفي يجبر النسخة الاحتياطية على تنزيل ملفات S3. يمكنك البحث في ملف الإعدادات عن الاسم وتعيينه من وحدة تحكم Rails. هناك موضوع يناقش ذلك، ولكن قد يكون الأسهل البحث في settings.yml.
لا تحتاج إلى تشغيل discourse-setup، فقط انسخ app.yml وأعد البناء.
يمكنك استخدام rsync لنقل شهادات let’s encrypt. في الواقع، يمكنك نسخ /var/discourse بالكامل (ربما باستثناء بعض السجلات وما شابه).
الهدف المثالي هو “الرفع والنقل” (lift n shift)، لكن هذا غير ممكن مع Amazon Lightsail لأنك لا تستطيع استيراد صورة موجودة. لذا نعم، سيكون الأمر باستخدام نفس مخزن S3 بالضبط.
يبدو أن نهجك هو الأقرب إلى “الرفع والنقل”. إذا فهمت ما تقوله، فيمكنني ببساطة ضغط مجلد /var/discourse بالكامل من الخادم الأصلي باستخدام tar/gz، ثم فك ضغطه في الخادم الجديد، متبوعًا بتشغيل أمر discourse start، وإعادة توجيه DNS إلى خادم bee. هل هذا كل شيء؟ هل أحتاج إلى إعادة بناء Discourse في الخادم الجديد؟ وماذا عن Nginx و Docker والاعتمادات الأخرى خارج المجلد؟
شكرًا لك. يبدو أن عملية “الرفع والنقل” لم تكن نظيفة كما توقعت؛ فهناك بعض الفحوصات التي يجب إجراؤها قبل وبعد العملية لضمان سير عملية الرفع والنقل بسلاسة (تم ترقية قاعدة بيانات PostgreSQL من الإصدار 12.0 إلى 13.0، مما علّمني بعض الدروس في عملية الرفع والنقل). إليك دليل خطوة بخطوة للاستخدام المستقبلي من قبل الأشخاص الذين يحاولون الانتقال إلى خادم Amazon LightSail (ذاكرة عشوائية 1 جيجابايت):
الخادم الأصلي
إنشاء نسخة احتياطية إلى S3
cd /var/discourse
./launcher rebuild # الحصول على أحدث إصدار لتسهيل عملية الانتقال
./launcher cleanup # تنظيفه لإزالة البيانات القديمة وتقليل حجم الحزمة
./launcher stop app # عدم القيام بذلك يتسبب في فشل عند محاولة إعادة البناء لاحقًا مع PostgreSQL
tar -zcvf /var/discourse discourse.tar.gz
خادم Amazon LightSail الجديد
تثبيت صورة Ubuntu 20.20 من Amazon (ذاكرة عشوائية 1 جيجابايت)
تكوين vm.overcommit_memory=1 # عدم القيام بذلك قد يتسبب في فشل مع PostgreSQL أثناء إعادة البناء
نقل ملف discourse.tar.gz عبر FTPS/transfer من الخادم الأصلي
tar -zxvf discourse.tar.gz -C /
cd /var/discourse
تعيين UNICORN_WORKERS في ملف app.yml إلى 2 # زيادة هذا الرقم عن 2 مع ذاكرة عشوائية 1 جيجابايت قد يعرض النظام لخطر التبديل والاختناق بسبب النشاط المفرط على القرص
./launcher rebuild
تغيير إعدادات DNS لتوجيهها إلى خادم Amazon الجديد
هل توجد طريقة أسهل لنقل الخوادم (الرفع والنقل) دون الحاجة إلى المرور بعملية إعداد discourse؟
هل تقصد بدون تشغيل discourse-setup أم تقصد بدون بناء الحاوية المطلوبة لتشغيل ديسكورد؟ إذا كنت تقصد الأخير، فهذا ممكن عن طريق دفع الصورة القديمة إلى مستودع يمكن للخادم الجديد استخدامه، لكن هذا ليس شيئًا يمكن للمبتدئ التعامل معه بسهولة.
تعقدت عمليةك بسبب ترقية PG13. ربما كان من الأسهل قليلاً بناء صورة جديدة من الصفر على الخادم الجديد واستعادة النسخة الاحتياطية من الخادم القديم، لكنك ستواجه بعض التعقيدات في الحصول على شهادات Let’s Encrypt للخادم الجديد.
نعم، هذا هو العنصر الوحيد الذي منعني من تشغيل ./discourse-setup على الخادم الجديد ثم الاستعادة من صورة S3 (وكيفية القيام بذلك دون الوصول إلى وحدة تحكم الويب الإدارية، حيث أن DNS سيظل يشير إلى الخادم القديم، وفهمي أن discourse لن يستجيب لعنوان IP في المتصفح). بما أن لدي نظامًا نشطًا وكنت بحاجة إلى تبديل DNS فورًا من النظام القديم إلى الجديد، فإن عدم وجود شهادات Let’s Encrypt كان العقبة الوحيدة أمامي.
إذا كانت هناك طريقة لنقل الشهادات من النظام القديم إلى النظام الجديد، وإكمال ./discourse-setup دون أي أخطاء تتعلق بـ Let’s Encrypt، ثم الاستعادة من نسخة S3 الاحتياطية دون استخدام وحدة تحكم الويب، فستكون هذه طريقة أبسط للقيام بذلك.
إذا قمت بنسخ ملفات yml الموجودة داخل containers، فلن تحتاج إلى discourse-setup (يمكنه ضبط معاملات الذاكرة إذا كانت مختلفة على الخادم الجديد، ولكن يمكنك القيام بذلك لاحقًا). ما عليك سوى تشغيل ./launcher rebuild app.
حسنًا، أظن أنني أفهم ما تقصده، ولكن للتأكد، دعني أعيد صياغة فهمي.
في الخادم الأصلي، كان مُعدًا لنسخ بيانات discourse احتياطيًا إلى S3 (وهي الإعدادات ومحتوى الموقع).
بنسخ ملفات yml من مجلد containers، سيتم نقل جميع إعدادات الخادم الأصلي إلى الخادم الجديد، لذا لم يعد عليّ الآن تنفيذ أمر discourse-setup؛ بل إن تنفيذ ./launcher rebuild app سيستخدم إعدادات الخادم الأصلي لتحميل أحدث صورة وتكوين discourse.
الآن، هناك أمران معلقان:
كيف يمكن نقل شهادات lets encrypt؟ (بما أن DNS لا يزال يشير إلى الخادم الأصلي، فلا يمكن إعادة إنشاء الشهادات، وأظن أن هذا يجب أن يتم قبل تنفيذ ./launcher rebuild app)
كيف يمكن استعادة discourse (الإعدادات + المحتوى) من النسخة الاحتياطية في S3 بعد إعادة البناء؟ وبما أن DNS لا يزال يشير إلى الخادم الأصلي، هل هناك طريقة للوصول إلى واجهة الويب الإدارية لـ discourse باستخدام عنوان IP أو localhost؟ أم يمكن استعادة النسخة الاحتياطية من S3 عبر وحدة التحكم (console)؟
شكراً على الخطوات المفصلة، لقد اضطررت للقيام بشيء مشابه، الانتقال إلى مضيف جديد.
بما أن الموقع كان يعمل، لم أكن أرغب في المرور عبر النسخ الاحتياطي، لذلك اتبعت الخطوات هنا.
لقد نجح الأمر تقريبًا ولكنه فشل في إعادة البناء على المضيف الجديد.
اتضح أن تعيين UID/GID لم يكن مطابقًا تمامًا على المضيفين، لذلك عند بدء تشغيل Postgres كان سيتعطل بسبب ملكية غير صحيحة لمجلد البيانات.
هناك تفصيل إضافي لسيناريو هذه المشاركة، وهو أن الحاوية لم يتم بناؤها، لذلك لا يعمل ./launcher enter app في هذه المرحلة. نظرًا لأن إعادة البناء ستستغرق وقتًا طويلاً، تمكنت من استخدام docker ps للحصول على اسم الحاوية التي تقوم بالبناء، ثم الدخول إلى الحاوية:
.