استخدم CloudPanel لإدارة مواقع متعددة مع Discourse

يمكنك الانتقال مباشرة إلى دليلي التعليمي خطوة بخطوة هنا…

على خادمي المخصص (Hetzner)، قمت بتثبيت نسخة جديدة من Discourse (وهذا هو الشيء الوحيد الموجود على الخادم في هذه المرحلة.)

الآن أريد استخدام CloudPanel كوكيل عكسي، حتى أتمكن أيضًا من استخدام الخادم لاستضافة مدونات Ghost ومواقع Wordpress لبعض عملائي.

من خلال قراءة هذا الدليل، وبعد دراسة المنشورات الأخرى أدناه أيضًا، يبدو أن هذا ممكن.

لكنني أواجه صعوبة في منحنى التعلم الخاص بي حول الوكلاء العكسيين.

يمكنني بسهولة تثبيت وإدارة مواقعي باستخدام CloudPanel.

لكنني لست واضحًا بشأن الترتيب أو الإجراء الصحيح لجعل CloudPanel يعمل بشكل جيد مع Discourse.

أود توثيق الإجراء هنا في هذا المنشور.

هل يمكن لأي شخص أن يرشدني خلال هذا؟

اتبع أحد هذه الأدلة أولاً لنقل discourse إلى منفذ آخر وإزالة قوالب ssl و let’s encrypt وإعادة البناء. ثم أخبر الوكيل العكسي الخاص بك باستخدام هذا المنفذ.

3 إعجابات

ماذا لو قمت بتثبيت CloudPanel أولاً، وأنشأت وكيلًا عكسيًا في الواجهة…


… و/أو في محرر Vhost…

… هل يمكنني بعد ذلك تثبيت Discourse؟

أم، هل من الضروري أو المفضل بطريقة ما تثبيت Discourse أولاً؟

أود تقديم الخطوات للطريقة الأكثر بساطة/بديهية (للمبتدئين الآخرين مثلي :slight_smile: )

لا يهم. طالما أن

  • لا يستخدم Discourse المنافذ 80/443 لأن التعارض سيؤدي إلى تعطل وكيلك العكسي
  • لا يستخدم Discourse بروتوكول SSL ولكن يعرض المنفذ 80 لهذا المنفذ الذي يستخدمه الوكيل العكسي في الواجهة الخلفية

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

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

إنها ليست إعدادًا للمغفلين. سيتعين عليك فهم كيفية عمل الوكيل العكسي وكيفية تكوين discourse يدويًا. لن يكون الأمر بسيطًا أو بديهيًا.

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

إعجابَين (2)

لقد تم قضاء ساعات طويلة جدًا في جعل هذه التعليمات تعمل للأشخاص الذين لا يعرفون شيئًا عن إدارة النظام.

@pfaffman آمل أن أتمكن من المساعدة في تقليل تلك الساعات بالنسبة لك في المستقبل!

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

هل containers/app.yml ملف يتم إنشاؤه بواسطة المثبت؟ (لا أجده في المستودع.)

لقد قمت بتحرير ملف standalone.yml وأعدت تسميته إلى app.yml

إذا وضعت هذا الملف في containers/ ثم قمت بتشغيل ./discourse-setup، فهل سينجح ذلك؟

(بافتراض أنني قمت بتكوين الإعدادات بشكل صحيح في ملف app.yml الخاص بي)

إنه كذلك.

بصفتك مستخدمًا جديدًا نسبيًا لـ Discourse، فإن الطريقة الصحيحة للقيام بذلك تبدو كالتالي:

  • تعطيل وكيلك العكسي مؤقتًا.
  • تثبيت Discourse مع تعطيل SSL/Lets Encrypt
  • التحقق من تثبيت يعمل على :80
  • تغيير منفذ Discourse إلى 81 أو منفذ آخر غير قياسي، أو الأفضل من ذلك استخدام مقبس.
  • تشغيل الوكيل العكسي مرة أخرى، وتكوينه مقابل تثبيت Discourse (بما في ذلك تغليف HTTPS)
  • تمكين force_https

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

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

لا يمكنك استخدام discourse-setup للإعداد الخاص بك. إذا قمت بتعديله، فقم بتشغيل

./launcher rebuild app

إعجابَين (2)

معجزة المعجزات – لقد فعلناها! شكراً جزيلاً لمساعدتكم! سأوثق الإجراء في منشور الموضوع أعلاه.

إعجابَين (2)

حسنًا، لقد علقت في شيء (صغير، أعتقد)…

لإنشاء مثيل Discourse ثانٍ، أقوم بإنشاء وتحرير ملف app2.yml، وملف server_name.conf لـ Discourse الثاني، وتغيير DISCOURSE_HOSTNAME و server_name.

ولكن بعد ذلك… كيف أقوم ببناء التطبيق الثاني؟ لقد حاولت:

service nginx restart

./launcher stop app

./launcher rebuild app2

و

./discourse-setup (لقد استخدمت ./discourse setup لتثبيت المثيل الأول ثم عدت وقمت بتحرير app.yml، وقد نجح الأمر في المثيل الأول.)

أدت هذه الإجراءات إلى ظهور Discourse على عنوان URL الثاني، ولكنه يبدو أنه يحصل على بيانات من المثيل الأول.

أنا لا أفهم شيئًا. ما هي الطريقة الصحيحة لبناء الموقع الثاني على النطاق الثاني؟

إعجابَين (2)

هل تم تكوين الوكيل العكسي الخاص بك للاستماع إلى النطاق الثاني وتوجيه حركة المرور إلى منفذ مختلف؟

إعجابَين (2)

تحتاج إلى تغيير الدليل الذي يستخدمه حيث يقول /var/discourse/standalone إلى شيء مختلف (standalone2؟).
قد ترغب في استخدام إعداد حاويتين بحيث تقوم بتشغيل نسخة واحدة فقط من postgres (أعتقد أن تكوين متعدد المواقع باستخدام Docker يحتوي على بعض التلميحات)، ولكن إذا كان لديك الكثير من ذاكرة الوصول العشوائي فقد لا تهتم.

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

واو. لم أكن لأكتشف ذلك بنفسي أبدًا. أنت بطلي لهذا اليوم.

ما أفعله هنا هو (لعميل) بناء نموذج أولي لنظام نشر Discourse متعدد الاستخدامات للمبدعين، ودمج Ghost مع Discourse.

أنا مطور واجهة أمامية، وأحتاج الآن إلى تعلم إدارة النظام بالكامل.

لذلك أحتاج إلى بناء كل من مواقع متعددة وحاويات منفصلة.

هذا هو إعداد الخادم الخاص بي:

  1. خادم مخصص على Hetzner (6 أنوية معالج، 64 جيجابايت ذاكرة وصول عشوائي و 2x512 جيجابايت NVMe)

  2. خادم افتراضي خاص على Contabo (8 أنوية معالج، 30 جيجابايت ذاكرة وصول عشوائي و 200 جيجابايت NVMe)

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

ليس لدي أي فكرة عن ذلك، ولكن إذا كنت تعتقد أنت والآخرون أن برنامجك التعليمي موثوق به، فلا تتردد في إنشاء #documentation:sysadmin how-to advanced-setup جديد وأي علامات أخرى تعتقد أنها مناسبة :slight_smile:
(قبل أن يتم حذف إجابتك تلقائيًا في غضون شهر :p)

3 إعجابات

حسنًا، نعم. لذلك بالنسبة لهذا المثيل الثاني، نجح الأمر (بعد إنشاء موقع جديد في CloudPanel):

  1. إنشاء وتعديل ملف app2.yml يدويًا، وتغيير كل مثيل في هذا الملف من standalone إلى standalone2

  2. تغيير standalone إلى standalone2 أيضًا في ملف Vhost

  3. تشغيل ./launcher rebuild app2

أعتقد أنني قمت أيضًا بمسح جميع ذاكرات التخزين المؤقت لـ Cloudflare، وأعدت تشغيل nginx، ثم أعدت تشغيل الخادم أيضًا.

شكرًا لك مرة أخرى على مساعدتك.

إعجابَين (2)

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.