نقل Discourse إلى خادم جديد بدون إعداد واجهة الويب أولاً

الدعم تثبيت
1

Let’s say I want to move my Discourse site from one Amazon EC2 instance (e.g. t2.micro) to a larger instance (e.g. t2.medium), what is the correct procedure for this?

The only option I know about is:

  1. Backup the existing site
  2. Install Discourse on the new server
  3. Configure Discourse using temporary values
  4. Restore the backup

However, I’m thinking that the smart people at Discourse thought about this situation and there’s a way to restore a backup on a new installation without step 3.

Scouring the site, I wasn’t able to find a definitive answer.

I did look at Move your Discourse Instance to a Different Server, but the instructions seem to imply that a generic installation is already active on the target server and that you can log in and immediately perform a restore.

2

I think what you want to know is that you can copy the backup to the new instance and then restore from the command line like

cd /var/discourse
./launcher enter app
discourse enable_restore
discourse restore

The last command will give you a list of available backups and you can copy-and-paste to start the restore.

3

@pfaffman thank you for helping with this question, there’s one spot where I’m still a bit unclear.

On the new server (assuming the prerequisites are already installed), after cloning the Discourse repository, do I still need to run discourse-setup? I don’t believe it’s possible to issue the commands

until after setup completes. Or am I incorrect? If I am correct, this is the part I’m referring to, you have to essentially provide a set of default values before you are able to perform a restore.

4

Yes, you still need to set up Discourse, but you can just use the same app.yml that you use on the old instance (or type them in to discourse-setup if that’s easier for you). But you have to have all of those values for a running Discourse anyway, so it’s not “temporary” values, but the values.

The command-line restore saves the you time of creating a temporary admin account that you’d use just to restore the backup.

5

عند استخدام سطر الأوامر، تسير كل الأمور بسلاسة أثناء عملية الاستعادة، لكن في النهاية أواجه الخطأ التالي:
حدث خطأ أثناء إشعار المستخدم.

هل لديك أي فكرة عما يجب عليّ فعله؟

كما أود أن أعرف: هل من الممكن إعداد الخادم الجديد ببساطة عن طريق نسخ مجلد /var/discourse/ من الخادم القديم إلى الخادم الجديد، بدلاً من استعادة نسخة احتياطية؟

6

يبدو وكأنه خلل

نعم. يمكنك فعل ذلك.

7

عذرًا لإعادة فتح موضوع قديم / تم حله، لكنني اعتقدت أن هذا التوضيح يجب أن يكون هنا بدلاً من موضوع جديد.

إذا كنت أرغب في نقل تثبيت discourse مستقل يعمل من الخادم القديم إلى الخادم الجديد، وبافتراض أن docker مثبت ويعمل على الخادم الجديد، فهل يمكن أن يكون الأمر بسيطًا مثل:

الخادم القديم:

cd /var/discourse
./launcher stop app

الخادم الجديد:

rsync old-server:/var/discourse /var
cd /var/discourse
./launcher rebuild app

ثم تغيير نظام أسماء النطاقات (DNS) ليشير اسم النطاق الخاص بالمنتدى إلى الخادم الجديد.

؟؟؟

8

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

يمكنك نقل النسخة الاحتياطية باستخدام scp والاستعادة من سطر الأوامر.

9

مرحباً شكراً لك. لن يكون هناك أي تغيير في اسم المضيف / المجال. أنا ببساطة أنتقل إلى خادم جديد وأكبر. هل ستنجح هذه الاستراتيجية البسيطة في هذه الحالة؟

تعديل: أقوم بتحرير مشاركتي الأصلية أعلاه لمحاولة توضيح أن اسم المضيف للمنتدى لن يتغير - مجرد خادم جديد. آسف على الارتباك.

10

حسناً. ربما يجب أن يكون هناك قسم howto.

نعم، يمكنك استخدام rsync لنسخ /var/discourse إلى الخادم الجديد (وهذا سيشمل شهادات SSL)، وإعادة البناء، ثم تبديل نظام أسماء النطاقات (DNS) وسيعمل كل شيء بشكل صحيح.

11

إذا كنت تقوم بتغيير مواصفات الخادم، فستستفيد من تشغيل discourse-setup - فهو يتعامل مع جوانب معينة من التوسع (عمال unicorn ومخازن قواعد البيانات المؤقتة المشتركة) وسيقوم تلقائيًا بتكوين app.yml. مجرد نسخ المجلدات لن يحقق ذلك.

12

شكرًا ستيفن،

أخطط لتعديل تلك المعلمات يدويًا في app.yml. سأقوم بتشغيل discourse بالتوازي مع عدد قليل من التطبيقات الأخرى المستندة إلى docker على نفس الخادم (كما أفعل الآن)، ولذلك قمت بضبطها على مستوى استخدام موارد أقل قليلاً من المكان الذي سيضعها فيه الإعداد بناءً على مواصفات الخادم إذا كان discourse هو التطبيق الوحيد قيد التشغيل.