Oh man that’s tragic. So sorry to hear 
7 إعجابات
https://meta.discourse.org/t/official-cloud-native-docker-image-from-discourse/228568/8
@sam وهذا الموضوع يوضح أن هذا لن يتم حله أبدًا على الرغم من أن bitnami قامت بذلك للتو…
على الأقل حصلنا على إجابة لسؤالنا وهي لا.
ماذا عن تجنب استخدام الجذر في المقام الأول؟ استخدام fakeroot يوضح أن العائق الرئيسي هو المسارات الثابتة (مثل /var). بخلاف ذلك، باستثناء الأخطاء والمشكلات المختلفة التي يعاني منها الإعداد الحالي، يمكن أن يعمل.
من المؤسف رؤية مثل هذا البرنامج الرائع لديه إجراء إعداد إلزامي سيئ التصميم، يعتمد على سوء فهم شائع للحاويات. من الواضح بالنسبة لي أنه تم القيام به بأفضل النوايا؛ ومع ذلك، فإن النتيجة هي شيء لا يمكن نشره في أي مكان خارج بيئة الهواة.
إعجاب واحد (1)
صورة التشغيل الخاصة بنا كمستخدم discourse، وأعتقد أن الصورة الرسمية كذلك.\n\nولكن على أي حال، من الرائع أن يكون عالم “الشركات” مهتمًا، لأنه يمتلك وقتًا/مالًا أكثر بكثير من عالم الهواة 
أنا متأكد من أن المجتمع سيقدر مساهمتك في تحسين النظام البيئي!
إعجاب واحد (1)
هذا بالتأكيد ليس صحيحًا، فنحن ننشر صورنا باستخدام Nomad عبر أساطيل من الأجهزة، وهناك ما يزيد عن 10000 حاوية Discourse تعمل حاليًا في AWS و Metal في هذه اللحظة.
3 إعجابات
تتطلب الأدوات صلاحيات الجذر (root) للتشغيل، وتحتاج إلى الوصول إلى المجلد /var الخاص بالمضيف.
أتعاون غالبًا مع مجتمعات وشركات المصادر المفتوحة لتحسين إعدادات الحاويات الخاصة بهم. سأكون سعيدًا بالمساعدة و/أو النظر في التمويل للحصول على إعداد حاويات أكثر منطقية.
ليس إلزامياً. إنه فقط إذا كنت بحاجة إلى مساعدة لإعداده، فهذه هي الطريقة للقيام بذلك. لقد ساعدت العملاء الذين يستخدمون gke و eks و ecs، على سبيل المثال. نرحب بك للاتصال بي إذا كنت بحاجة إلى مساعدة في متطلباتك الخاصة.
لم يتم ترميز /var بشكل ثابت؛ لقد عملت مع شخص مؤخرًا كان لديه في /var/www/discourse (والذي بدا فكرة سيئة للغاية، حيث إنه يخاطر بتقديم بيانات سرية للويب، ولكنه كان “سياسة”).
إنه ليس سيئ التصميم، إنه سيئ التصميم إذا كنت ستصممه اليوم بدلاً من عقد من الزمان. لقد كان تصميمًا جيدًا في ذلك الوقت، ولا يزال يعمل لتشغيل بنيتهم التحتية وحتى للعديد من الأشخاص الذين لا يعرفون شيئًا عن إدارة النظام.
إعجابَين (2)
أعتقد أنك لا تعتمد على الأدوات الرسمية مثل discourse-setup، والتي تتطلب صلاحيات الجذر لتشغيلها، ومن المحتمل أنها مخصصة للإعداد المحلي.
ألق نظرة على مصدر discourse-setup. إذا كنت على دراية بتكوين وضبط أداء Discourse، فلن يكون ذلك إلزاميًا.
يقوم Launcher بكل العمل الشاق لبناء الصورة من ملفات yml الناتجة.
إعجابَين (2)
يمكن القيام بكل شيء، لكنه يبدو جهدًا غير ضروري بالنسبة لي.
- استخدم
fakerootقبل كل أمر - يمكن تغيير
/varعن طريق تحرير ملف yaml:sed -i \"s;host: /var/discourse;host: $PWD/discourse;g\" containers/*.yml --skip-connection-test(تم العثور عليه بالنظر إلى الكود، لأن البرنامج النصي غير قادر على التحقق من الاتصال إذا كان هناك وكيل عكسي)- أرى شيئًا متعلقًا بـ certbot أعرف بالفعل أنني سأحتاج إلى معرفة كيفية تعطيله نظرًا لأن تفريغ SSL يتم عادةً خارجيًا
- يمكن تغيير منافذ containers/app.yml بحيث يتم استخدام منافذ
>= 1024، ولكن هذا لا يبدو كافيًا:Error starting userland proxy: error while calling PortManager.AddPort(): cannot expose privileged port 443
لا أريد أن أكون وقحًا، لكن تشغيل خدمات متعددة في حاوية واحدة كان دائمًا تصميمًا سيئًا، لأنه يعني وجود طريقة قليلة أو معدومة لمعرفة ما يحدث للخدمات الفردية، والحاجة إلى إعداد آلية تحليل سجل مخصصة خارج Docker، ولا توجد فحوصات صحية مفيدة، ولا يمكن الاعتماد بسهولة على قاعدة بيانات خارجية، وما إلى ذلك. يمكن القيام بذلك إذا كانت هذه هي الخدمة الوحيدة التي تديرها في عملك، ولكن إذا بدأت كل خدمة أخرى في القيام بذلك، فإن معظم فوائد استخدام الحاويات تختفي.
سأكون سعيدًا بإرسال بعض طلبات السحب والتوثيق لجعل Discourse يعمل في بيئة متوافقة مع Docker دون الوصول إلى الجذر، ولكن فصل الخدمات وإعداد إعداد قياسي سيكون مهمة كبيرة دون ضمان أن يتم دمجها.
إذا كنت لا تتفق مع الجوانب الأساسية لكيفية بناء Discourse، فهل فكرت في استخدام منتج مختلف؟
3 إعجابات
حسناً، أفهم بشكل أفضل.
لدى ديسكورس رأي قوي حول الأدوات اللازمة لاستضافتها ذاتيًا. يسمح لهم ذلك بتقديم دعم فعال لمعظم المسؤولين ذوي الخبرة القليلة الذين يرغبون في نشر ديسكورس. يمكنك الموافقة أو عدم الموافقة، لقد كنت حزينًا بعض الشيء في الماضي أيضًا، لكنني أفهم الآن بشكل أفضل 
إذا كانت لديك حاجة مختلفة عن التشغيل السريع كما يفعل معظم الناس، فأنت في الغالب بمفردك. بمجرد أن تعرف ذلك، فلا بأس
لدينا نفس الحاجة لصورة ديسكورس مستقلة تعمل بالدكر. نقوم بتشغيلها على كوبيرنيتيس مع مينيو، لقد كان الأمر مؤلمًا بعض الشيء لجعلها تعمل، ولا يزال الأمر يتطلب الكثير من الجهد. لقد حصلنا على بعض المساعدة الرائعة من ديسكورس أيضًا للقيام بذلك.
عملنا متاح هنا:
https://forge.liiib.re/indiehost/tech/infrastructure/charts/-/tree/master/discourse
(لم يتم توثيقه بشكل كافٍ، ولا اختباره، ولا صيانته أو تحديثه في الوقت المناسب، أو أتمتته، ومن المحتمل أن يكون مخصصًا بعض الشيء، فهو ما هو عليه)
إذا كان الناس مهتمين بتحسينه، فلا تتردد في القدوم وتقديم طلب سحب، أو الدردشة هنا: https://matrix.to/#/#libresh:liiib.re
ولكن نعم، لدى فريق ديسكورس رأي قوي حول الإصدار المجتمعي لديسكورس. يمكنك الموافقة أو عدم الموافقة، لكنهم يقدمون معظم الدعم للأشخاص، والقليل الذي رأيته، إنه دعم مذهل، لذلك أعتقد أنه كان قرارًا جيدًا
6 إعجابات
هذه جوانب أساسية لكيفية تعبئة Discourse، أكثر من Discourse نفسه، وهو برنامج رائع، لكنك على حق، يجب أن أفكر في حلول مختلفة.
إعجابَين (2)
أنت مرحب بك لإزالة القوالب الخاصة بـ postgres و redis (بالإضافة إلى ssl و let’s encrypt) واستخدام قوالبك الخاصة.
إعجابَين (2)
شكراً للمشاركة. لقد وجدت أيضاً GitHub - literatecomputing/docker-compose-discourse: Launch Discourse with docker-compose and similar وصوراً من bitnami. المشكلة الرئيسية هي أن هذه الحلول غير مدعومة رسمياً. أتساءل عما إذا كان من الممكن أن تكون فكرة لإنشاء إعداد Docker بديل مدعوم من المجتمع، بدلاً من وجود مستودعات مخصصة مختلفة، لأنه لن يكون من الفعال نشر الجهد في أماكن متعددة.
إعجاب واحد (1)
أنت على حق، يمكن تغيير الإعدادات بالفعل. إذا تمكنت من تشغيله دون عناء كبير، فسأحاول إرسال بعض طلبات السحب (PR) لتحسين الأدوات أو الوثائق الحالية، مثل تشغيله بدون صلاحيات الجذر (root). يجب أن يكون ذلك متوافقًا مع آراء فريق التطوير، مع توفير بعض الراحة لمسؤولي النظام الأكثر تطلبًا.
بعد 9 سنوات، يبدو أن Docker الاصطلاحي مغطى بواسطة منتدى Bitnami?
ولكن في أماكن أخرى في هذا المنتدى توجد ادعاءات بأنه يستهلك الكثير من الذاكرة العشوائية وغير مدعوم. لقد فوجئت برؤية مقدار الاحتكاك الذي لا يزال موجودًا في الإعداد القياسي عند محاولة تشغيله في السحابة.
العديد من الخدمات هذه الأيام مثل redis و postgres والتخزين المتوافق مع s3 سهلة الإعداد والنقل بين مضيفين مختلفين مثل digitalocean و supabase و aws وما إلى ذلك، لذا فإن الواجهة الخلفية قابلة للنقل. يبدو أن الجهاز الافتراضي الذي يشغل Discourse يجب أن يكون سهل التوسع/التبديل ببناءات حتمية. من المؤسف أنه قريب جدًا من هذا المثالي ولكنه مقيد.
كما قال مستخدم آخر، هذا أمر مفاجئ:
المنطق المشار إليه سابقًا في الموضوع بأن جعل هذا أسهل قد يعيق الفرص التجارية هو منطق غريب. المصالح التجارية سيكون لديها موظفون للتعامل مع البناءات المعقدة، لذا فإن هذا يؤثر على المطورين المنفردين أكثر من أي شخص آخر. حالة الاستخدام الشخصية الخاصة بي هي أنني أدير مجتمعًا كبيرًا جدًا (غير ربحي). لذلك لا يندرج تحت هواة حسب الحجم أو تجاري حسب الإيرادات.
إعجاب واحد (1)
إيه… أفكر في إعداد منتدى/لوحة مجتمعية وبالطبع فكرت في استخدام Discourse (لأنني أستمتع بتجربة المستخدم النهائي) ولكن مرة أخرى واجهت العقبة مع التثبيت/الإدارة العدائية تمامًا…
على مر السنين، أصبحت متعلقًا جدًا بتشغيل كل شيء باستخدام ملف docker-compose بسيط، مع إضافة بعض العناصر الإضافية (قاعدة بيانات، minio للتخزين المتوافق مع s3 وما إلى ذلك) ولكن لا… لا يزال Discourse عدائيًا للغاية في هذه الحالة.
أنا آسف ولكن وجود بعض “المُشغّل” السخيف لبدء الأمور؟
ثم عملية الترقية تنص على:
قم بإنشاء صورة أساسية جديدة يدويًا عن طريق تشغيل:
./launcher rebuild my_image
آسف - إعادة بناء الصورة يدويًا؟ مثل بحق الجحيم… إنه مثل امتلاك/استخدام docker ولكن في الواقع عدم استخدامه…
هل يعمل ./launcher rebuild app؟ هذا هو الأمر المعتاد.
وهل اتبعت دليل التثبيت القياسي؟
ليس لدي ما يمكنني التعليق عليه بشكل بنّاء، لذا أطلب منكم محاولة ترقية خادم Mastodon، Pixelfed، Moodle… Discourse سهل بشكل لا يصدق.
أمر يدوي واحد يمثل عقبة 
إعجابَين (2)