هل نجح أي شخص في إعداد Discourse ليعمل على استضافة Apache بدلاً من nginx الافتراضي؟
يبدو أن معظم المناقشات حول Apache في هذه المنتديات تدور حول تشغيل Discourse على استضافة تعمل بالفعل بنظام Apache. في كل حالة صادفتها، قام الأشخاص فقط بتوجيه Apache إلى nginx. وللتوضيح: أريد أن يعمل حاوية الخلفية Docker التي تشغل Discourse على استضافة Apache وليس nginx.
على وجه التحديد، آمل في تشغيل الخلفية الخاصة بـ Discourse على Apache بدلاً من nginx لتمكين وحدة mod_security. يتطلب إعداد nginx مع mod_security تجميع nginx من المصدر، وهي تعقيدات أود تجنبها.
يخدم خادم الإنتاج الحالي لدينا بالفعل عدة مواقع (مثل WordPress وMediaWiki، وغيرها). نستخدم nginx لإنهاء اتصالات HTTPS وإجراء بعض عمليات تحديد معدل هجمات حجب الخدمة (DoS) الأساسية، ثم نوجه الطلبات إلى Varnish Cache، ثم إلى الخلفية الخاصة بـ Apache مع mod_security. إذا أمكن، أود الحفاظ على هذه البنية لـ Discourse، بحيث تعمل حاوية Docker الخلفية الخاصة بـ Discourse على Apache مع mod_security وليس nginx.
هل نجح أي شخص في إعداد Discourse ليعمل على Apache؟
عذرًا، أنا جديد في Docker. أعاني حقًا في معرفة كيف يتم وضع ملف ‘/etc/nginx/conf.d/discourse.conf’ في مكانه داخل حاوية Docker. هل يمكن لأحد توضيح الخطوات التي يتم بها إنشاء هذا الملف ووضعه في الحاوية عبر سكربت ‘./launcher’؟
تحرير: انتظر، هل يتم بالفعل تجميع Nginx من المصدر بواسطة Discourse؟
لا، لم ينجح أحد. يرتبط Discourse ارتباطًا وثيقًا بـ nginx. سيكون من الصعب أو المستحيل استبداله بـ Apache. وبما أنك ستكون الشخص الوحيد الذي يقوم بذلك، فلن يهتم أحد عندما يفشل.
فقط استخدم حاوية Docker التي يستخدمها الجميع على الكوكب، وضع Apache أمامها إذا كنت تعتقد أن ذلك سيساعد في الأمان بطريقة ما.
إذن يبدو أن ملف /etc/nginx/conf.d/discourse.conf يتم إنشاؤه داخل الحاوية بواسطة ملف القالب /var/docker/templates/web.template.yml — والذي ينسخه إلى مكانه من $home/config/nginx.sample.conf، ثم يقوم بإجراء تعديلات باستخدام كتل replace في YAML (والتي يتم تحديثها لاحقاً في قوالب أخرى، مثل templates/web.socketed.template.yml).
كنت أفترض أن ملف nginx.sample.conf يتم تثبيته مباشرة بواسطة nginx عند التجميع من المصدر في image/base/install-nginx، لكن ملف nginx.sample.conf الوحيد الذي وجدته داخل الحاوية (/var/www/discourse/config/nginx.sample.conf) كان يحتوي بالفعل على تعليمات مخصصة لـ Discourse.
وللتوضيح: هل تعتقد أنه سيكون أكثر أمانًا بالنسبة لي تحديث سكريبت ‘image/base/install-nginx’ لتجميع nginx داخل حاوية Docker الخاصة بـ Discourse مع دعم mod_security، بدلاً من تحديث الحاوية لتشغيل vhost الخاص بـ Discourse خلف Apache (بدلاً من Nginx)؟ إذا كان الأمر كذلك، فما هي مخاطر تعديلي لسكريبت install-nginx؟ وكيف يمكن أن يؤدي ذلك إلى تعطيل تثبيت Discourse الخاص بي في المستقبل؟
إشعار هام: كل ما تقترحه من إجراءات، رغم كونه قابلاً للتنفيذ تقنيًا، غير مدعوم على الإطلاق. لا يمكننا أن نوفر دعمًا معقولًا لكل تركيبة ممكنة يبتكرها الناس لاستضافة Discourse على الويب. لذا فإن الدعم المقدم في هذا المنتدى يقتصر على التثبيتات التي تتبع الدليل الموجود في: discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub.
@ledimeo هذا ما اقترحه @pfaffman، وما أعتقد أنه أفضل في هذه الحالة، لتجنب تعطيل الأمور بشكل كبير في المستقبل عند إصدار نسخ جديدة. لكن يبدو أنه يستخدم بالفعل خادم nginx آخر في المقدمة كوكيل عكسي ولا يريد:
مع ذلك، أعتقد أن توجيه apache إلى nginx (حتى لو انتهى الأمر بهذه الطبقات الأربع) سيكون على الأقل أسهل في الصيانة من محاولة تغيير طريقة عمل discourse في التثبيت الرسمي.
إذن، إضافة Apache كوكيل (proxy) أمام Nginx الخاص بـ Discourse هي خيار ممكن بالتأكيد.
أتفق معك في أن الخبير سيجعل الترقيات المستقبلية أسهل، وهذه نقطة مهمة.
لكن إضافة خطوة أخرى إلى البنية التحتية لن تجعل فقط استكشاف الأخطاء وإصلاحها في المستقبل أكثر تعقيدًا، بل إن لدي أيضًا مخاوف بشأن أداء Apache كوكيل لتطبيق ويب يستخدم الاستدعاء الطويل (long polling)، كما أشار @sam في هذا المنشور من عام 2016.
أفضل Nginx بشكل عام على Apache، باستثناء عندما يتعلق الأمر بـ mod_security. سيكون رائعًا لو كانت مستودعات نظام التشغيل تتضمن حزمًا لتمكين mod_security في Nginx كما تفعل لـ Apache، لكن حاليًا تمكين mod_security على Nginx يتطلب تجميع Nginx من المصدر في كل من RHEL/Cent و Debian. وأنا أتجنب الاعتماد على الحزم المجمعّة من المصدر في بيئات الإنتاج كما يتجنب المرء الطاعون.
للأسف، لا يبدو أن سكريبت /var/discourse/image/base/install-nginx المحدث الخاص بي يُنفَّذ عند تشغيل أمر /var/discourse/launcher destroy app && /var/discourse/launcher rebuild app. هل هناك سبب يمنع أمر rebuild هذا من إعادة تنفيذ سكريبت install-nginx المحدث؟
إذا لم تكن معتادًا على Docker، فسيكون هذا المسار صعبًا…
discourse_docker يحتوي على الشفرة المصدرية لصورة Docker الأساسية الخاصة بنا الموجودة في سجل Docker العام، ولن يتم تشغيلها محليًا أبدًا، والسبب الكامل هو وجود صورة قابلة لإعادة الاستخدام.
حسنًا، لقد كذبتُ بشأن استخدام vim من أجل التبسيط. في الواقع، أقوم بتشغيل هذه الأوامر لتحديث السكربت بشكل متكرر (idempotently) وموثوق.
cd /var/discourse/image/base
cp install-nginx install-nginx.`date "+%Y%m%d_%H%M%S"`.orig
# إضافة كتلة للتحقق من وحدة ModSecurity لـ nginx مباشرة قبل تنزيل مصدر nginx
grep 'ModSecurity' install-nginx || sed -i 's%\(curl.*nginx\.org/download.*\)%# mod_security --maltfield\napt-get install -y libmodsecurity-dev modsecurity-crs\ncd /tmp\ngit clone --depth 1 https://github.com/SpiderLabs/ModSecurity-nginx.git\n\n\1%' install-nginx
# تحديث سطر التكوين لتشمل وحدة ModSecurity التي تم التحقق منها أعلاه
sed -i '/ModSecurity/! s%^[^#]*./configure \(.*nginx.*\)%#./configure \1\n./configure \1 --add-module=/tmp/ModSecurity-nginx%' install-nginx
# إضافة سطر إلى قسم التنظيف
grep 'rm -fr /tmp/ModSecurity-nginx' install-nginx || sed -i 's%\(rm -fr.*/tmp/nginx.*\)%rm -fr /tmp/ModSecurity-nginx\n\1%' install-nginx
أين يجب وضع هذه الأوامر بحيث يتم تعديل سكربت install-nginx الفعلي الذي يستخدمه الحاوية أثناء التمهيد؟
