إن أداة بودمان Podman هي أداة مقدمة ومدعومة من قبل توزيعة ريد هات Red Hat كبديل عن أداة دوكر Docker. فأداة بودمان شبيهةً بدوكر ويمكنك بدء استخدامها إن كنت على معرفة بدوكر.
عندما نأتي على ذكر الحاويات، ستخطر الأداة دوكر Docker في ذهنك، لكنها ليست الأداة الوحيدة للتعامل مع الحاويات. إذ ستجد أن أداة بودمان المقدمة من ريد هات أداة واعدة وتلبي احتياجاتك وليس عليك تعلم كيفية التعامل معها من الصفر، لأنها مشابهة لدوكر.
تهدف هذه السلسلة إلى تعريفك على أداة بودمان، كي تستطيع عند نهاية هذه المقالات، التعرف على الفرق بين دوكر وبودمان، وبدء استخدام بودمان عند العمل مع الحاويات.
ما ستتعلمه سلسلة التعرف على أداة بودمان Podman
سنتعلم في هذه السلسلة ما يلي:
- الفرق بين أداتي دوكر وبودمان.
- إنشاء الحاويات وحذفها باستخدام أداة بودمان.
- تفعيل حاويات بودمان تلقائيًا عند إقلاع النظام.
- تحديث الحاويات.
- مفهوم الحاويات محدودة الصلاحية Rootless containers.
- مفهوم بودمان كومبوز Podman Compose.
متطلبات هذه السلسلة
- معرفة مسبقة بمفهوم الحاويات Containers.
- تجربة مسبقة في التعامل مع دوكر.
- خبرة في التعامل مع سطر الأوامر أو الطرفية Terminal في لينكس Linux.
سنناقش في مقال اليوم الفرق بين أداتي دوكر وبودمان بالتفصيل، حيث يترافق مصطلح الحاويات Containers في ذهننا مع أداة دوكر Docker، لكن دعونا نتعرف في مقالنا على الفرق بينها وبين أداة بودمان Podman التي ازداد استخدامها مع الحاويات.
ومع انتشار استخدام الحاويات أصبحت أداة دوكر، التي ظهرت في عام 2014، أشهر أداة لإدارة الحاويات. ونشرت شركة ريد هات Red Hat في عام 2018، أداة بودمان كبديل عن دوكر. وبما أن الأداتين لهما الغرض نفسه، سنتعرف في هذا المقال على مزايا كل منهما.
مفهوم الحاويات
لنفترض أنك تعمل كمهندس برمجيات وطُلِب منك نشر مجموعة برامج ذات مهام حرجة. ماذا ستفعل لو كان البرنامج الأول والبرنامج الثاني لهما نفس الاعتمادية dependency ولكنهما يعملان على إصدارات مختلفة من نفس الاعتمادية؟ أو لو كانت تبعية البرنامج الأول تتعارض مع الاعتمادية البرنامج الثاني؟
في هذه الحال عليك نشرهما في جهازين افتراضيين Virtual Machine مختلفين، لكن هذا يلغي قابلية التوسع scalability، لأنه عند تشغيل جهازين افتراضيين على نفس الجهاز، سيرث البرنامج 50% فقط من إجمالي قدرة الجهاز الحاسوبية. وعند زيادة عدد البرامج من برنامجين إلى عشرة سيتضح لك أن هذا الحل غير فعّال.
حيث إن إحدى مساوئ الآلات الافتراضية هي أنها تعمل بنظام تشغيل كامل، وهذا يُعد أمرًا سلبيًا في حالتنا. فلو كان عندنا عشرة أجهزة افتراضية تعمل بنظام تشغيل ريد هات RHEL، سيصبح عندنا عشر نسخ من نفس الثنائيات binaries، وسيؤدي ذلك إلى استهلاك غير فعّال لذاكرة الوصول العشوائي RAM. حتى إن أبسط عملية تثبيت installation ستحجز أكثر من 4 جيجابايت من مساحة القرص لكل جهاز افتراضي.
لذلك بدلًا من استخدام جهاز افتراضي، حيث يكون لديك نظام تشغيل كامل على الجهاز بالإضافة إلى برنامجك واعتمادياته، يمكنك استخدام صورة الحاوية container image. إذ تحتوي صور الحاوية على البرنامج واعتمادياته فقط. ومن مزايا صور الحاويات أن حجمها يكون عادةً أقل من 300 ميجابايت.
فالمشكلة تكمن في طبيعة عمل الآلات الافتراضية؛ فعندما تنشئ آلةً افتراضية، تُنشَأ نسخة افتراضية من العتاد hardware. أي نسخة افتراضية من وحدة المعالجة المركزية وذاكرة الوصول العشوائي، وذاكرة التخزين والموارد الأخرى، ولا بد أن لهذا حمل على الجهاز.
أما عند استخدام الحاويات، تُنشَأ نسخ من البرنامج مع اعتماديّاته، وهذا له حمل منخفض مقارنةً بالآلات الافتراضية.
الغرض من استخدام دوكر أو بودمان
ربما استخدمت برنامج فيرتشوال بوكس VirtualBox المُقدَّم من أوراكل Oracle لإدارة الآلات الافتراضية، والذي يُتيح لك إنشاء آلات افتراضية وتشغيلها أو إيقافها، وتعديلها، وحذفها. تُتيح كل من أداتي دوكر وبودمان ذلك، ولكنها تتعامل مع البرامج الموجودة في حاويات، وليس الآلات الافتراضية.
وعلى الرغم من أن كِلا الأداتين تعملان وفق فلسفتين مختلفين، إلا أن كلتاهما تساعدان على إدارة الحاويات. لذلك سنتعرف الفروق بينهما وأي منهما هو الأفضل وفقًا لغرض الاستخدام الذي تريده.
دوكر أم بودمان
يُعد كل من دوكر و بودمان من البرامج الممتازة لإدارة الحاويات. وعندما أعلنت شركة ريد هات عن طرحها لبودمان كبديل عن دوكر قالت إن بودمان متوافق مع واجهة سطر أوامر دوكر، أي إن الانتقال من دوكر إلى بودمان لا يتطلب تغييرات كبيرة على الشيفرة البرمجية. هذا يعني أنه يمكنك استبدال أمر docker بالأمر podman وسيعمل البرنامج.
ولكن ثمة بعض الاختلافات الأساسية، التي سنتعرف عليها:
أولًا، مفهوم البرنامج الخفي Daemon
إن الفرق الرئيسي الذي يميز بين أداتي دوكر وبودمان هو طريقة عملهما على نظام التشغيل. حيث تعمل نواة دوكر Docker core كبرنامج خفي dockerd، أي إنه يعمل دائمًا في الخلفية ويدير الحاويات. أما أداة بودمان فتشبه البرنامج العادي؛ أي إنه يبدأ العمل عند تنفيذ إجراء ما فيه (بدء أو إيقاف حاوية). تتميز طريقة عمل دوكر المعتمدة على البرنامج الخفي Daemon-based approach بما يلي:
- يتيح تشغيل الحاويات تلقائيًا وبسهولة عند تشغيل النظام.
- لا حاجة إلى مدير خدمة خارجي مثل systemd نظرًا لأن دوكر هو برنامج خفي. لكن هذا لا يعني أن أداة بودمان سيئة، إليك المزايا التي تتميز بها أداة بودمان عن دوكر:
- عند تعطل برنامج دوكر الخفي، فستكون حالة الحاويات غير معروفة. لكن يمكن تجنب ذلك عند استخدام أداة بودمان.
- يمكنك استخدام systemd لإدارة الحاويات، إذ يمنحك ذلك قدرة غير محدودة على ضبط وإدارة الحاويات مقارنةً بدوكر.
- يتيح ربط بودمان مع systemd تحديث الحاويات قيد التشغيل بأقل وقت توقف عن العمل downtime. كما يمكنك تلافي التحديثات السيئة.
ثانيًا، الأمان Security
إن أهم سبب لاستخدام بودمان بدلًا من دوكر هو الأمان، إذ طُرح بودمان كبديل أكثر آمنًا من دوكر. فإذا كنتَ مهتمًا بالأمان، فستجذبك اثنتان من ميزات بودمان الأساسية. ذكرنا آنفًا أن ما يميز بودمان عن دوكر هو أن بودمان لا يعمل كبرنامج خفي. أما الميزة الأساسية الثانية لبودمان هي أنه يمكنه تشغيل الحاويات دون صلاحيات الوصول إلى الجذر root. هذا يعني أنك لست بحاجة إلى امتيازات المستخدم المميز superuser لإدارة الحاويات. والآن، إليك ثلاثة أسباب تجعلك تفضل استخدام بودمان بدلًا عن دوكر إن كنت مهتمًا بالحصول على مستوى أعلى من الأمن.
السبب الأول، يعمل الأمر dockerd كمستخدم جذر
كما تعلم فإن نواة دوكر تعمل كبرنامج نظام خفي system daemon، أي كبرنامج ينفذه المستخدم المسؤول أو الجذر root user. سبق وذكرنا فوائد البرنامج الخفي، لكن ثمة بعض المشاكل الأمنية عند تشغيل البرنامج الخفي كمستخدم جذري. أولًا، إذا اختُرق برنامج دوكر الخفي (dockerd)، فيمكن لأحدهم أن يخترق نظامك من خلال الوصول إلى الجذر. ولا شك أنك لا تود حدوث ذلك. وهنا تتضح ميّزة بودمان إذ إنه لا يستخدم برنامجًا خفيًا وليس له متطلبات صارمة للوصول إلى الجذر. وهذا يقودنا إلى السبب الثاني.
السبب الثاني، يدعم بودمان الحاويات دون صلاحيات جذر
ربما سمعت أن بودمان يدعم تشغيل الحاويات دون الوصول إلى الجذر أو ما يعرف Root-less containers، وهذا أمر صحيح وأكثر أمنًا. والآن، لنفترض أن برنامج دوكر الخفي آمن، وأن صورة الحاوية التي تستخدمها فيها ثغرة أمنية. ولكن المطور لا يعرف ذلك. إذا شَغّلتَ هذه الصورة في حاوية تابعة للمستخدم الجذر، فاعلم أن الحظ ليس حليفك. أما عند استخدام بودمان، فيمكنك تشغيل الحاوية دون الحاجة إلى امتيازات الجذر. هذا يعني أنه إن احتوت صورة الحاوية على ثغرة أمنية، فلن يتعرض للخطر سوى المستخدم الذي يملك تلك الحاوية. أما بقية مستخدمي النظام فهم بأمان، ولا سيما المستخدم الجذر. وعلى الرغم من أن دوكر حصل مؤخرًا على دعم لتشغيل الحاويات محدودة الصلاحية Rootless containers ، لكن لا يزال ينقصه بعض الميزات، وهي أن دعم AppArmor غير موجود. وهو نظام التحكم الإلزامي بالوصول (MAC) الافتراضي الخاص بتوزيعتي ديبيان وأوبنتو
السبب الثالث، تحديث الصور تلقائيًا
قد يخطر في ذهنك أن تحديث الصور تلقائيًا لا يمكن أن يكون ميزة، لكنها كذلك. تذكر السبب الثاني الذي ذكرناه وافترض أن المطورين يعلمون بوجود الثغرة الأمنية، ثم أصدروا إعلانًا بذلك ونشروا الصورة المصححة. لكن ميزة التحديث التلقائي ليست مدمجة built in في دوكر، فماذا عن بودمان؟ يعتمد الجواب على كيفية تعريفنا لكلمة "مدمجة". نظرًا لأنه ليس لبودمان برنامج خفي، فإنه لا يمكنه إجراء فحوصات منتظمة للحصول على التحديثات. لكن بما أن بودمان هو أحد منتجات ريد هات Red Hat، فيمكن تحديث الحاويات تلقائيًا عن طريق systemd لأنه يتوافق معه، وهذا ما سنتحدث عنه في مقالنا التالي من هذه السلسلة.
ملاحظة: لا تعني الأسباب التي ذكرناها أن دوكر غير آمن وأنه يجب على الجميع استخدام بودمان، إذ لا يوجد شيء آمن بنسبة 100%. لكن وجب تسليط الضوء عليها من باب الاحتياط وأخذ الحذر.
ثالثًا، النهج المتبع في بودمان
ربما لاحظت أن دوكر يتّبِع نهج "الحل الواحد" وأن بودمان يتّبع نهجًا مختلفًا. وهذا يعني أنه ليس عليك سوى تثبيت الملف الثنائي binary لدوكر على نظامك. ويمكنك استخدام الأمر docker لإنشاء الصور ونشرها (إلى السجلات مثل سجل hub.docker.com) وإدارة الحاويات. ولكن بالنسبة لبودمان، نشرت شركة ريد هات Red Hat ثلاثة ثنائيات منفصلة. فعليك استخدام الأمر buildah لبناء الصور. ولنشرها على سجل مثل سجل hub.docker.com، فعليك استخدام الأمر skopeo. ولإدارة الحاويات، فاستخدم الأمر podman. كلا النهجين يؤدي الغرض المرجو منه، إذًا فالأمر يعتمد على ما تفضّله، هل تفضّل استخدام نهج الحل الشامل الذي يقدمه دوكر أم تفضل نهج الحل المتشعب لبودمان.
رابعًا، أداة دوكر سوارم Docker Swarm
تُعدّ أداة دوكر سوارم Docker Swarm مفيدةً لتوسيع نطاق الحاويات باستخدام عدة أجهزة حقيقية وافتراضية. إذ يمكنك وضع عدة حواسيب ضمن "سرب" أو swarm من أجل غرض محدد. فيمكن أن تخصص سربًا للتعامل مع طلبات قاعدة البيانات فقط، وسربًا آخر للتعامل مع خادم ويب. في حين أن هذه الميزة غير متوفرة في بودمان، إلا أنه يمكنك الاستفادة منها باستخدام Kubernetes. ويمكننا القول إن Kubernetes يستخدم على نطاق أوسع من Docker Swarm، وعند الحاجة إلى التوسع واستخدام عدة أجهزة، فإن Kubernetes يلبي احتياجاتك على أفضل وجه.
الخاتمة
تُعد أداة دوكر مرادفةً للحاويات. لكن أنشأت شركة ريد هات Red Hat أداة بودمان لإدارة الحاويات للتغلب على بعض أوجه القصور في عمل دوكر. وتوافق بودمان مع أوامر دوكر يُسهل التوجه نحو استخدامها دون الحاجة إلى ترك ما تعلمته عن دوكر. لا يعني ذلك أن المسؤولين عن أداة دوكر لا يعملون على تحسينها، إذ إن إضافة ميزة الحاويات محدودة الصلاحية rootless containers هي خير دليل على ذلك. والآن فإن الخيار متروك لك في استخدام الأداة التي تفضلها، وللتعرف على المزيد حول أداة بودمان، تابع مقالنا التالي. ترجمة وبتصرّف للمقال Understanding the Differences Between Podman and Docker من سلسلة Container Management With Podman.
تعليقات
إرسال تعليق