أنا أبحث في Discourse كخيار محتمل لإنشاء منتدى في مشروعي.
أنا مندهش قليلاً من مدى تعقيد تشغيل هذه البنية فعليًا.
على GitHub، هناك هذا الدليل الإرشادي — وهو يتطلب خادم بريد SMTP ونطاقًا.
رأيت أيضًا دليلًا آخر يشرح تثبيت البنية مباشرة على المضيف. وأفضل الاعتماد على Docker لإعداد جميع هذه التبعية
ما أربكني أيضًا هو أن الدليل الأول ركّز بشدة على ضرورة وجود خادم SMTP وDNS، بينما لا يذكر هذا الأمر في الدليل الآخر على الإطلاق.
تراءى لي أنه نظرًا لأن كل شيء مُعبّأ في حاويات Docker، فيجب أن أتمكن من تشغيل Docker Compose ببساطة لتشغيل حاويات Discourse وقاعدة البيانات (وكما أرى فهي PostgreSQL) (+ ربما بعض الحاويات الأخرى مثل التخزين المؤقت إذا كان Discourse يحتاجها). ثم، في بيئة الإنتاج، سأستضيفه على Kubernetes (يبدو أن هذا ليس بالأمر السهل كما قرأت في بعض المواضيع).
هل تريد تثبيتًا للتطوير أم للتشغيل الفعلي؟ إذا كان الأمر يتعلق بالتشغيل الفعلي، فراجع التثبيت القياسي الرسمي لـ Discourse. يمكن تشغيل النظام تحت بيئة k8s، لكنه ليس مباشرًا، حيث ستحتاج إلى استخدام ./launcher لبناء الحاوية. كما أن إجراء ترقية كاملة دون توقف يتطلب عدة خطوات ليست واضحة على الفور. إذا كنت تريد أن يكون الأمر سهلاً، فما عليك سوى إنشاء آلة افتراضية (وهو أسهل قليلًا إذا كانت تعمل بنظام Ubuntu أو Debian).
نعم، تحتاج إلى القدرة على إرسال البريد الإلكتروني للتشغيل الفعلي. أما للتطوير، فمن الواضح أنك لا تحتاج إلى ذلك.
@merefield شكرًا على رابط Docker. هذا يعمل، وهو قريب من ما تخيلت أن العملية ستبدو عليه. مع ذلك، من الغريب قليلاً أن كل شيء مُعبَّأ في حاوية واحدة. ونعم، العملية بطيئة. ما فاجأني هو أنه عندما أنفذ git clone على discourse ثم cd discourse، يصبح قذفي (shell) بطيئًا جدًا -第一次 أرى ذلك . يجب أن يحتوي هذا المستودع على عدد كبير من الملفات، أو شيء من هذا القبيل، رغم أنني لست متأكدًا من سبب تأثير ذلك على قذفي.
@pfaffman أود أيضًا تجربة التثبيت الأقرب إلى بيئة الإنتاج، لأتخيل كيف تبدو العملية. لا بأس بالتثبيت على آلة افتراضية (VM). ومع ذلك، ماذا عن خادم SMTP والنطاق؟ الدليل صارم جدًا بشأن هذين العنصرين ويقول إنه يجب أن أمتلكهما.
وهذا مقبول أيضًا، لكن الأمر يتعلق بأنني لا أفهم بعض الأشياء تمامًا:
لماذا النطاق ضروري فعليًا؟ لماذا لا يكفي localhost؟
هل يجب أن يشير خادم البريد إلى نفس النطاق الذي أستخدمه لـ Discourse؟
يتحدث الدليل أيضًا عن النطاقات الفرعية - لماذا نطاق فرعي؟ أي أنني أقوم بإعداد آلة افتراضية على Azure، ولديها نطاق DNS مُعيَّن (مثل myvm.westeurope.cloudapp.azure.com) - أليس هذا النطاق كافيًا؟
هذا للاستخدام الإنتاجي ويتطلب بروتوكول HTTPS، لذا ستحتاج إلى اسم نطاق. اسم نطاق Azure سيعمل.
لا يشترط استخدام نفس اسم النطاق لخادم البريد كما هو مستخدم في اسم المضيف. منذ فترة، قمت بتعديل discourse-setup ليطلب عنوان البريد الإلكتروني للإشعارات.
الاسم الثانوي يعني ببساطة عدم استخدام x.com، بل استخدام y.x.com. هذه ممارسة راسخة إلى حد كبير.
لدي نفس القلق الذي لديك بشأن أسماء النطاقات لـ Discourse. لماذا لا يكفي localhost؟
لقد قمت بتثبيت Discourse فقط لفريقي لنشاطاتنا، لكن لا يمكنني ذلك دون DNS. حاولنا إضافة مورد DNS باستخدام localhost إلى ملف المضيفين على الخادم الخاص بي لحل المشكلة، لكن دون نجاح.
لا. إذا كنت تريد تشغيل تثبيت تطويري، فلا تحتاج إلى اسم نطاق، لكنه يعمل فقط على localhost. إذا كنت تريد أن يستخدم فريقك النظام، فستحتاج إلى اسم نطاق. إذا كان لديك فريق، فمن المؤكد أن لديك اسم نطاق. فقط أنشئ نطاقًا فرعيًا لأي نطاق تستخدمه شركتك، أو ادفع 12 دولارًا مقابل اسم نطاق، أو جرب النسخة التجريبية المجانية.
حسناً، بالنسبة لنا، لا نريد أن تكون المناقشات عامة. نريد لوحة نقاش داخلية. أنا مع الآخرين؛ فشل التشغيل على localhost، وفشل التثبيت عند محاولة تجربته فقط. هذا أمر مزعج جداً، والبرامج النصية الغريبة بدلاً من الأمر المعروف والقياسي ‘docker-compose up -d --build’ أمر مقلق لدرجة لا توصف. لا أعرف ما إذا كنت أريد استخدام هذا المنتج لأنه يتعامل مع نفسه بجدية مفرطة… أو على الأقل الشخص الذي كتب برنامج التشغيل يفعل ذلك.
تحتاج إلى اسم نطاق، لكنه لا يحتاج إلى أن يكون على عنوان IP عام. إذا كان خادمك قادرًا على الوصول إلى الإنترنت (لتحميل Discourse ومكوناته)، فيمكنك إيقاف تشغيل مكونات Let’s Encrypt وسيجب أن يعمل. أعتقد أنك تحتاج فقط إلى حذف قوالب SSL و Let’s Encrypt في ملف YAML، لكن لن تتمكن من استخدام discourse-setup. انسخ نموذج التشغيل المستقل وعدله يدويًا.
إنه مطلوب لعدة أسباب. على الرغم من أنه يمكنك الحصول على نطاق مجانًا من FreeNom، إلا أن هناك الكثير من الجدل حول كيفية تعامل FreeNom مع البيانات ومعلومات المستخدم، لذا كن حذرًا إذا اخترت هذا المسار.
