Apache مع SSL + Discourse: الخطوات التالية؟

[OrbitStorm]

بعد قضاء أسبوع في البحث عن حل لتثبيت Discourse بجانب Apache، أطلب بتردد المشورة بشأن الخطوات التالية، حيث يبدو أن تفعيل شهادة SSL لـ Discourse خلف Apache شبه مستحيل نظرًا لتصميم Discourse المائل إلى Nginx.

الهيكل الحالي لبيئة الاستضافة الخاصة بي:

• خادم Digital Ocean بسعر 10 دولارات
• Ubuntu 18.04
• Apache مع شهادة SSL من Let’s Encrypt للصفحة الأمامية HTML
• PHP و MySQL و phpMyAdmin
• Webmin (بدون SSL)
• Discourse

أود الاحتفاظ بمرونة تثبيت WordPress، لذا لم أتأكد من أن Nginx هو المسار الصحيح، حيث قرأت أن Apache يحافظ على توافقية أفضل مع WordPress.

هدفي: تفعيل شهادة SSL على نطاق كامل للمجال، بما في ذلك Discourse، دون الحاجة إلى فصل Discourse إلى خادم (droplet) منفصل. إذا تطلب ذلك استخدام محدود لـ Nginx، فلا بأس. أحتاج فقط إلى معرفة الدروس التعليمية التي يجب البحث عنها لحل هذا الفوضى.

شكرًا لكم.

[fzngagan (Faizaan Gagan)]

هل جربت هذا؟ Set up Discourse on a server with existing Apache sites

[EricGT]

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

1. هل لديكم وكيل عكسي (reverse proxy)؟
2. هل يقوم الوكيل العكسي بتشفير SSL؟
3. هل الخوادم الأخرى لا تستخدم SSL وتعتمد على الوكيل العكسي لتشفير SSL، أم أنكم تطبقون استراتيجية الدفاع على الأعماق حيث يقوم كل خادم بتشفير SSL؟
4. هل الاتصال بين الوكيل العكسي والخوادم يتم حصريًا عبر الـ sockets وليس المنافذ (ports)؟

[neounix (Dark Matter)]

مجرد معلومة جانبية، لقد أجريت اختبارات شاملة باستخدام كل من Apache2 وnginx كوكلاء عكسيين أمام Discourse في بيئة الإنتاج (باستخدام sokتات يونكس)، وnginx ليست “أسرع بكثير”.

في هذا التكوين، يكون nginx “أسرع قليلاً”، والفرق في السرعة غير ملحوظ للمستخدم.

بالإضافة إلى ذلك، لا تظهر اختبارات Google Pagespeed في أدوات مشرفي المواقع (Lightspeed)، عند حساب متوسطها عبر الزمن، أي فروق جوهرية بين الوكيلين العكسيين.

هذا التعليق (مجرد معلومة جانبية) لا يستند إلى نظرية أو تكرار ما كتبه آخرون؛ بل يستند إلى اختبارات حقيقية في بيئة الإنتاج.

نقوم بتشغيل جميع حالات Discourse الخاصة بنا خلف وكلاء عكسيين من Apache2 (كانت في الأصل وكلاء عكسيين من nginx) لأننا نفضل تشغيل العديد من المواقع (استضافات افتراضية) على خوادمنا حيث توجد بالفعل تطبيقات LAMP مستضافة.

أي شخص يريد استخدام Apache2 كوكيل عكسي بدلاً من nginx سيكون الوضع ممتازًا! هذا الأمر يجعل Discourse متاحًا بسهولة لمجموعة واسعة من المستخدمين / المضيفين (Apache2 وnginx).

[OrbitStorm]

@fzngagan لستُ أبدأ من الصفر، وهذا الدليل مخصص لـ CentOS، بينما ذكرتُ بوضوح في منشوري أنني أستخدم Ubuntu.

@EricGT راجع الحل الذي شاركتُه في موضوعي الخاص، لأن الحصول على دعم إذا كنت تستخدم أي شيء غير Nginx أو CentOS شبه مستحيل — كما يتضح من هذا الموضوع حيث لم أحصل على إجابات لسؤالي، بل على نقاش خارج الموضوع حول Apache مقابل Nginx.

Discourse not loading with Apache and proxy redirect

Despite having every intention of moving on from Discourse given the utter lack of current documentation that isn’t hyper-focused on CentOS/Nginx, an incredibly generous and patient individual at DigitalOcean responded to a thread I had created there and after some trial and error, helped put together a simple-to-follow tutorial for prospective Discourse users with the same circumstances as mine. As a refresher, those circumstances are: Installing Discourse on the same server as Apache | Using…

@Stephen

ليس على الإطلاق، فبعض المواقع الكبيرة جداً تستخدم nginx+php-fpm+wordpress. عند ضبطها بشكل صحيح، يكون Nginx أسرع بكثير.

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

@neounix

أي شخص وكل شخص يرغب في استخدام Apache2 كوكيل عكسي بدلاً من nginx سيكون بخير!

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

[codinghorror (Jeff Atwood)]

حسناً، كما نوضح بوضوح في عدة مناسبات، هناك حد لما يمكننا دعمه مجاناً هنا بسبب قيود الوقت والعقل. لهذا السبب لدينا تثبيت قياسي يعمل بشكل جيد لـ 95% من الأشخاص الذين يجربونه، ونقدم دعماً كاملاً له.

إذا كنت ترغب في استكشاف خيارات الدعم المدفوع للتثبيتات المخصصة، فإننا نوصي بقناة Marketplace.

[OrbitStorm]

@codinghorror

حسنًا، كما نوضح بوضوح عدة مرات، هناك حد لما يمكننا دعمه مجانًا هنا بسبب قيود الوقت والعقلية.

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

ردك يعطيني انطباعًا بأن “الدعم” هنا مجرد خدعة لبيع خدمات إضافية.

[neounix (Dark Matter)]

@OrbitStorm

لقد حصلت على مساعدة من DigitalOcean، وهي مزود استضافة، للحصول على وكيل عكسي مناسب. هذا أمر مذهل، حتى بالنسبة للبرمجيات مفتوحة المصدر.

عزيزي @OrbitStorm

أولاً، نحن نستخدم Discourse في بيئة الإنتاج خلف وكيل عكسي Apache2 (في أكثر من حالة) ولم نواجه أي مشاكل في إعداده؛ سوى “البحث على Google عند الحاجة للمساعدة” وهو ما يفعله الجميع دون تردد.

ثانياً، لم أطلب من فريق Discourse أو أي شخص في meta دعم Apache2 كوكيل عكسي لأن هذا التكوين غير مدعوم رسمياً. فـ Discourse لا (بحسب معرفتي) “يدعم رسمياً” تكوينات متعددة الحاويات، أو الوكلاء العكسيين (مثل Apache2)، أو Kubernetes، أو Docker Swarm، أو عدد لا يحصى من التكوينات الأخرى. ومن المنطقي والصحيح أن يحدّ فريق Discourse، الذي يقدم هذا البرنامج الرائع مجاناً ومفتوح المصدر مع كل سطر برمجي وكل تعديل على Github، من “التكوينات المدعومة رسمياً”. وقد بدا لي أن Jeff لخص هذا بشكل جميل وصحيح جداً:

حسناً، كما أوضحنا بوضوح عدة مرات، هناك حد لما يمكننا دعمه مجاناً هنا بسبب قيود الوقت والراحة العقلية. - Jeff A.

ثالثاً، يوفر Discourse عدداً من الدروس التوجيهية للتكوينات “غير المدعومة”، مثل استخدام Apache2 كوكيل عكسي؛ ومع ذلك، فإن إعداد وكيل عكسي ليس “مهمة خاصة بـ Discourse” بحد ذاتها. فإعداد وكيل عكسي هو “مهمة عامة لمدير الأنظمة” وهي نفس المهمة تقريباً لأي تطبيق خلفي، بما في ذلك Discourse.

نستخدم Apache كوكيل عكسي أمام عدد من تطبيقات الويب بما في ذلك Discourse، وسجل Docker، وحاويات وتطبيقات Docker أخرى. واستخدام Apache2 (أو nginx) كوكيل عكسي ليس خاصاً بـ Discourse، بل هو مهمة عامة لمدير الأنظمة.

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

لذا، ولخّص لك يا @OrbitStorm (هذه آخر مشاركة لي في موضوعك، لذا يرجى القراءة بعناية) ما تم قوله سابقاً، بما في ذلك كلمات J. A. اللطيفة والصبر، لديك العديد من الخيارات:

1. يمكنك بسهولة الذهاب إلى الإنترنت وتعلم كيفية إعداد Apache2 كوكيل عكسي (وهذا ما فعلناه)، وهو أمر ممتع ومجاني لتعلم هذه المهمة العامة لمدير الأنظمة.

2. يمكنك توظيف شخص للقيام بذلك إذا كنت غير راغب في التعلم، أو لا تستطيع “حلها” بنفسك، أو لا تملك الوقت الكافي.

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

أوصي بشدة، بصفتي مستخدماً لـ Discourse ولدي عقود من خبرة إدارة الأنظمة، ألا تختار الخيار رقم 3 (فالتنمر والترهيب لن ينجحا مع فريق meta، وهذا ما أضمنه لك)؛ وأن تفكر في الخيار رقم 1 إذا لم ترغب في إنفاق أي مال للمساعدة.

إعداد Apache2 كوكيل عكسي لـ Discourse أمر في غاية السهولة. توجد بعض مشاركات meta الخاصة بـ Discourse حول هذا (بعضها حديث وبعضها قديم)، وهناك عدد لا يحصى من الدروس التوجيهية على الإنترنت حول كيفية إعداد Apache2 كوكيل عكسي لتطبيق ويب. التقنية نفسها. أنصح باستخدام منفذ Unix (unix socket) عند التشغيل في وضع الوكيل العكسي.

بصدق، من الممتع إعداد Apache2 كخادم افتراضي وكيل عكسي لـ Discourse. لماذا نجعل الأمر مرهقاً ونطلق إهانات على الأشخاص الذين ابتكروا هذا البرنامج الرائع ويعطونه مجاناً؟ إن Discourse هدية مجانية! إذا كنت ترغب في تكوين Discourse بخلاف التكوينات المدعومة رسمياً، فلن يمنعك أحد!

ختاماً يا @OrbitStorm، أنصحك بشدة (كمتحدث بصفتي مستخدماً لـ Discourse وليس كعضو في الفريق) بتغيير نهجك في التنمر على meta للحصول على الدعم. وكما قلت، أنا أدير Discourse في تكوينات “غير مدعومة رسمياً” ونشرت تحديثات ورموزاً هنا لمساعدة الآخرين (أعطي شيئاً لهذه المجتمع الرائع). لقد نشرت بالفعل كوداً يعمل وسهل المتابعة لإعداد Apache2 كوكيل عكسي، كما فعل آخرون قبلي.

يرجى اختيار إما الخيار رقم 1 (افعلها بنفسك) أو الخيار رقم 2 (استأجر شخصاً للقيام بذلك)؛ وتخلي عن نهجك الحالي رقم 3 (التخويف والتنمر وإهانة فريق meta). إذا أردت اختيار الخيار رقم 3، فانشر في منتدياتنا الخاصة بـ Unix و Linux ويمكنك أن تتنمر عليّ هناك إذا أردت، كل ما تشاء

[OrbitStorm]

@neounix

في الختام، @OrbitStorm، أنصحك بشدة (كمتحدث بصفتي مستخدمًا لـ Discourse وليس كعضو في الفريق) بتغيير نهجك في التنمر على منصة Meta للحصول على الدعم.

TL;DR: ماذا؟

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

ما زلت تتحدث عن الالتزام، ومع ذلك، ها أنت ذا، تستمر في الرد على خيوطي فقط لتكون جدليًا (كما فعل ستيفن). لم أكن أدرك أن هناك قاعدة تمنعني من طلب الدعم لتهيئة استضافة شائعة (تم الاستشهاد بـ W3Techs سابقًا وهي تُظهر حصة 67% لـ Apache). كان بإمكانك ببساطة ترك خيوطي دون إجابة إذا لم تكن موافقًا، لكنك اخترت أن تكون عدائيًا وتعطل المحادثة.

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

أعمل في تطوير الألعاب منذ 16 عامًا ولم أعرف أبدًا مثل هذا المستوى الجنوني من عدم الاحترافية والتافهة كما هو هنا في خمسة أيام قصيرة فقط. هذا سخافة على مستوى Reddit؛ نكتة صريحة.

@neounix

اذهب وانشر في منتديات Unix و Linux لدينا، ويمكنك أن تتنمر عليّ هناك إذا أردت.

أيضًا، هذه حالة توضيحية. لا يُصدق.

[Benjamin_D (Benjamin Decotte)]

لا أستطيع أن أرى لماذا يجب أن يكون لترتيب SSL علاقة بالتطبيقات خلف الوكيل ، طالما أن قالب SSL معطل في ملف app.yml؟ سواء كان nginx أو apache أو haproxy أو traefik، فجميعها تملك نفس المفهوم المتمثل في المقطع/كتلة الخادم/المضيف الافتراضي، حيث تحدد بشكل أساسي تشغيل SSL، ثم موقع شهاداتك على المضيف الخاص بك، وبعض معاملات SSL الأخرى، وهنا قد تكمن المخاطر ربما؟

أعتقد أن الحل الذي تبحث عنه ليس مرتبطًا بـ Discourse بل بـ Apache، وأعتقد أن أي تكوين SSL جاهز للعمل مع Apache ومضيف افتراضي سيعمل بشكل جيد مع Discourse، كما عمل مع وكلاء عكسيين آخرين، لكن قد أكون متفائلًا بعض الشيء .
ومع ذلك، أتذكر أنني واجهت مشكلة ربما تتعلق بـ ciphers، فأنت تريد التأكد من نسخ/لصق بعناية (السطر طويل جدًا) تلك المستخدمة داخل حاوية Docker.

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

[codinghorror (Jeff Atwood)]

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