الموقع يستجيب بـ 502 Bad gateway - هل المشكلة في Ruby؟

لدينا منصة Discourse تعمل منذ ما لا يقل عن ثلاث سنوات، وفي أمس ارتكبت خطأً بإعادة تشغيل المثيل على أمل أن يؤدي ذلك إلى تغيير النطاق. المثيل يعمل الآن، ويمكننا رؤية أن nginx يستقبل طلبات من الخارج، لكن جميع الزوار يتلقون رسالة “502 Bad Gateway” طوال الوقت. إليك مثال على إدخال في سجل أخطاء nginx:

2020/06/22 19:03:26 [error] 11742#11742: *158 connect() failed (111: Connection refused) while connecting to upstream, client: 162.158.159.12, server: <my domain>, request: "GET                / HTTP/1.1", upstream: "http://127.0.0.1:3000/", host: "<my domain>"

لا يوجد خادم ويب يعمل خارج Docker، لذا يقوم ملف app.yml ببساطة بإعادة توجيه المنافذ 80 و443 إلى الحاوية. ولكن ما الذي من المفترض أن يعمل على المنفذ 3000؟ هل من المفترض أن يكون Ruby / Rails؟

مرحبًا كريس:

نعم، أنت محق.

يعمل Rails على المنفذ 3000 في تطبيق Discourse.

قد ترغب في التحقق من سجل Rails في التطبيق لمعرفة ما يحدث مع Rails.

أتمنى أن يكون هذا مفيدًا قليلاً.

هل كنت تحاول تغيير اسم النطاق لـ مثيلتك؟

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

يرجى اتباع هذا الدليل، وسيساعدك على تغيير اسم النطاق بشكل صحيح.
Change the domain name or rename your Discourse

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

نحن نحاول حالياً إعادة بناء الحاوية، كما تم اقتراح ذلك في مكان آخر.

تتمثل التعقيدة الإضافية في أن جميع حركة المرور تمر عبر CloudFlare، مما أدى إلى ظهور مشاكل في شهادات SSL. غير متأكد مما إذا كان ملف templates/cloudflare.template.yml لا يزال يعمل؟

ستحتاج إلى تعطيل Cloudflare لتمكين Let’s Encrypt من طلب شهادة.

تم حل جميع المشاكل الآن. لقد تمكن أفضل خبراء التقنية لدينا من إنشاء إصدار جديد، بل نجحوا في جعل Let’s Encrypt يعمل بنجاح!