هل هناك اهتمام بـ Podman؟

مطور
20

حاولتُ ذلك لمدة نصف ساعة تقريبًا. إن 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:

يخبر خيار z Podman بأن حاويتين تشاركان محتوى الـ 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) ويحتاج إلى صيانة مستمرة أم لا. لكن… لا أعرف. :roll_eyes: