صورة Docker الرسمية "cloud native" من discourse

[wzrdtales (Tobias Gurtzick)]

مرحباً،

لقد ألغى الفريق مؤخرًا دعم تعطيل الاستقصاء الطويل عبر الواجهة. هذا أدى إلى تعطل الوظائف المطلوبة لصورة bitnami docker، والتي تستخدم passenger ولا تعمل، انظر https://github.com/bitnami/bitnami-docker-discourse/issues/177. صورة bitnami لا تمرر معلمات البيئة مباشرة، لذلك هذا معطل حتى يقوم شخص ما بتوسيع صورة bitnami، انظر DEV: Drop `enable_long_polling` and `long_polling_interval` settings by tgxworld · Pull Request #16323 · discourse/discourse · GitHub.

بالطبع، ظهر لي السؤال، بما أن discourse يتم توزيعه بالفعل فقط مع حاوية docker: هل هناك أي فرصة أن يحتفظ الفريق بصورة docker “سحابية أصلية”؟

الفرق الكبير بين صورة bitnami وصورتك هو وضع التشغيل. تتوقع البنية التحتية الحديثة أنه يمكنك أتمتة التثبيت. عادةً ما يتم ذلك في k8s باستخدام helm، ولكن عمليات نشر ansible في بيئات تقليدية أكثر باستخدام الأجهزة الافتراضية ستؤدي إلى نفس النتيجة. لذا فإن ما سيجعل discourse على قدم المساواة مع صورة bitnami المهملة إلى حد ما هو إضافة روتين مثبت تلقائي وربما حتى تكييف قالب helm.

بما أنني هنا بالفعل، دعني أقدم بعض الملاحظات حول discourse نفسه و “جاهزيته السحابية”:

بشكل عام، عندما حاولنا ربط discourse بإعداد قابل للتكرار لمشروع عميل حالي، اتضح بسرعة أن discourse لم يتم إنشاؤه أبدًا من منظور البنية التحتية الحديثة. أحد الأمثلة هو الحاجة إلى تخزين NFS مشترك. هذا ليس موثوقًا به ولا قابلاً للتطوير. لحسن الحظ، يمكن إعادة توجيه معظم هذا بالفعل إلى S3، ولكن هناك أجزاء متبقية وهي المكونات الإضافية.

هناك ثلاث طرق لحل مشكلة المكونات الإضافية:

• الكود المقيم المخزن في قاعدة البيانات (غير مستحسن)
• حاويات جانبية مسبقة التعبئة (في مصطلحات Kubernetes سيتم استخدامها كـ initContainers للكتابة إلى emptyDir) الكتابة إلى تخزين متطاير (أي tmpfs) قبل بدء تشغيل حاوية discourse (مستحسن، على الرغم من أنه ليس مريحًا للغاية)
• روتين مثبت، يحصل على معلومات المكونات الإضافية الحالية وأوامر التثبيت الخاصة بها من قاعدة البيانات عند بدء التشغيل وروتين مراقب/مستمع لتثبيت المكونات الإضافية في وقت التشغيل أيضًا (غير مستحسن، لأنه بطيء للغاية وعرضة للأخطاء)

[Stephen]

أعتقد أن هذا قد تمت مناقشته بشكل مستفيض هنا:

Can Discourse ship frequent Docker images that do not need to be bootstrapped?

There is this open issue (which I just closed) on Discourse Docker repo asking Discourse should behave like a standard docker image a docker user excepts to be able to run discourse without a special launcher. to define multiple containers (redis, postgres, discourse,…), links and volumes, docker-compose should be used instead. Docker Compose overview | Docker Docs The question is somewhat misguided, but I would like to address a broader one of Can Discourse ship frequent Docker images …

[wzrdtales (Tobias Gurtzick)]

بصراحة، بما أن Bitnami حلها بسهولة، فلا يوجد سبب كبير لمناقشة ذلك كثيرًا. لن يكون من الصعب جدًا جعل Discourse قابلاً للنشر بسهولة.

[Falco]

@wzrdtales

أحد الأمثلة هو الحاجة إلى تخزين NFS مشترك.

أردت فقط الإشارة إلى أننا ندير العديد من مواقع Discourse في بيئات سحابية ولا نستخدم تخزين NFS. يتم التعامل مع الأصول والتحميلات عبر تخزين الكائنات (S3) بينما يتم الاحتفاظ بشفرة المصدر (النواة والإضافات) في صورة الحاوية التي تم تشغيلها.

[wzrdtales (Tobias Gurtzick)]

حسنًا، تم الرد على ذلك بالفعل: لحسن الحظ، يمكن إعادة توجيه معظم هذا إلى S3 بالفعل، ولكن هناك أجزاء متبقية وهي المكونات الإضافية. يعد بناء حاوية مسبقًا لاستخدامها ممارسة سيئة لأنه يزيد من خطر عدم الترقية بشكل صحيح عبر مخططات Helm المستخدمة.

[michaeld (Michael - Communiteq)]

@wzrdtales

الحاجة إلى تخزين NFS مشترك. وهذا ليس موثوقًا به ولا قابلاً للتطوير. لحسن الحظ، يمكن إعادة توجيه معظم هذا بالفعل إلى S3، ولكن هناك أجزاء متبقية وهي المكونات الإضافية.

هل يمكنك التوضيح؟ لا أفهم كيف تتطلب المكونات الإضافية تخزين NFS مشترك.

[sam (Sam Saffron)]

أنا آسف جدًا ولكن لدينا بالفعل هذا الموضوع الرائع لمناقشته.

لا أريد فصل هذا. إذا كانت هناك أي أفكار فيجب مناقشتها على:

Can Discourse ship frequent Docker images that do not need to be bootstrapped?

There is this open issue (which I just closed) on Discourse Docker repo asking Discourse should behave like a standard docker image a docker user excepts to be able to run discourse without a special launcher. to define multiple containers (redis, postgres, discourse,…), links and volumes, docker-compose should be used instead. Docker Compose overview | Docker Docs The question is somewhat misguided, but I would like to address a broader one of Can Discourse ship frequent Docker images …