Awesome! I’ve bookmarked this post, and if anybody asks how to run Discourse in Kubernetes or Swarm, I’ll be sure to point them at your images . Advantage of being not-an-employee: my word doesn’t have to carry the weight of being Official™.
They, on the other hand, benefit immensely from having One Official™️ Way of deploying Discourse. CDCK is not going to take on the load of maintaining a deployment system that they themselves don’t use and is massive overkill for most self-hosters. And if they don’t maintain it, they ain’t endorsing it. Brand protection demands it.
I recently reached critical appreciation for discourse and got interested in hosting a deployment. I’m currently hosting JupyterHub, GitLab and Mattermost - everything through Helm charts and would very much like to do the same with Discourse.
Some background about Helm / Kubernetes:
A Helm chart is a set of configurable Kubernetes resources, and Kubernetes resources are for example a Deployment Kubernetes resource that makes a given docker image run at all time. Installing something can end up becoming a single line command + some configuration.
I would be happy to at least review code and make some PRs to fix various things in a Helm chart for discourse if it would be developed. I’m currently a maintainer of JupyterHub’s Helm chart and have various contributions to other charts.
I think it’s actually possible / feasible to break up Discourse into a set of kube pods, but have fun sizing the resource requirements for the web and sidekiq runners
If insane levels of infrastructure failure tolerance is not a business requirement for you, just use the singleton fat container, it’s going to be order of magnitude cheaper & easier for the same level of steady state service.
أنا من مجتمع إيطالي كبير نسبيًا يستخدم Discourse كأداة لمنصته الخاصة بالمنتديات.
بينما نحب Discourse، لاحظنا أيضًا بعض الصعوبات في نشره على Kubernetes عبر إجراءات «قياسية» من نوع ما.
أشعر بألم المطورين لقد عملت لسنوات في Open Networking Foundation، وكان أحد أكبر التحديات نقل منصة CORD -إحدى أكبر منصاتنا- من التثبيت القائم على السكربتات إلى Dockerfiles/docker-compose وصور Docker المستضافة على DockerHub بالإضافة إلى Helm Charts. ورغم وجود مخاوف معقولة من القيام بذلك، وبما أن حلًا يناسب جميع الحالات لا يوجد فعليًا، إلا أنني أستطيع القول إننا رأينا فوائده بوضوح منذ أول عمليات النشر.
عادةً، أكبر خطوة يجب اتخاذها هي تبني عقلية تسمح للأدوات الموجودة بالقيام بما تفعله أفضل ما يمكن فـ Docker يملك إجراءات تثبيت قياسية وسهلة وموثقة جيدًا بالفعل. أما السكربتات فهي شيء مخصص، وغالبًا ما تحتاج إلى تخصيصات وصيانة مستمرة.
كما أنه لا يوجد أي سبب يمنعك من استخدام صور Docker الأصلية أو Helm Charts كاعتمادات لـ Discourse (مثل: unicorn، postgres، redis، …).
أنصح بالبدء بالأساسيات أولاً (أي وجود Dockerfile و docker-compose وبناء آلي على DockerHub لكل مكون). بمجرد إنجاز ذلك (مع التعديلات المناسبة على البرمجيات والوثائق)، يصبح تطوير Helm Charts أسهل شيء.
سأكون سعيدًا جدًا للمساعدة، حتى عبر مكالمة لمناقشة إيجابيات وسلبيات الحلول المذكورة أعلاه.
خلال بحثي القصير، لاحظت أيضًا أن Bitnami (شركة مشهورة جدًا في مجال Docker) قد أطلقت بعض الصور (https://github.com/bitnami/bitnami-docker-discourse#how-to-use-this-image). كنت أتساءل عما إذا كان هذا عملًا منفصلًا يقومون به بمفردهم، أم أنه شيء منسق معكم. قد يكون نقطة انطلاق ممتازة. إذا لم يكن هناك شراكة معهم، فإنني أنصح به كطريقة ممكنة للمضي قدمًا. لست متأكدًا مما إذا كانوا سيقومون بذلك مجانًا، لكنه قد يكون خيارًا متاحًا.
معظم عمل تغليف Docker سيكون لمطابقة ما يفعله pups في الخلفية لـ launcher، بما في ذلك إعداد بعض التكوينات المخصصة لـ Postgres و Sidekiq وما إلى ذلك. قام @unteem بحل مشكلة شخصية واتبع ما فعله pups للإصدارات الأقدم من Discourse. الحفاظ على صورة Docker محدثة مع الإصدار الرسمي أمر صعب. سيكون من المثير للاهتمام تفصيل العملية الكاملة واتباع هذا المسار باستخدام نهج Docker قياسي. إذا كان هناك مسار عملي نحو استخدام إعداد قياسي، فأعتقد أن العديد من الأشخاص هنا سيكونون سعداء جدًا.
لم أفعل ذلك بعد. أنا متأكد من وجود الكثير من المعلومات هناك، لكنني عادةً ما أبتعد -على الأقل في سياق العمل- عن الوظائف المخصصة لمستخدم واحد (عكس تلك المدعومة من المجتمع)، وذلك لسبب بسيط وهو أنه قد يصبح من الصعب صيانتها لاحقًا.
المسار المحدد يعتمد حقًا على بعض تفاصيل المنصة.
ما أراه كحل ممكن في حالتك هو البدء في فهم كيفية عمل الصور القياسية (مثل Postgres و Redis وغيرها) مع Discourse دون تخصيصات محددة.
السبب في أنني أعتبر هذا الأمر مهمًا هو أنه يمنحك القدرة على الاعتماد -في أي مكان تقوم فيه بتثبيت Discourse- على خدمات قياسية خارجية (يمكن تثبيتها على عتاد مادي، أو آلة افتراضية، أو حاويات، أو في k8s كاعتماديات للرسوم البيانية، إلخ).
عادةً ما تتيح كل من هذه الخدمات استخدام بعض نصوص البدء التلقائي لإنشاء قاعدة بيانات وما إلى ذلك… لا ينبغي أن يكون ذلك صعبًا.
بعد ذلك، سأقوم بإنشاء ملف Dockerfile مناسب (الذي يصبح أيضًا دليل البدء السريع للمستخدمين الذين يرغبون في تثبيت Discourse بدون Docker).
ثم يأتي ملف docker-compose.yaml (وهذا مشابه جدًا لما تعرضه Bitnami على GitHub).
في هذه المرحلة، يجب أن تكون قادرًا على تشغيل Discourse على جهاز الكمبيوتر المحمول الخاص بك على شكل خدمات “مصغرة”، باستخدام صور الاعتمادات القياسية، في بضع ثوانٍ، وبأمر واحد، دون أي نص مخصص.
وأخيرًا وليس آخرًا، يأتي جانب Kubernetes الممتع (بضع ملفات YAML، ربما معبأة على شكل Helm Charts)، ليتم نشرها في المستودع الرسمي المستقر، أو بديلاً -على الأقل في بداية العملية- في مستودعك المستضاف ذاتيًا.
ما يمكنني قوله هو أنه يعمل بالنسبة لنا إذا كنت ترغب في مشاركة الرحلة وتشعر بالمغامرة، فلا تتردد في الانضمام إلينا لدينا متعة
لا نقدم دعمًا فعليًا، فليس لدينا الكثير من الوقت لذلك، لكن إذا قدمت طلب دمج (PR)، فسيتم الترحيب به. أتمنى حقًا أن نتمكن من القيام بهذا العمل تحت مظلة Discourse الرسمية، فهذا سيجعل الأمر أسهل بكثير.
لكن في نهاية المطاف، بدأت أفهم فريق Discourse. لديهم أداة واحدة فقط يدعمونها للمجتمع، وتعمل بشكل جيد. يقدمون دعمًا جيدًا للمستخدمين غير التقنيين، وهذا أمر رائع حقًا. إذا كانت هناك مشكلة، فإن الأمر git pull && rebuild يحل 99% من المشاكل أفهم أن دعم أداة أخرى يمثل خطرًا كبيرًا، وإذا لم يتم دعمها أو لم تُنفذ بشكل جيد، فقد يضر ذلك المشروع بطرق معينة. مرة أخرى، شكرًا جزيلاً لفريق Discورة على العمل الشاق
مشكلتي الوحيدة هي أننا ربما نكون كثرًا في تطوير حل خاص بنا، والطريقة الوحيدة للتعاون هي التعاون هنا في المصدر (upstream).
في الواقع، إحدى الطرق للقيام بذلك هي وجود صورة أخرى في discourse_docker تُسمى super_base؟ بدون runit/anacron/nginx/postgres، وتعتمد البنية الأساسية على super_base، ويمكننا إعادة استخدامها لنشرنا على k8s؟ أعتقد أن هذا سيعمل
أعتقد أنكم أنجزتم عملًا رائعًا، وسأكون سعيدًا بالمساهمة قدر المستطاع
لقد توفرت أيضًا على وقت أطول لفحص العمل الذي قام به فريق Bitnami عن كثب. والخبر السار هو أنهم قد فصلوا الحاويات بالفعل. هل أتيحت لكم الفرصة للنظر في ذلك؟ ما رأيكم؟
إضافة أي شيء لا نستخدمه داخليًا يعني ببساطة أنه سيتعطل وسيُتخلى عنه بعد فترة وجيزة، مما يسبب المزيد من الألم لكل من اعتمد عليه. كان لدينا أمثلة متعددة على ذلك في المشروع.
إذا كان هذا شيئًا يريد المجتمع العمل عليه، فلا بأس بذلك.
المشكلة فقط أن هناك العديد من الاعتمادات التي يجب متابعتها.
ينشر الناس بانتظام هنا أن هذه الصور لا تعمل بطريقة أو بأخرى.
ما أفعله هو استخدام launcher لبناء الصور ودفعها إلى مستودع أقوم بعد ذلك بنشره باستخدام Kubernetes، ولدي نصوص برمجية لترقيات بدون توقف. هذا مبالغة كبيرة للعملاء الذين قمت بإعداده لهم. أنا أضيف 3 ملايين مشاهدة صفحة/شهر على عتاد تجاري مع إعداد قياسي (معظمه) (يحتوي فقط على traefik يعمل كوكيل عكسي لعدة مواقع).
لقد فكرت في نشر مجموعة من الصور مع، على سبيل المثال، مجموعات مختلفة من الإضافات، لكن المشكلة هي أنه إذا كانت هناك أي مشاكل فيها، فلا يمكنهم الحصول على دعم هنا.
لن يحدث ذلك. الحل الذي أستخدمه هو بدء تشغيل الصورة الجديدة، ثم دفعها إلى مستودع، ثم تشغيلها، ثم إجراء عمليات ترحيل ما بعد الترقية بعد بدء تشغيل البودات الجديدة.
لقد كنت أفكر في تقديم مثل هذا العرض (ولن يكون “رسميًا”)، ولكني سأحتاج إلى التأكد من أنه لن يؤدي إلى مشاكل دعم إضافية هنا وأن يدفع لي مقابل الوقت الذي أمضيته في صيانته ودعمه. ليس لدي فكرة كبيرة عن كيفية حل أي من هاتين المشكلتين، ولكن إذا كانت لديك ميزانية، فلا تتردد في الاتصال بي.
(لكنه يفتقر بالتأكيد إلى التوثيق، و “الانفتاح” لفتح الحسابات والمساهمة.
إذا كان هناك طلب، هنا أو في رسالة خاصة، يمكننا الفتح )
@pfaffman إذا وجدت أشخاصًا سعداء على استعداد لدعم وقتك، فسيسعدنا التعاون!
نحن نستضيف ديسكورس لبعض المجتمعات الصغيرة، بشكل رئيسي في فرنسا، كجزء من الحركة المشتركة.
(مثل https://forum.chatons.org/ هو الأكبر الذي نستضيفه مجانًا)
. Advantage of being not-an-employee: my word doesn’t have to carry the weight of being Official™.
لقد عملت لسنوات في Open Networking Foundation، وكان أحد أكبر التحديات نقل منصة CORD -إحدى أكبر منصاتنا- من التثبيت القائم على السكربتات إلى Dockerfiles/docker-compose وصور Docker المستضافة على DockerHub بالإضافة إلى Helm Charts. ورغم وجود مخاوف معقولة من القيام بذلك، وبما أن حلًا يناسب جميع الحالات لا يوجد فعليًا، إلا أنني أستطيع القول إننا رأينا فوائده بوضوح منذ أول عمليات النشر.