Discourse مثبت في UNRAID Ubuntu Server VM خلف NPM reverse proxy لا يحل اسم المضيف

مرحباً بالجميع! لقد قرأت منشورات مختلفة هنا دون جدوى، لذا فكرت في شرح إعدادي الحالي بالتفصيل على أمل أن يقدم شخص ما بعض الملاحظات لي لحل المشكلة.

أقوم حاليًا بتشغيل خادم Unraid. يستضيف Unraid حاويات Docker بالإضافة إلى الأجهزة الافتراضية. لدي مدير وكيل عكسي Nginx (NPM) يعمل في حاوية Docker ويتعامل مع الوكلاء العكسيين لجميع حاويات Docker الأخرى التي أقوم بتشغيلها. تم تعيين جدار الحماية الخاص بي لإرسال جميع حركة مرور WAN على المنافذ 80/443 إلى NPM وأقوم بإعادة توجيه حركة المرور داخل NPM إلى الحاويات الخاصة بي.

لقد اتبعت الدليل التالي: discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub

يشير إلى أنه مخصص للتثبيت على خادم سحابي، على الرغم من أن جهازي هو جهاز فعلي مستضاف ذاتيًا.

معلومات النظام اعتبارًا من الأحد 28 يناير 07:35:54 صباحًا بالتوقيت العالمي المنسق 2024

  تحميل النظام: 0.5126953125
  استخدام /: 45.9% من 13.16 جيجابايت
  استخدام الذاكرة: 6٪
  استخدام المبادلة: 0٪
  العمليات: 125
  المستخدمون المسجلون: 0
  عنوان IPv4 لـ docker0: 172.17.0.1
  عنوان IPv4 لـ enp1s0: 10.30.20.150

لقد قمت بتشغيل جهاز افتراضي في Unraid، وقمت بتثبيت Ubuntu Server، وقمت بتعيين عنوان IP ثابت، وقمت بتثبيت Docker، وقمت بتنزيل Discourse. عند تشغيل الإعداد، أحصل على الخطأ التالي.

اسم المضيف لـ Discourse الخاص بك؟ [discourse.example.com]: forum.mydomain.net

التحقق من اسم النطاق الخاص بك . . .
تحذير: يبدو أن المنفذ 443 للجهاز غير قابل للوصول باستخدام اسم المضيف:
تحذير: الاتصال بـ (المنفذ 80) يفشل أيضًا.

يشير هذا إلى أن forum.mydomain.net يحل إلى عنوان IP لا يصل إلى هذا
الجهاز الذي تقوم بتثبيت Discourse عليه.

أول شيء يجب فعله هو التأكد من أن forum.mydomain.net يحل إلى عنوان IP الخاص بهذا الخادم.
عادة ما تفعل هذا في نفس المكان الذي اشتريت منه النطاق.

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

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

./launcher rebuild app

أنا قادر على ping جهاز Ubuntu الافتراضي الخاص بي على عنوان IP الثابت المعين له عند 10.30.20.150 من حاوية NPM الخاصة بي. لقد قمت بإعداد تكوين NPM الخاص بي لاستهداف HTTPS 10.30.20.150 المنفذ 443 بالإضافة إلى منفذ HTTP 80 دون جدوى. عندما يفشل الإعداد، يبدو أنه يغلق حاوية Discourse داخل الجهاز الافتراضي؟

هل هناك أي حل بديل لهذا؟
ربما، تعديل منافذ جدار الحماية الخاص بي لتجاوز الوكيل العكسي واستهداف الجهاز الافتراضي مباشرة حتى يتمكن من الحصول على شهادة وتشغيل الحاوية، ثم بمجرد تشغيله، يمكنني تعديل ملف config.yml يدويًا لاستخدام الوكيل العكسي الخاص بي؟
هل يمكنني تعديل التثبيت بطريقة ما لعدم طلب شهادة SSL، وتشغيله على المنفذ 80، ثم التعامل مع الحصول على شهادة SSL من خلال NPM؟

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

سأكون ممتنًا جدًا للمساعدة أو الملاحظات أو الاقتراحات بشأن هذا الأمر.

هذا هو التثبيت الإنتاجي الوحيد المدعوم هنا.

لكنني لست مقتنعًا بأنه مناسب لظروفك حيث لديك بالفعل وكيل عكسي.

قد ترغب في التحقيق في استخدام صورة Discourse الأساسية وهندسة عكسية لتكوينك المخصص الخاص بك:

https://hub.docker.com/r/discourse/base/

هل يمكنك إزالة الإشارة إلى المنفذين 80 و 443 في ملف app.yml بإضافة علامة #؟

هل يوجد هذا الملف في /var/discourse/containers؟ لا يمكنني الانتقال إلى هذا الدليل، حيث يظهر خطأ “تم رفض الإذن”.

إذًا، هل سيكون المفهوم الأساسي لهذا هو تعديل ملف Dockerfile الأساسي لـ Discourse وإزالة الأسطر التي تقوم بتثبيت/تكوين الوكيل العكسي الذي يأتي مع الحزمة؟

لا، سأقوم بإنشاء ملف docker compose مخصص بالكامل (أو أي شيء آخر تستخدمه للتنسيق) واستخدام ملف dockerfile مخصص لـ discourse.

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

أتساءل عما إذا كان القيام بشيء مشابه لما فعله هذا الرجل هنا يمكن أن يعزل الحاويات المبنية في الوكيل العكسي حتى أتمكن من إكمال التثبيت، أو حلها بشكل صحيح للوكيل العكسي الخارجي الخاص بي الذي يعمل في حاوية docker خاصة به؟

إنه في الطرف المتقدم من عمل مسؤول النظام، ولكن Docker Compose يشبه إلى حد كبير اللعب بمكعبات ليجو رائعة جدًا - فهو ليس صعبًا كما يبدو وهناك الكثير من المساعدة على الويب.

ستكون تجربة تعليمية رائعة لتطوير مهارة قابلة للنقل للغاية، انطلق!

يبدو رابطك أيضًا مكانًا جيدًا آخر للمحاولة.

نعم، هذا هو المقصود.

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

اتباع طريقة “تشغيل مواقع الويب الأخرى” هو على الأرجح الشيء الذي يجب القيام به.

نعم، الأمر ليس سهلاً، لكنني عملت مع حل Docker Compose جيد جدًا لدى أحد العملاء - لم يكن هناك أي launcher!

لدي أيضًا تثبيت تطوير سحابي خاص باستخدام DC …