الحاوية في المضيف لا تقوم بتشغيل install-nginx كما ذُكر أعلاه.
لست متأكدًا من أن هذا الموضوع مفيد بشكل خاص.
أنت لا تحب هندسة Discourse، ولن تقبل رأي المطورين حول الطرق التي يتم بها تحسين المنتج، ولا يبدو أنك على دراية بـ Docker، وبإقرارك الخاص أنت تكذب في أسئلتك مما يهدر وقتنا بشكل جماعي.
يحمل هذا الموضوع بالفعل وسم unsupported-install لأنك تبتعد كثيرًا عن نطاق الدعم المجاني المقدم للمجتمع. إذا كانت هذه الأمور تهمك حقًا، فلماذا لا تنشئ موضوعًا جديدًا في #marketplace؟ بهذه الطريقة يمكنك استثمار أموالك الخاصة لدفع مستشار لتثقيفك، بدلاً من استنزاف وقتنا.
لم أعمل معه من قبل، آسف. إذن هل يجب أن أضع أوامر sed المذكورة أعلاه في قسم الخطافات (hooks) من ملف app.yml؟ هل يوجد مثال في مكان ما يوضح كيفية القيام بذلك لتعديل ملف في مستودع docker_discourse أثناء عملية التمهيد (bootstrap)؟ حاليًا، يحتوي هذا القسم فقط على أمر git clone للإضافات.
ربما أستطيع إضافة أوامر sed هذه في قسم cmd مثل أمر git clone، لكنني لا أعرف في أي مجلد سيعيش برنامج نصي install-nginx.
أيضًا، أين يقع ملف app.yml؟ لم أستطع ربط قسم hooks المذكور أعلاه لأن مجلد containers فارغ في المستودع 
توجد جميع الوثائق اللازمة للقيام بهذه الأمور هنا في ميتا. نحن جميعًا نحب تخطي قراءة الدليل، لكن في هذه الحالة يجب عليك حقًا العودة إلى الأساسيات.
في الحقيقة، أنت تتعامل مع كل هذا بشكل معكوس.
سأشير مرة أخرى إلى علامة unsupported-install - التوقع هو أنه إذا قررت الانحراف عن التثبيت القياسي، فسيتحمل عبء تقني إضافي بنفسك.
كيف قمت بتثبيت هذه النسخة؟
آسف، لكنني أقوم بالبحث عن الوثائق قبل النشر. سأكون سعيدًا جدًا بوجود دليل لـ Discourse، وقد قرأت العديد من المواضيع الموسومة بـ #howo بالفعل. للأسف، لا يبدو أن هناك دليلًا لـ Discourse.
أقدر مساعدتك في هذا الأمر، وأنا متأكد من أنها ستفيد الآخرين في المستقبل الذين يبحثون عن وثائق حول كيفية القيام بهذه الأمور…
أولاً discourse-setup، والتي أدت في النهاية إلى تثبيت معطوب. ثم قمت بتعديل app.yml يدويًا، تليها ./launcher rebuild app
أعتقد أن هذه مناقشة مثيرة للاهتمام، فقط للتعرف على Discourse بشكل أفضل.
سأختار nginx، ربما أقوم بتعديل app.yml بما يكفي لإضافة وحدة mod_security في عملية التجميع، وأنشئ صورة أساسية خاصة بي.
الآن، Discourse هو برنامج معقد يعمل على Rails، وهو أكثر تعقيدًا في النشر السلس والمتسق، ولهذا السبب بذل الطاقم جهدًا إضافيًا في صورة Docker التي يصنعونها.
تحدث الكثير من السحر الأسود في الصورة، مع عدد هائل من التحسينات فقط للعمل بأفضل طريقة ممكنة في التثبيت المدعوم.
مع العلم بذلك، والقدرة على فهم جميع قطع اللغز (مثل المستودعات الـ 2-3 المطلوبة لتشغيل Discourse). ليس من المستحيل تحقيق ما تريد تشغيله.
الآن، ومع العلم أن إعدادك هو nginx -> varnish -> apache، لماذا لا تشغل nginx -> varnish -> Discourse مع إضافة mod_security إلى الصورة الأساسية وإعدادها باستخدام الخطافات.
احتمال أن يزيد mod_security من أمانك ضئيل للغاية. إن الأشخاص الذين يحافظون على Discourse مهتمون جدًا بالأمان، لذا فمن المرجح أن المشكلات التي يُفترض أن يحلها mod_security قد تم التعامل معها بالفعل. علاوة على ذلك، فإن احتمال أن يؤدي إضافة mod_security إلى صورتك إلى جعل Discourse غير قابل للاستخدام أكبر بكثير من الصفر. إذا قمت بتثبيت mod_security ووجدت أن Discourse لا يعمل، فستكون وحدك في تعديل Discourse ليتوافق مع mod_security، إما لإقناع مُطوري Discourse بأنك اكتشفت مشكلة أمنية حقيقية، أو أن تضطر إلى الحفاظ على نسخة مُعدّلة خاصة بك مستقبلاً.
لا يمكن أن ينشأ أي خير من هذا. من غير المرجح للغاية أن ينشأ أي خير من هذا.
موافق، جدار حماية تطبيقات الويب آخر يقترب من الأمان عبر الغموض.
تُبذل جهود استباقية حقيقية للحفاظ على أمان المناقشة:
لقد انحرف هذا الموضوع عن السؤال الأصلي المتعلق بتشغيل discourse على Apache (بدلاً من وكيل عكسي إلى nginx).
لكنني أعتقد أن مناقشة وضع جدار حماية لتطبيقات الويب (WAF) (مثل mod_security أو غيره) أمام Discourse مفيد للمجتمع، لذا فقد أنشأت موضوعًا منفصلًا لمناقشة Discourse + WAF تحديدًا هنا: