إعداد خادم تجريبي

ويكي المجتمع Sysadmins
1

هناك العديد من الحيل التي يمكن أن تساعد عند إعداد خادم تدريجي.

ما هو الخادم التدريجي؟

الخادم التدريجي هو في الأساس نسخة طبق الأصل من موقع إنتاجي. وهو موجود أيضًا على خادم، ويعمل بشكل متطابق. يعمل داخل حاوية Docker، تمامًا كما يفعل موقع Discourse العادي.
وهو موجود لمنحك مكانًا لتجربة الأشياء الخطرة، أو لتجربة الأشياء التي لا يمكنك إخفاؤها بسهولة عن المستخدمين. إنه مفيد جدًا لتجربة الإعلانات باستخدام https://meta.discourse.org/t/official-Advertising-ad-plugin-for-discourse/33734، أو إذا كنت ترغب في القيام بشيء جريء مثل استيراد أو دمج منتدى.
هذا على عكس خادم التطوير، الذي يعمل عادةً في مكان يسهل الوصول إليه (ومعزول) حتى يتمكن المطور من العبث بالكود بأمان.

ماذا أحتاج؟

  1. كل ما تحتاجه لتثبيت قياسي مستضاف ذاتيًا

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

  • وإلا فستحتاج إلى طريقة لنقل الملفات الكبيرة من وإلى الخادم عبر SSH

خطوات

إعداد الخادم الخاص بك كما ترغب

عادةً في خادم Ubuntu افتراضي مستضاف على Digital Ocean، ولكن يمكنك استخدام أي شيء تشعر بالراحة معه.

تثبيت Discourse

عبر هذا الدليل (أو ربما عبر dashboard.literatecomputing.com). أوصي باستخدام بيانات اعتماد بريد إلكتروني “غير مهمة” (لا تحتاج إلى البريد الإلكتروني ولا تريده أن يعمل).

discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub

تأكيد أن التثبيت الخاص بك يعمل:

image
image852×556 44.9 KB

إنشاء حساب مسؤول (إذا لزم الأمر)

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

./launcher enter app
rake admin:create

هذا ليس ضروريًا بشكل صارم باستثناء اختبار التثبيت حيث يمكنك الاستعادة من النسخ الاحتياطي من سطر الأوامر.

تحرير app.yml وإضافة بعض التعديلات

  1. قد ترغب في عمل نسخة من app.yml الأصلي (أسميه app.vanilla.yml) والذي يمكنك الرجوع إليه إذا أفسدت الأمور.

  2. في أسفل قسم env أضف هذه الأسطر:

     ## إعدادات خاصة بالخادم التدريجي
     DISCOURSE_AUTOMATIC_BACKUPS_ENABLED: false
     DISCOURSE_LOGIN_REQUIRED: true
     DISCOURSE_DISABLE_EMAILS: 'yes'
     DISCOURSE_S3_DISABLE_CLEANUP: true
     DISCOURSE_ALLOW_RESTORE: true

  1. إذا كان لديك نسخ احتياطية من S3 (أو ما شابه) معدة، فأضف هذه أيضًا (مع إعداداتك من الموقع الرئيسي)

      ## إعداد S3
  DISCOURSE_S3_ACCESS_KEY_ID: 'your_key'
  DISCOURSE_S3_SECRET_ACCESS_KEY: 'your_secret'
  DISCOURSE_BACKUP_LOCATION: 's3'
  DISCOURSE_S3_BACKUP_BUCKET: 'your_backups_location'
  DISCOURSE_S3_REGION: 'your_s3_region'
  DISCOURSE_S3_DISABLE_CLEANUP: true

    وإذا كنت تقوم أيضًا بتحميلات S3:

      DISCOURSE_ENABLE_S3_UPLOADS: true
  DISCOURSE_S3_UPLOAD_BUCKET: 'your_uploads_location'

  2. قد ترغب في إضافة نفس الإضافات التي لديك على موقعك الإنتاجي أثناء وجودك هناك.

  3. قم بإعادة بناء

    • ./launcher rebuild app

إدارة الخادم التدريجي

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

إيقافه أو تشغيله

إذا تركت خادمك التدريجي “قيد التشغيل” لفترات طويلة، فإنك تخاطر بفهرسته بواسطة Google، وقيام المستخدمين بتسجيل الدخول إليه عن طريق الخطأ. نظرًا لأن بيانات اعتمادهم هي نسخة طبق الأصل من موقعك الإنتاجي، فهذا ممكن جدًا.
طريقة بسيطة للتخفيف من هذين الأمرين هي ببساطة إيقاف تشغيل Discourse:

 ./launcher stop app

وتشغيله مرة أخرى حتى تتمكن من استخدامه:

./launcher restart app

التحديثات

سيتعين عليك التأكد من تحديث / إعادة بناء كل من الخادم التدريجي وموقعك الإنتاجي في نفس الوقت إذا كنت ترغب في ضمان بقاء الأشياء متوافقة من وجهة نظر الإضافات والكود. وينطبق الشيء نفسه على تغييرات app.yml.
إذا كنت لا تستخدم S3، فسيتعين عليك نقل النسخ الاحتياطية يدويًا بين الخوادم. وهي كبيرة!

تهيئة خادم اختبار

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

./launcher enter app
ALLOW_DEV_POPULATE=1 bundle install
ALLOW_DEV_POPULATE=1 rake dev:populate

سيؤدي هذا إلى تهيئة منتدىك ببعض البيانات المزيفة حتى تتمكن من رؤية كيف تبدو الأشياء مع أي سمات وإضافات تريدها. إذا لم تكن قد بدأت منتدىك بعد، فسيمنحك هذا فكرة عما ستبدو عليه الأشياء على الأرجح.

إدارة المصادقة الثنائية

بينما يجب أن تعمل أسماء المستخدمين / كلمات المرور الخاصة بك من موقعك الرئيسي بشكل جيد في الموقع التدريجي، إلا أنها ليست جميلة جدًا مع المصادقة الثنائية. إذا كانت لديك مشكلة، فقم بإيقاف تشغيل المصادقة الثنائية:

./launcher enter app
rake users:disable_2fa[<USERNAME>]
32 إعجابًا
2

ناثان، فكرة رائعة لتجميع هذا الدليل.

ربما فاتني ذلك، ولكن ما هي الخطوة التي تعطل البريد الإلكتروني هنا؟

5 إعجابات
3

سؤال جيد. إن إدخال بيانات اعتماد SMTP غير صحيحة يمنع ذلك تمامًا، ولكن سيكون من المنطقي أيضًا تعطيل رسائل البريد الإلكتروني باستخدام:

DISCOURSE_DISABLE_EMAILS = yes

بالإضافة إلى ذلك، يتم تشغيل هذا تلقائيًا عند إجراء استعادة، لذا فهو ليس ضروريًا حقًا.

8 إعجابات
4

تمت إضافة بعض التعليمات لإيقاف تشغيل التطبيق إلى OP.

إعجابَين (2)
5

صحيح، وغالبًا ما يكون من الجيد أن تكون قادرًا على الحصول على رابط تسجيل دخول، لذلك أوصي بـ

 DISCOURSE_DISABLE_EMAILS = 'non-staff'
6 إعجابات
6

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

فكرت في استخدام استيراد من بيئة الإنتاج ثم تشغيل مهمة إخفاء الهوية على كل منها، ولكن هذا سينتهي بموقع اختبار يبدو مملًا للغاية!

هل يمكنني اقتراح تحويل الموضوع الأصلي إلى ويكي؟

بعض الروابط:

https://hackernoon.com/ruby-on-rails-and-the-complexity-of-fake-user-profiles-made-simple-mf4j31gv

7

لقد جعلتها ويكي.

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

أعتقد أنه يمكنك وضع User.create في حلقة مع قائمة أسماء من مكان ما.

إعجابَين (2)
10

من الواضح أنها ليست من اختصاصي :slightly_smiling_face:، ولكن هل ستكون هذه فرصة جيدة لاستخدام rake dev:populate؟

cd /var/www/discourse
ALLOW_DEV_POPULATE=1 bundle install
ALLOW_DEV_POPULATE=1 rake dev:populate

أعتقد أن هذا سيعمل أيضًا على موقع إنتاجي هو في الأساس بيئة تجريبية/موقع اختبار.

4 إعجابات
11

يبدو أن ذلك ليس عائقًا!

هذا اقتراح رائع:

رمز المهمة: discourse/populate.rake at 1472e47aae5bfdfb6fd9abfe89beb186c751f514 · discourse/discourse (github.com)

إجراءات خاصة بالمستخدم:

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

جميل! في الواقع، فكر شخص ما بالفعل في هذه المشكلة!

تحرير: وللتسلية، جربت هذا على موقع اختبار تم تثبيته مؤخرًا؛ قمت بلصق مهام bundle و rake الخاصة بك وقام بهذا:

root@test2-app:/var/www/discourse# ALLOW_DEV_POPULATE=1 rake dev:populate
OK
لم أكتشف ملف `config/dev.yml` مخصص، أقوم بإنشاء واحد لك حيث يمكنك تعديل الافتراضيات.
يوجد 9 سجلات للمجموعات. إنشاء 6 أخرى.
......
يوجد 3 سجلات للمستخدمين. إنشاء 27 أخرى.
........................
يوجد 4 سجلات للفئات. إنشاء 26 أخرى.
..........................
تم تمكين discourse-solved على الفئة 'Recipes' (12).
إنشاء 30 سجل علامة عينة
..............................
يوجد 6 سجلات للمواضيع. إنشاء 24 أخرى.
........................
root@test2-app:/var/www/discourse#

image
image1123×1048 179 KB

3 إعجابات
13

المشكلة الكبيرة في هذا هي أن مجموعة البيانات الخاصة بك لم تعد تمثل بياناتك الحية.

يحتاج خادم الاختبار إلى أن يكون ممثلاً للبيئة الحية، وإلا فلن تتمكن من اختبار كل شيء قبل الانتقال إلى الإنتاج بأي تغييرات مخطط لها.

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

الألقاب المزدوجة (مع وبدون الواصلة) والأحرف المميزة على سبيل المثال تسببت في الكثير من المشاكل.

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

5 إعجابات
14

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

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

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

إذا تم نشره وتأمينه بنفس طريقة الموقع المباشر، فما هو الخطر المتصور لديهم؟

إعجابَين (2)
16

أنا مع ستيفن. هل العميل أكثر توتراً بوجود بيانات حقيقية على موقع تجريبي، أم بعدم وجود موقع تجريبي يختبر بياناتك الفعلية بالفعل؟

إذا لم تكن تختبر ببياناتك الحية الفعلية من الإنتاج، فلن تعرف ما سيحدث عندما تستخدم البيانات الحية.

وهذا النقاش يبتعد كثيراً عن الموضوع الأصلي. :slight_smile:

إعجابَين (2)
17

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

4 إعجابات
18

بعد مواجهة بعض المشكلات بعد تطبيق المصادقة الثنائية على موقعنا، أضفت هذا:

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

يا إلهي – كان ذلك رائعًا جدًا! بادا-بينغ-بادا-بوم!

أشعر بأنني منتج جدًا بعد استيراد تلك البيانات الوهمية… فجأة، تم ملء منتدى الاختبار الخاص بي تلقائيًا بمجموعة من المستخدمين والمشاركات والعلامات والفئات والمجموعات… يا إلهي!

شكرًا جزيلاً @nathank و @pfaffman و @merefield و @JammyDodger و @Stephen… يا إلهي!

Happy So Excited GIF

5 إعجابات
20

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

21

أفضل طريقة هي تعيين متغير بيئة DISCOURSE_pop3_polling_enabled=false

تحتاج إلى كتابة اسم المتغير بالكامل بأحرف كبيرة، لكن لا يمكنني فعل ذلك على هاتفي.

إعجابَين (2)
22

لقد قمت مؤخرًا بترحيل منتدى الإنتاج الخاص بي إلى S3 و CloudFront. كان لدي بالفعل خادم تدريج منفصل يعمل، ولكنه الآن غير متزامن مع بيئة الإنتاج و S3 لأنني لست متأكدًا مما إذا كنت بحاجة إلى حاوية منفصلة واتصال CDN - لا أرغب بشكل خاص في تحمل تكاليف AWS إضافية لمجرد خادم تدريج. من المفترض أن توجيه كلا الخادمين إلى نفس حاوية S3 غير مستحسن؟ ما هي الطريقة الصحيحة للقيام بذلك؟

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