تنبيه سريع: أنا جديد نسبيًا في بناء بيئة VPS من الصفر، لكن لدي خبرة كافية في استضافة الويب (خاصة الاستضافة المشتركة والخوادم المخصصة المدارة) لأعرف ما أفعله وأستوعب الدروس التعليمية.
على الرغم من ذلك، أستخدم حاليًا أرخص خادم سحابي (Droplet) من DigitalOcean للتجربة. أنا هاوٍ، ولا أتوقع وجود حركة مرور ضخمة، وأحاول فقط إنشاء نسختين ستوفران صفحة رئيسية من نوع ما (غالبًا WordPress) ومنتدى Discourse مصاحب — نسخة واحدة لتصميم الألعاب والأخرى لمجتمع صناعي المحتوى الخاص بي.
أدرك أن Discourse و Apache لا يتوافقان جيدًا بسبب قرار Discourse باستخدام المنفذ 80، وأدرك أيضًا أن هناك حلولًا بديلة، لكن يبدو أن هناك أشكالًا مختلفة بنتائج غير مؤكدة ولا توجد أي إشارة رسمية من Discourse تقول “نعم، هذا يعمل”.
أنا مرتبك قليلاً حول سبب تصميم منصة رائعة كهذه لتكون معيقة لإدارة خادم ويب بجانبها، لكن تجربتي مع البرنامج حتى الآن جعلتني مهتمًا بما يكفي لإيجاد طريقة لجعلها تعمل. لقد رأيت أن تكامل WordPress موجود ويتم الترويج له في صفحة الميزات، لكن مرة أخرى، يبدو أن Discourse لم يُصمم ليكون إلا نظامًا قائمًا بذاته.
هل هناك أي نصيحة أو مدخلات ممن واجهوا نفس المعضلة؟ شكرًا!
ومع ذلك، يبدو أن هناك عددًا كبيرًا من المشكلات في جعله يعمل بشكل صحيح، خاصة فيما يتعلق بـ SSL.
هل سيكون من الأسهل تشغيل قطرتين (Droplets)، واحدة للموقع الإلكتروني والأخرى خصيصًا لـ Discourse؟ أعتقد أنني يمكنني ببساطة تغيير سجل DNS للنطاق الفرعي ليشير إلى قطرة Discourse، وهذا يجب أن يحل المشكلة. فقط أجد أنه غريب تشغيل خادمين لمنتدى واحد.
أقول هذا بكل احترام، لكن Discourse، كما هو مُعدّ من الصندوق، يتطلب عمليًا خادمًا مخصصًا له. استخدام وكيل عكسي لتشغيل خادم ويب بالتوازي مع Discourse على نفس الخادم الافتراضي (VPS) هو أمر غير مضمون، كما يتضح من التعليقات والشكاوى الأخرى، وقد يعمل SSL أو لا يعمل. كما أنه شبه مستحيل تشغيل نسختين من Discourse على نفس الخادم. كل هذا، بالنسبة لي، يُعدّ عائقًا. لا يوجد أي برنامج منتدى آخر، بما في ذلك المنصات المتقدمة مثل XenForo أو Invision، يتطلب هذا المستوى من الجهد مع هذا القدر من عدم اليقين. إنها باقات باهظة الثمن، لذا أفترض أنك تحصل على ما لا تدفع ثمنه مع Discourse. كمستخدم جديد يواجه كل هذه العقبات، يبدو لي أن Discourse صُمم دون مراعاة أي شيء آخر (أي المواقع الإلكترونية).
وبالنسبة لما يُقال، وكما أشرت في منشوري الأصلي، استخدمت نشرًا بنقرة واحدة لـ Discourse. لذا، سأحتاج إلى عكس كل شيء لمحاولة تشغيل Apache (أو Nginx إذا لم أستطع العثور على دليل تعليمي) على نفس الخادم. إذا كنت سأستخدم Discourse كمنصة المنتدى الأساسية لدي، فلست مهتمًا بتشغيل خادمين لمجتمع واحد. هذا مجرد أمر غير منطقي.
@Benjamin_D المشكلة التي أواجهها هي أن جميع الدروس المتاحة هنا تفتقر إلى جانب ما من بيئتي الحالية. هناك درس لـ Apache لكنه يستخدم CentOS. أما أنا فأستخدم Ubuntu. والدرس الآخر لكane York يستخدم Nginx، ولكن كما ذكرت، أنا أستخدم Apache.
أنا لا أقوم بأي شيء معقد بشكل مفرط. أنا أستخدم DigitalOcean وLinux مع Ubuntu 18.04، وأستضيف كل شيء على droplet (دون استخدام تخزين تابع لجهة خارجية)، وما إلى ذلك. أنا أستخدم Mailgun كحل للبريد، لكنني لا أعتقد أنه يوفر صندوق ورود، وهو أمر مقبول في الوقت الحالي.
في الواقع، يُعدّ Discourse أفضل برنامج مفتوح المصدر لبناء المنتديات والمجتمعات على كوكب الأرض في الوقت الحالي (من وجهة نظري)، ولأسباب عديدة، وإليك بعضًا منها:
Discourse مفتوح المصدر ويتمتع بمجتمع قوي وفريق تطوير أساسي ذكي جدًا (وقادر).
تم تصميم Discourse للعمل داخل حاوية Docker في بيئة الإنتاج، وهو ما يحمل العديد من المزايا:
يمكن نشر Discourse بسهولة في وضع standalone mode دون الحاجة إلى خادم ويب أو قاعدة بيانات خارجية.
يمكن نشر Discourse بسهولة في وضع multi-container mode مما يوفر موثوقية أعلى وترقيات سلسة.
يمكن أيضًا نشر Discourse في تكوينات عالية التوفر باستخدام Docker Swarm و Kubernetes، حيث يمكن لـ Discourse التوسع للأعلى والأدنى “حسب الطلب”.
يُعدّ نسخ احتياطي لـ Discourse واستعادته أمرًا سهلاً. يمكننا أخذ النسخة الاحتياطية القياسية لـ Discourse المتاحة خارج الصندوق (OOTB) واستعادتها في أي مكان في العالم داخل حاوية Docker جديدة ونظيفة.
يعمل Discourse بسهولة خلف خوادم وكيل عكسي مثل Apache2 و nginx. وهذا أيضًا يحمل العديد من المزايا، وإليك بعضًا منها:
يمكن تشغيل Discourse على خادم ويب موجود، سواء كان nginx أو Apache2، مع بذل جهد قليل سواء في منافذ TCP/IP المكشوفة عبر Docker أو في سوكيتات نطاق UNIX.
تشغيل التطبيقات القائمة على الويب خلف وكلاء عكسيين هو أمر راسخ. هذا الإعداد ليس خاصًا بـ Discourse، لكن Discourse سيوفر الدعم.
إعداد SSL أمر بسيط جدًا خلف وكيل عكسي ويمكن أن يكون بسيطًا مثل `certbot -d my.great-discourse.site’ باستخدام خدمة LETSENCRYPT المدعومة والمجانية.
تم توثيق Discourse بالكامل، تعديلاً بتعديل، على GitHub، لذا يمكن لأي شخص متابعة تغييرات الكود.
يتبنى Discourse نموذج عمل تدريجي، وهو ما يحمل بعض المزايا الرئيسية، بما في ذلك:
Discourse، البرنامج الأساسي والعديد من الإضافات الرائعة والموضوعات والمكونات، مجانية.
يوفر Discourse دعمًا مجانيًا يشمل دعم التكوين القياسي، في meta.
يوفر Discourse استضافة تجارية لأولئك الذين لا يرغبون في الاستضافة الذاتية أو يفضلون أن يكون الأمر أكثر “تفاديًا للتعامل المباشر”.
يشجع Discourse الاستشارات التجارية وتطوير الإضافات داخل مجتمعه، مما يخلق نظامًا بيئيًا تجاريًا قابلًا للاستمرار.
هناك المزيد، لكنني أريد إنهاء هذا الموضوع!
هل نوافق (هل نوافق نحن) على كل قرار يتخذه فريق Discourse الأساسي؟ وهل يوافقون على كل أفكارنا (أو أفكاري) واقتراحاتنا؟
لا، بالطبع لا؛ ولا ينبغي لهم، ولا لنا، ولا لي. نحن أحرار في الاقتراح، وإرسال اقتراحات الكود، وطلبات السحب (PRs)، وسيتعامل فريق Discourse الأساسي مع هذه الاقتراحات بعقل منفتح.
لكن في نهاية المطاف، يجب على الفريق الأساسي الحفاظ على تحرك مجتمع Discourse في اتجاه متماسك، وهو أمر ليس سهلًا عندما يرغب مئات الأشخاص من ثقافات مختلفة في تكوين مختلف ولديهم أولويات ونماذج عمل وأفكار مختلفة.
وبعبارة أخرى، لا يوجد شيء يجب “تجنبه” (كلمات عنوان موضوعك) من Discourse، خاصة إعداد الوكلاء العكسيين وإتقان Docker. الكثيرون (بما في ذلك أنا) يتجهون نحو Kubernetes بسبب Discourse، ليس فقط لـ Discourse بل لتطبيقات الويب الأخرى أيضًا.
Discourse هو “أبعد شيء” عن “عقبة” (مرة أخرى، كلماتك، وليس كلماتي)؛ وبسبب اعتماده على الحاويات، وبالفعل، فإن “السماء هي الحد” لكيفية نشر مسؤولي الأنظمة ذوي الخبرة لـ Discourse في بيئات إنتاج قابلة للتوسع للغاية؛ وهو أيضًا بسيط بدرجة كافية بحيث يمكن للمبتدئين نشره بسهولة في وضع standalone.
إذا فهمتُ بشكل صحيح، فإن ما تريده هو أن يستمع nginx ويعيد توجيه أحد النطاقات الفرعية إلى Apache من جهة، ونطاقًا فرعيًا آخر إلى الحاوية التي تعمل فيها Discourse من الجهة الأخرى (عن طريق إعداد المنفذ المناسب في ملف app.yml، أو باستخدام قالب web.socketed)، أم أنك تستخدم Apache كوسيط؟
يُستخدم nginx بدلاً من HAProxy في دليل CentOS، أعتقد ذلك
قريب لكن ليس تمامًا. للتكرار، أنا أعمل على نظام Linux مع Ubuntu 18.04. أستخدم Apache لاستضافة موقع HTML قياسي (وستكون WordPress في المستقبل)، وقد قمت بتثبيت Discourse تحت نطاق فرعي. كل ما أحتاجه هو معرفة كيفية إعداد وكيل عكسي (وفقًا لهذه الدروس) يعيد توجيه حركة المرور من المنطقتين 80 و443 إلى منافذ جديدة، نظرًا لأن Apache يستخدم بالفعل هاتين المنطقتين. لست مهتمًا باستخدام Nginx لأنني لا أملك خبرة معه، ولا أرغب في دمجه مع Apache مما سيجعل إعداداتي أكثر تعقيدًا.
لست مطورًا متقدمًا. أنا مجرد شخص لديه فهم سلس للواجهة الأمامية، وفهم أساسي للوحات التحكم، وفهم محدود لـ SSH، ولا أفهم تقريبًا أي شيء آخر (ولهذا السبب أعتمد على الدروس).
هدف النهائي هو امتلاك نطاقين لكل منهما صفحة رئيسية خاصة به، مع وجود عدة نسخ من Discourse (واحدة لكل موقع). أمور بسيطة.
إذا كنت تريد أن تكون حياتك سهلة، فقم بتشغيل Discourse على قطرة (Droplet) خاصة به. لا يمكنك حقًا تشغيل Discourse وApache على قطرة بحجم 1 جيجابايت، لذا فإن استخدام قطرتين بحجم 1 جيجابايت لا يكلف أكثر.
@pfaffman لم يكن نيتي البقاء على أصغر droplet أبدًا، بل أستخدمه فقط أثناء محاولتي إعداد كل شيء. لا فائدة من دفع سعر ساعي أعلى أثناء التجربة.
السبب الوحيد الذي يجعلني غير متحمس لتشغيل droplets اثنين هو أنني سأحتاج على الأرجح إلى نقل 3-4 نطاقات مختلفة إلى DigitalOcean. لا أريد دفع ثمن 6-8 droplets. هذا جنون.
إذا كنت ترغب في أكثر من 3 مواقع Discourse، فمن المرجح أن تحتاج إلى استكشاف إعداد المواقع المتعددة. لدي إعداد أقوم به باستخدام Traefik، رغم أنني أبحث حاليًا عن بوابات عكس أخرى.
