People,
I know Discourse has standardised on Docker for distribution and support but it seems to me there are some reasonable arguments for also making Discourse available as a Podman container? I would be happy to have a go at producing something if at least one clued-up dev was prepared to help me . .
Regards,
Phil.
It is unlikely we can spend any time on it, but if you want to give it a go, go for it.
Thanks for the fast reply Jeff!
I will see if I can get some enthusiam going from the appropriate Fedora group . .
@codinghorror , Can you point me to a HOWTO for a completely manual install somewhere? - I have some familiarity with Rails etc . .
Here are the instructions: Beginners Guide to Install Discourse on Ubuntu for Development.
If you look at the install script in the Install Discourse Dependencies section of the guide, you’ll find the manual instructions there.
Thanks!
I will check it out . .
تم استبدال Docker بـ Podman في RHEL 8.
يبدو من المنطقي البدء في دعم تثبيت Podman لتجنب فقدان عملاء RHEL (وCentOS).
ببساطة: ‘alias docker=podman’
مما يُظهر توافقًا عاليًا مع Docker.
هل يبدو العائد على الاستثمار جيدًا؟
بما أن التثبيت الموصى به لا يستخدم حزمة Docker المزودة من المستودع، فلا أعتقد أن هذا يمثل اعتبارًا في أي من الحالتين.
طالما أن Docker نفسها لم تتوقف عن دعم التوزيع، فإننا بأمان.
لا أعرف بالضبط مقدار الجهد المطلوب لدعم Podman، لكنني أعتقد أن العملاء من قطاع المؤسسات لا يقدّرون مستوى دعم يُوصف بأنه “من المحتمل أننا بخير”.
إذا كنت تشغّل RHEL (CentOS) الإصدار 8 أو أحدث، فستحتاج إلى تثبيت Docker من مستودع خارجي، ربما بالتوازي مع Podman، وهذه الحالة لن تدعمها RedHat. أو يمكنك ببساطة استخدام Podman لتثبيت صورة Docker، لكن هذا الاستخدام غير مدعوم من قبل Discourse.
نأمل أن يتم دعمه رسميًا في المستقبل.
أعتقد أن هذا الموضوع سيحظى بمزيد من الاهتمام مع إصدار CentOS 8.
يدعم Docker بالفعل نظام CentOS 8، وبالتالي يدعم أيضًا نظام RHEL 8. لستُ على علم بأي سيناريوهات تتطلب تشغيل النظامين جنبًا إلى جنب، هل أغفلتُ شيئًا؟
من غير الدقيق القول إن Docker قد حُلت محله Podman، بل إن Podman أصبح يُوزَّع افتراضيًا الآن. فبعد كل شيء، من يستخدم إصدار Docker الذي يُرفق مع التوزيعة؟
كانت مسؤولية الدعم دائمًا تقع على عاتق Docker، وليس على شركة Red Hat. وكما ذُكر أعلاه، كانت التوصية دائمًا هي استخدام حزمة Docker، وليس الإصدار المرفق مع التوزيعة.
الأمر على العكس من ذلك، ولكن صفحة RedHat المرتبطة تقول:
حزمة
dockerغير مُضمَّنة ولا مدعومة من قبل Red Hat لنظام Red Hat Enterprise Linux (RHEL) 8.
حلّ محرك الحاويات
podmanمحلdockerباعتباره وقت تشغيل الحاويات المفضل والمدعوم والمُحدَّث لنظم Red Hat Enterprise Linux 8.
لا أفهم من هذا أن Docker “مدعوم” من قبل Red Hat.
إذا كان هذا يعني التخلي عن دعم عملاء RHEL، فهذا قرار من Discourse.
تحقق من مستودع Docker، فهم لا يقدمون حزم RHEL، بل CentOS فقط.
يُفترض أن يكون Podman متوافقًا بنسبة 100% مع Docker، لذا في الحقيقة لست متأكدًا من أننا سنحتاج إلى القيام بأي شيء
ربما، قم بتعديل وثيقة التثبيت قليلاً لإضافة مرجع لتثبيت Podman (ربما فقط قل إنه مدعوم وأنك مُفترض استبدال أمر docker بـ podman في مكان ما في البداية)، حتى لا يتساءل الناس عما إذا كان مدعومًا أم لا؟
لن نتخذ أي موقف صريح حتى نجرب هذا
بحسب علمي، لم يحاول أحد في تاريخ البشرية تثبيت discourse باستخدام podman من قبل
أعتقد أن هناك بعض الارتباك هنا. نحن نعرف عن Podman، ويؤيد عدة أشخاص في الفريق نجاحه لأن ذلك سيكون مفيدًا لكامل نظام FOSS البيئي، ولكن:
إنه غير مدعوم.
استضافتنا تستخدم Ubuntu / Debian. لذا، لا نملك عملاء يعملون على RHEL في الوقت الحالي.
حتى لو ثبت أنه يعمل كما هو، سأكون حذرًا جدًا من أي فكرة تتعلق بالدعم.
ما لم تتخلى Docker عن CentOS/RHEL، فإن ذلك غير ضروري، وحتى لو حدث ذلك، فإن Discourse/Docker لن يكون التطبيق الأول الذي لديه متطلبات على مستوى التوزيع.
ما أجده محبطًا هنا هو مقدار التكهنات مقارنة بكمية العمل المنجز.
لو بدأت بهذا، لكانت ردود أفعالي مختلفة:
لقد استخدمت التثبيت الرسمي لـ Discourse عبر Docker على Podman خلال الـ 30 يومًا الماضية، وإليك بعض الملاحظات التي واجهتها، وإليك ما أعجبني في هذا الإعداد!
الفرضية الكاملة هنا هي: قم بالعمل نيابةً عنا، فأنا غير راغب في التجربة، وغير راغب في بذل أي جهد، وهذا سيصبح مشكلة كبيرة لك وللأوساط.
أنا لا أحب هذا الأمر كثيرًا.
هذا يلخّص ردي بشكل جيد جداً؛ فنحن نعمل بتقنيات يمكن التنبؤ بها، ولا حاجة ولا مكان لإصدار إعلانات نهاية العالم.
لستُ من محبي هذه المناقشات المتبادلة أيضاً، وكان ينبغي لي على الأرجح أن أمسك لساني بدلاً من الانخراط فيها.
بناءً على هذه العبارة، كنت أفترض أنه يتعين عليك بذل بعض الجهد لجعل الأمر يعمل، ولكن إذا كان من المفترض أن يكون متوافقًا بنسبة 100% ولا يت الأمر سوى باستبدال الأمر، فسيكون ذلك رائعًا.
كنت أقترح أن يمكنك توجيه أولئك الذين ضلوا الطريق باستخدام Podman بدلاً من Docker.
لا أعرف بالضبط نموذج التطوير الخاص بك، لكنني أفترض أنه نموذج قائم على المجتمع يُتوقع من المستخدمين العمل فيه أولاً.
حاولتُ ذلك لمدة نصف ساعة تقريبًا. إن podman متوافق مع الأوامر لكنه غير متوافق مع المخرجات، لذا يصاب launcher بالارتباك عند محاولة تحليل المخرجات. (ليس من الصعب التمييز بينهما؛ فـ docker --version ترد بـ podman version 1.0.5، لذا فهذا ليس عائقًا جديًا.)
لا يوجد جهاز شبكة باسم docker0. إن مُحرّك التخزين الافتراضي overlay في podman هو في الأساس تنفيذ لـ overlay2 ومُربَط به، لكن المخرجات لا تذكر overlay2، ومخرجات أمر docker info تختلف قليلًا. استخدمتُ --skip-prereqs لتجاوز الفحوصات. لم تُنشأ الدلائل المشتركة تلقائيًا؛ ولم أتحقق من السبب. نفذتُ أمر mkdir -p /var/discourse/shared/standalone/log/var-log للمضي قدمًا. بعد ذلك، ظهرت مشاكل صلاحيات بسبب تفعيل SELinux دون تكوينه لـ /var/discourse.
إذا قمتَ بربط دليل ما بحاوية باستخدام volume mount وأضفتَ :z أو :Z، فإن محركات الحاويات تعيد تسمية المحتوى تحت الـ volumes إلى
container_file_t.
تقول وثائق بناء podman:
يخبر خيار
zPodman بأن حاويتين تشاركان محتوى الـ volume. ونتيجةً لذلك، يعلّق Podman المحتوى بوسم محتوى مشترك. تسمح وسوم الـ volumes المشتركة لجميع الحاويات بقراءة/كتابة المحتوى. أما خيارZفيخبر Podman بوضع وسم محتوى خاص غير مشترك على المحتوى. فقط الحاوية الحالية يمكنها استخدام volume خاص.
قررتُ استخدام غيّرتُ setenforce 0 مؤقتًا على هذا التثبيت المؤقت والعودة إلى ذلك لاحقًا، ربما.volumes لاستخدام :z بحروف صغيرة كما يلي:
volumes:
- volume:
host: /var/discourse/shared/standalone
guest: /shared:z
- volume:
host: /var/discourse/shared/standalone/log/var-log
guest: /var/log:z
مع هذه التعديلات البسيطة، تمكنتُ من تهيئة discourse. Redis غير سعيد لأن صفحات الذاكرة الشفافة الكبيرة مدعومة في النواة، ويقترح تعطيل ذلك، بالإضافة إلى تغيير إعدادات الإفراط في تخصيص الذاكرة. ربما مرّت عليّ رسائل تصحيح مفيدة كثيرة بين ملايين البايتات من مخرجات السجل!
./launcher start app
...
--restart option is not supported.
Use systemd unit files for restarting containers
عدّلتُ السكربت ليعمل دون استخدام --restart، واكتشفتُ الحاجة إلى --skip-prereqs أيضًا في وضع start، مما قادني أخيرًا إلى محاولة تنفيذ docker run، وعندها:
./launcher start app --skip-prereqs
...
+ /usr/bin/docker run ... -e DOCKER_HOST_IP= --name app -t -p 80:80 -p 443:443 -v /var/discourse/shared/standalone:/shared:z -v /var/discourse/shared/standalone/log/var-log:/var/log:z --mac-address 02:9c:01:9b:0e:17 local_discourse/app /sbin/boot
--mac-address option not currently supported
إذًا، بالتأكيد لا يعمل ذلك خارج الصندوق، ولا أعرف كم من الجهد يتطلب إصلاح launcher ليعمل مع docker أو podman. التعامل مع معالجة المتطلبات المسبقة سيكون “سلسًا” على الأرجح ولن يكون صعبًا جدًا مع فحص أولي لـ podman، لكنني لا أعرف مدى عمق الافتراضات المتعلقة بإعدادات الشبكة في التكوين عبر الطبقات السفلية، ويبدو أن وضع الشبكة هذا غير مدعوم ببساطة بواسطة podman.
بناءً على هذا القلق، أنا أخطط لعدم بذل الجهد لجعل launcher يعمل تحت podman. أنا فقط أبلغ بنتيجة تجربة أولية سريعة.
مع ذلك، ربما لا يكون العمل شاقًا لشخص يعرف المكدس (stack) بشكل أفضل. لقد قمتُ بكل أعمال التطوير هذه الربيع في تثبيت تطوير يدوي على Fedora 29 مع تعديلات تافهة مثل استخدام dnf بدلاً من apt-get وبعض ترجمات أسماء الحزم البسيطة، دون استخدام docker أو podman على الإطلاق. أتوقع أن شخصًا يعرف podman جيدًا بالإضافة إلى الإدارة العادية لمكدس تقنيات discourse بأكمله سيجد أن الأمر يتطلب جهدًا متوسطًا نسبيًا وسهلًا. لو كنتُ أعرف كل العمل المطلوب، لكان لديّ فهم أفضل لما إذا كان هذا النوع من العمل عرضةً للتعفن (rot) ويحتاج إلى صيانة مستمرة أم لا. لكن… لا أعرف. 