Podman vs Docker: أيهما تختار؟

إذا كنت في عالم المحاكاة الافتراضية والحاويات ، فمن المحتمل أنك واجهت Podman و Docker وقد تتساءل عن كيفية اختلافهما عن بعضهما البعض.

في هذا المنشور ، سوف نستكشف الاختلافات بين Docker و Podman ونحاول العثور على الخيار المناسب لك!

عامل ميناء

Docker هي تقنية حاويات تسهل إدارة التبعية داخل المشروع على جميع المستويات (التطوير والنشر).

تتوفر آلية Docker على أنظمة Linux و Windows و Mac OS ، وتتركز حول الحاويات وتنظيمها ، وهذا هو المكان الذي تختلف فيه الحاويات عن المحاكاة الافتراضية.

يحتوي Docker على كتلتين أساسيتين للبناء: Docker CLI و Docker Daemon.

Docker Daemon:

إنها عملية خلفية ثابتة تساعد في إدارة صور Docker والحاويات والشبكات ووحدات التخزين. يستخدم Docker واجهة برمجة تطبيقات Docker Engine REST للتفاعل مع Docker daemon ، الذي يتم الوصول إليه عبر بروتوكول HTTP.

Docker CLI:

إنه عميل سطر أوامر Docker للتفاعل مع Docker daemon. هذا هو ما تستخدمه عند تشغيل أي أمر Docker.

يعتمد تشغيل Docker على نواة Linux ووظائف هذه النواة ، مثل مجموعات cgroups ومساحات الأسماء. تفصل هذه الوظائف العمليات بحيث يمكن تشغيلها بشكل مستقل ، حيث أن الغرض من الحاويات هو تشغيل عمليات وتطبيقات متعددة بشكل منفصل.

هذا ما يجعل من الممكن تحسين استخدام البنية التحتية دون تقليل مستوى الأمان مقارنة بالأنظمة المنفصلة.

تأتي جميع أدوات الحاويات مثل Docker مع نموذج نشر قائم على الصور. يبسط هذا النموذج مشاركة تطبيق أو مجموعة خدمات عبر بيئات متعددة.

بالإضافة إلى ذلك ، يساعد Docker في أتمتة نشر التطبيقات داخل بيئة الحاوية. باستخدام هذه الأدوات المتنوعة ، يحصل المستخدمون على وصول كامل إلى التطبيقات ويمكنهم تسريع النشر والتحكم في الإصدارات وتعيينها.

بودمان

يقوم Podman (مدير POD) ببناء وتشغيل وإدارة حاويات OCI وصور الحاويات. تم تطويره بواسطة Red Hat وكان مخصصًا في الأصل لمؤسسته Linux 8. ويستخدم لإدارة الحاويات ويعمل كخلف رسمي لـ Docker.

وبالتالي أوقفت Red Hat دعم Docker لكنها أكدت أن التبديل سيكون سهلاً للمستخدمين نظرًا لأن Podman يعتمد على Docker على الرغم من أنه في الأصل كان مخصصًا فقط كأداة تصحيح.

يدير النظام البيئي للحاوية بالكامل باستخدام مكتبة libpod. نظرًا لأن Podman يعمل فقط على أنظمة Linux الأساسية ، فإن REST API والعملاء قيد التطوير حاليًا للسماح لأنظمة Mac و Windows بالاتصال بالخدمة.

لكن،   يوجد حاليًا عميل بعيد قائم على Varlink يعمل على أنظمة تشغيل Mac أو Windows التي تتيح الاتصال عن بُعد بخادم Podman المستند إلى Linux. تدعم مكتبة libpod طرقًا متعددة لتحميل الصور بأمان ، بما في ذلك الثقة والتحقق من الصور.

كما أنه يدعم الكبسولات لإدارة مجموعات الحاويات معًا وتنسيقات صور متعددة ، بما في ذلك تنسيقات صور OCI و Docker.

في البيئات الصغيرة جدًا والتي يمكن التحكم فيها ، يمكن أن يكون Podman بمثابة مقدمة لـ Kubernetes. إنه يسد الفجوة بين الإدارة الفردية للحالات الفردية من السنوات الأولى لضجيج الحاوية والتزامن الحديث مع Kubernetes.

يمكن لمستخدمي الحاويات الطموحين الاستمتاع بالفعل بالمستوى التالي مع الكبسولات. لم يعد إنشاء وتشغيل مجموعة Kubernetes ضروريين. في أبسط الحالات ، يمكن اختبار الكبسولات المصممة حديثًا وتحسينها في العمليات الفردية. حتى النقل اللاحق إلى Kubernetes ممكن.

يوفر الأمر podman generate kube ملفات التكوين المقابلة. بعد ذلك ، يخدم هؤلاء واحدًا لواحد كمدخلات لأداة Kubernetes kubectl.

يمكن للإصدارات الحالية من Podman أيضًا إنشاء ملفات تكوين لـ systemd - وهي ميزة لأي شخص يستخدم التوليفة الأولية في كل مكان لتنسيق الحاوية.

بودمان مقابل دوكر: الاختلافات

رسخ Docker نفسه بسرعة باعتباره الحصان الهاوٍ لإدارة الحاويات. ومع ذلك ، يتمتع Docker بالعديد من المزايا ، وقبل كل شيء ، مجموعة الصور سريعة النمو ، فضلاً عن العيوب والمخاطر الأمنية المحتملة. علاوة على ذلك ، لم يعد Docker مدعومًا كحاوية لـ Kubernetes.

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

يسمح للعمليات التي تعمل في الحاويات بالوصول إلى النواة بامتيازات الجذر وبالتالي مهاجمة النظام المضيف.

يظهر التمييز الأول عند استخدامه لأول مرة. بينما يتطلب Docker بدء تشغيل Docker daemon أولاً ، يمكن بدء تشغيل حاوية Podman مباشرةً من سطر الأوامر. لذلك لا توجد عملية خلفية ، ولا يتم تنفيذ التطبيق إلا عند الحاجة.

من منظور أمني ، يعد هذا أمرًا جيدًا لأن Podman أقل عرضة للهجوم إذا لم يكن البرنامج الخفي مضطرًا للعمل على مدار الساعة طوال أيام الأسبوع بامتيازات المستخدم المتميز. لا يتطلب Podman عملية خلفية بسبب الهندسة المعمارية ، والتي تختلف اختلافًا جوهريًا عن Docker.

بينما يتبع Docker نموذج خادم العميل ، حيث يتواصل عميل Docker مع Docker daemon عبر واجهة برمجة التطبيقات ، يتبع Podman نموذج fork-exec. تعمل كل حاوية كعملية فرعية لـ Podman.

يتم إنشاء مساحة اسم المستخدم عند أول استخدام عند تشغيل Podman بامتيازات مستخدم عادية. في مساحة اسم المستخدم ، يعمل Podman بامتيازات الجذر وله حقوق تحميل أنظمة الملفات وإنشاء الحاويات.

وفقًا لذلك ، فإن حاوية Podman لها الحقوق التي يمتلكها المستخدم المنفذ فقط. يعني استخدام مساحات أسماء المستخدمين أنه يمكن لكل مستخدم إنشاء وإدارة الحاويات الخاصة به ، ولكنها غير مرئية للمستخدمين الآخرين والمستخدم المتميز.

نظرًا لأن Podman يتم تشغيله بشكل مستقل عن Docker ، فإن المطورين لديهم الكثير من الفسحة ويمكنهم الاستجابة لرغبات المجتمع. تشمل الإضافات المثيرة للاهتمام إلى Podman الأمر mount / unmount وتكامل systemd.

يمكن للمضيف استخدام الأمر mount / unmount لتحميل نظام ملفات الحاوية ، على سبيل المثال ، للوصول إلى الملفات أو تغييرها ثم إلغاء تحميلها مرة أخرى.

أثناء مراقبة الحاويات باستخدام systemd لا يعمل بسبب البرنامج الخفي في Docker مع Podman ، يمكن بدء تشغيل الحاويات ومراقبتها وحتى إعادة تشغيلها عبر systemd.

بالإضافة إلى ذلك ، يوفر Podman الأمر podman podman generate systemd ، والذي ينشئ خدمة systemd مقابلة للحاوية المعنية ، وبالتالي يخفف المستخدم من إنشاء خدمات systemd ، مما يعني أن التكامل على النظام المضيف متاح.

هناك اختلاف مهم آخر بين Podman و Docker وهو أن الأخير لا يغير قواعد جدار الحماية أو تثبيت dnsmasq الحالي نظرًا لقدرته على إنشاء شبكة داخلية. في المقابل ، يتعين على Docker الكتابة فوق قواعد جدار الحماية لتمكين الاتصال بين الحاويات.

متى يجب أن تهاجر من Docker إلى Podman

إذا كنت تنشر الحاويات في بيئة قائمة على RHEL ، في هذه الحالة ، ليس لديك العديد من الخيارات باستثناء استخدام Podman لأنه أصلي لـ RHEL. يمكنك أيضًا الانتقال إلى Podman عبر Docker أو اختياره إذا كان لديك عمليات نشر صغيرة مع عدد قليل من الحاويات.

ومع ذلك ، إذا كنت ترغب في الحصول على أي شيء أكثر تعقيدًا من ذلك ، فلديك حاويات متعددة وكومة من حاويات التنسيق باستخدام عامل إنشاء / podman-compose عبر شبكة. من الأفضل استخدام Docker لأنه يتعامل مع الشبكات بشكل أفضل.

وبالمثل ، إذا كنت قد بدأت للتو في الدخول إلى عالم الحاويات ، ففي هذه الحالة ، يعد Docker خيارًا أفضل لأنه مستقر وراسخ مع الوثائق المناسبة ولديه منحنى تعليمي ضحل مقارنةً بـ Podman ، الذي لا يزال يفتقر إلى الاستقرار و ليس لديها وثائق محددة جيدا.

الهجرة من Podman إلى Docker

إذا كنت في سطر الأوامر ، فمن السهل جدًا التبديل من Docker Engine إلى Podman. في أبسط حالاته ، يعمل الأمر $ alias docker=podman في معظم الأوقات.

بالطبع ، هذا يفترض أن البرنامج المناسب مثبت على النظام. في حالة Linux ، هذه ليست مشكلة أيضًا ؛ تتوفر حزم البرامج الجاهزة للتوزيعات المتاحة تجاريًا.

Windows أو macOS ليس من بين أنظمة التشغيل المدعومة. يعمل نهج الاسم المستعار لأن العديد من أوامر Docker لها مكافئ Podman.

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

يكون التبديل أكثر صعوبة عند استخدام أدوات رسومية مثل Docker Desktop. يجب أن يؤثر بشكل خاص على المطورين الذين يعملون مع Windows أو macOS.

سيتعين على مستخدمي Docker Desktop التعود على سطر الأوامر ، وينطبق الشيء نفسه على Docker compose. ومع ذلك ، هناك مشروع podman-compose. تم كتابة البرنامج بلغة Python ، ويعمل كبديل لتأليف Docker.

الكلمات الأخيرة

يمكن اعتبار استبدال Docker بواسطة Podman على وشك الانتهاء. بالنسبة للمستخدمين والمسؤولين ، فإن معظم جوانب هذا التغيير سهلة. العديد من ميزات Docker لها مكافئات متطابقة في Podman.

الفائدة الحقيقية هي عدم وجود عملية خفية واحدة وامتيازات الجذر ، ناهيك عن الاستخدام الطبيعي لمجموعات الحاوية. ومع ذلك ، تجدر الإشارة إلى أن Docker تظل التقنية الرئيسية فيما يتعلق بالحاويات ، ولكن من المرجح أن يتغير هذا على المدى الطويل.

يمكنك أيضًا استكشاف بعض أوامر Docker لإدارة الحاويات.