على الرغم من وجود العديد من المدونات والبرامج التعليمية الجيدة على Podman و Buildah ، إلا أن مستخدمي Docker يفتقرون بوضوح إلى تفسيرات واضحة وموجزة حول كيفية تحولهم إلى Podman ، لماذا هناك حاجة إلى Buildah في قضايا أخرى من هذا النوع.
سنحاول الإجابة على هذه الأسئلة ونخبرك بكيفية الترحيل بسلاسة من Docker إلى Podman.
كيف يعمل عامل الميناء
لنبدأ بتوضيح كيفية عمل Docker من أجل فهم سبب ظهور Podman و Buildah. كما تعلم ، لا تعمل أوامر Docker إلا عند تشغيل عملية البرنامج الخفي Docker. يبدو أن الفكرة مع الشيطان هي جمع كل الأشياء الرائعة التي يقوم بها Docker في مكان واحد ، وفي الوقت نفسه تنظيم واجهات برمجة التطبيقات المفيدة للتعامل معها من أجل المستقبل. كما هو موضح في الشكل أدناه ، يحتوي البرنامج الخفي Docker على جميع الوظائف اللازمة لأداء المهام التالية:
- عمليات الشد والدفع عند العمل مع سجل الصور ؛
- إنشاء نسخ من الصور في حاوية التخزين المحلية وإضافة طبقات إلى هذه الحاويات ؛
- إجراء تغييرات في الحاويات وإزالة صور الحاوية من المستودع المحلي على المضيف ؛
- اطلب إلى kernel OS لبدء تشغيل الحاوية في مساحة الاسم المقابلة ، cgroup ، إلخ.
في الجوهر ، يعتني برنامج Docker بجميع الأعمال من خلال السجلات والصور والحاويات والنواة. وأنت تخبره فقط بما يجب القيام به من خلال واجهة سطر الأوامر (CLI).
هنا لن نزن إيجابيات وسلبيات هذا النهج ، عندما يتم تجميع كل شيء في عملية شيطانية واحدة. يمكن تقديم العديد من الحجج لصالحه ، وفي وقت ظهور Docker ، كان من المنطقي تمامًا. ومع ذلك ، مع الاستخدام الفعال لـ Docker ، بدأت الأسئلة تثور عليه ، على سبيل المثال ، مثل:
- تعني العملية الواحدة نقطة فشل واحدة ؛
- تمتلك عملية الخفي جميع العمليات الفرعية (حاويات التشغيل) ؛
- عندما يغادر الشيطان ، تبقى العمليات التابعة أيتاماً ؛
- حاوية التجمع لديه ثقوب الأمن.
- لتنفيذ أي عمليات Docker ، يحتاج المستخدم (المستخدمين) إلى امتيازات الجذر الكاملة.
كانت هناك شكاوى أخرى. قد لا يتفق المرء مع هذا أو يقول إن أوجه القصور هذه قد تم القضاء عليها بالفعل ، لكننا لن نجادل. يعتقد مطورو Podman أنهم نجحوا في حل العديد من هذه المشكلات ، وإذا كنت ترغب في الاستفادة من Podman ، فهذا المقال مناسب لك.
جوهر Podman هو التفاعل مع سجل الصور ، مع حاويات وتخزين الصور ، وكذلك مع Linux kernel ، ليس من خلال البرنامج الخفي ، ولكن مباشرة من خلال عملية runC ، المسؤولة عن إطلاق الحاويات.
الآن وبعد أن اكتشفنا جزئيا دوافع مطوري Podman ، حان الوقت لمناقشة معنى الانتقال إلى Podman للمستخدم. وهنا نحتاج إلى فهم وتوضيح (سنفعل ذلك أدناه) ما يلي:
- يستبدل Podman Docker. في الوقت نفسه ، لم يعد من الضروري بدء نوع من عملية الخفي ، مثل برنامج Docker daemon ؛
- تعمل أوامر Docker المألوفة بنفس الطريقة في Podman؛
- لا يقوم Podman بتخزين الحاويات والصور في نفس مكان Docker ؛
- Podman و Docker الصور متوافقة.
- في بيئات Kubernetes ، Podman قادر على أكثر من Docker.
- وأيضاً سنقوم بتحليل ما هو Buildah ولماذا هو مطلوب.
تركيب بودمان
إذا كنت تستخدم Docker ، فيمكنك إزالته عندما تقرر إجراء التبديل. ومع ذلك ، يمكنك ترك Docker أثناء محاولة Podman. هناك بعض
الدروس المفيدة
والعروض التوضيحية الرائعة التي قد يكون من المفيد قراءتها ومشاهدتها للمبتدئين حتى تتمكن من فهم عملية الانتقال بشكل أفضل. مثال واحد في العرض التوضيحي يتطلب Docker لإظهار التوافق.
لتثبيت Podman على
Red Hat Enterprise Linux 7.6 أو إصدار أحدث ، استخدم ما يلي ؛ إذا كنت تستخدم Fedora ، فاستبدل yum بـ dnf:
# yum -y install podman
يستخدم Podman نفس أوامر Docker
تم تصميم Podman ليكون من السهل التبديل من Docker. لذلك ، تعمل جميع الفرق التي تعرفها من Docker بنفس الطريقة في Podman. علاوة على ذلك ، يُقال إن البرامج النصية لاستدعاء Docker يجب أن تعمل بشكل جيد إذا قمت بإنشاء الاسم المستعار المناسب ، مثل هذا: alias docker = podman - فقط جربه. بالطبع ، قبل ذلك تحتاج إلى إيقاف Docker (systemctl stop docker). بالإضافة إلى ذلك ، يمكنك تثبيت حزمة podman-docker ، والتي ستنفذ جميع التحويلات اللازمة لك. ببساطة يضع البرنامج النصي في / usr / bin / docker الذي يقوم بتشغيل Podman بنفس الحجج التي يستخدمها Docker.
أوامر Docker المعتادة ، مثل السحب ، والدفع ، والبناء ، والتشغيل ، والالتزام ، والعلامة ، وما إلى ذلك ، كلها في Podman. انظر دليل Podman لمزيد من المعلومات. الفرق المهم هو أنه في Podman أضافت بعض الفرق أعلام الراحة ، على سبيل المثال ، - all (-a) إشارات لأوامر rod و podman rmi ، والتي سيجدها الكثيرون مفيدة للغاية.
بالإضافة إلى ذلك ، يمكن تشغيل Podman كمستخدم عادي ، دون امتيازات الجذر. صحيح ، حتى الآن لا يعمل هذا إلا في Fedora و مع Podman 1.0 ، وفي RHEL يجب أن يظهر بدءًا من الإصدارين 7.7 و 8.1. لقد أصبح هذا ممكنًا بفضل التحسينات في حماية مساحة المستخدمين. إن التشغيل كمستخدم منتظم يعني أنه بشكل افتراضي ، يقوم Podman بتخزين الصور والحاويات في الدليل الرئيسي للمستخدم ، وسوف نناقش هذا بمزيد من التفصيل في القسم التالي. لمعرفة المزيد حول كيفية تشغيل Podman دون امتيازات الجذر ، راجع مقال دان والش
كيف يعمل Podman بدون جذور؟ .
Podman وصور الحاويات
عند إدخال الأمر podman images لأول مرة ، من المرجح أن تكون محبطًا ، حيث لن ترى أي صور Docker تم تنزيلها بالفعل على جهاز الكمبيوتر الخاص بك من قبل. في الواقع ، يوجد مستودع Podman المحلي في مجلد / var / lib / container ، وليس في دليل / var / lib / docker. وقد تم ذلك ليس فقط ، ولكن كجزء من بنية تخزين جديدة تلبي معايير مبادرة الحاويات المفتوحة (OCI).
في عام 2015 ، أنشأت Docker ، و Red Hat ، و CoreOS ، و SUSE ، و Google ، وغيرها من اتجاهات حاويات Linux ، مبادرة Open Container ، وهي هيئة مستقلة لإدارة مواصفات معايير تنسيق صور الحاويات ووقت تشغيلها. كجزء من OCI ، تم إنشاء حاويات / صورة ومشاريع تخزين / حاويات على GitHub.
نظرًا لأنه يمكن تشغيل Podman بدون امتيازات الجذر ، فإنه يحتاج إلى مكان منفصل لتسجيل الصور. لذلك ، يوجد مستودع Podman في الدليل الرئيسي للمستخدم ~ / .local / share / container. يساعد هذا في تجنب الموقف حيث يمكنهم كتابة كل شيء في / var / lib / Container ، وفيما يتعلق بالممارسات الأخرى التي تشكل خطورة من وجهة نظر الأمان. بالإضافة إلى ذلك ، أصبح لدى كل مستخدم الآن مجموعة من الحاويات الخاصة به منفصلة ، بحيث يمكن لعدة مستخدمين العمل في وقت واحد على المضيف في وقت واحد. بعد الانتهاء من العمل ، يمكن للمستخدمين الضغط على السجل العام لإتاحة صورهم للآخرين.
عند التبديل من Docker إلى Podman ، تكون معرفة مسارات موقع الحاوية الجديدة مفيدة لتصحيح الأخطاء ، وكذلك عندما تريد مسح المستودع المحلي باستخدام الأمر rm -rf / var / lib / Container للبدء من جديد. ومع ذلك ، من خلال التبديل إلى Podman ، من المحتمل أن تبدأ في استخدام الخيار all-new لأوامر podman rm و podman rmi بدلاً من هذا الأمر.
توافق الحاوية بين Podman وأوقات التشغيل الأخرى
على الرغم من المواقع المختلفة للمستودعات المحلية ، يقوم كل من Docker و Podman بإنشاء صور حاويات متوافقة مع معيار OCI. يمكن لـ Podman استخدام سجلات الحاويات الشائعة ، مثل Quay.io أو Docker Hub ، وكذلك السجلات الخاصة في كلا الاتجاهين (الدفع والسحب). على سبيل المثال ، مع Podman ، يمكنك تنزيل وتشغيل أحدث صور Fedora من Docker Hub. إذا لم تقم بتحديد سجل ، فسيقوم Podman افتراضيًا بالبحث في السجلات المدرجة في ملف registries.conf ، باتباع الترتيب المحدد في هذا الملف. في البداية ، الأول في هذا الملف هو سجل Docker Hub.
$ podman pull fedora:latest $ podman run -it fedora bash
يمكن تنزيل الصور التي تم تحميلها إلى السجل باستخدام Docker وتشغيلها باستخدام Podman. على سبيل المثال ، إذا أنشأنا صورة myfedora باستخدام Docker وقمنا بتحميلها إلى مستودع Quay.io (ipbabble) ، فيمكنك تنزيلها باستخدام Podman ، وإليك الطريقة:
$ podman pull quay.io/ipbabble/myfedora:latest $ podman run -it myfedora bash
يسمح لك Podman بنقل الصور بسهولة وأمان بين الدلائل / var / lib / docker و / var / lib / container باستخدام أوامر الدفع والسحب ، على سبيل المثال:
$ podman push myfedora docker-daemon:myfedora:latest
من الواضح أنك إذا حذفت docker-daemon في هذا المثال ، فسيتم إرسال رسالة الإرسال إلى Docker Hub. إذا قمت بتحديد quay.io/myquayid/myfedora ، فسيتم تحميل الصورة إلى سجل Quay.io (هنا myquayid هو اسم حسابنا على Quay.io):
$ podman push myfedora quay.io/myquayid/myfedora:latest
إذا قررت أنك مستعد للتخلي عن Docker ، لإلغاء تثبيته ، فما عليك سوى إيقاف تشغيل البرنامج الخفي ثم إزالة حزمة Docker باستخدام مدير الحزم. ولكن قبل ذلك ، تأكد من تنزيل جميع الصور التي تحتاج إليها باستخدام Docker إلى السجل الخارجي (وليس المحلي) بحيث يمكنك تنزيلها من هناك لاحقًا. أو يمكنك استخدام Podman لتنزيلها من مستودع Docker المحلي إلى مستودع Podman OCI المحلي. على سبيل المثال ، في RHEL ، يتم نقل صورة فيدورا مثل هذا:
# systemctl stop docker # podman pull docker-daemon:fedora:latest # yum -y remove docker # optional
يجعل Podman من السهل التبديل إلى Kubernetes
يقدم Podman عددًا من الميزات الإضافية - مقارنة بميزة Docker - التي تعد مفيدة للمطورين ومشغلي تقنية المعلومات عند العمل مع Kubernetes ، على وجه الخصوص ، الأوامر المفيدة التي لا يتوفر عليها Docker. إذا كنت معتادًا على Docker وتفكر في الانتقال إلى Kubernetes / OpenShift كمنصة للحاويات ، فسيكون Podman في متناول يديك.
يمكن لـ Podman إنشاء ملف Kubernetes YAML استنادًا إلى حاوية قيد التشغيل باستخدام الأمر podman في إنشاء kube. وعند تصحيح الأخطاء قيد التشغيل ، بالإضافة إلى الأوامر القياسية للعمل مع الحاويات ، يمكنك أيضًا استخدام الأمر podman pod. لمزيد من المعلومات حول كيفية مساعدة Podman في التحول إلى Kubernetes ، راجع مقال Brent Baude يمكن لـ Podman الآن تسهيل الانتقال إلى Kubernetes و CRI-O.
Buildah - ما هو ولماذا
ظهر Buildah في وقت سابق من Podman. وهذا في بعض الأحيان يشجع مستخدمي Docker: "لماذا يتحدث مدافعو Podman فجأة عن Buildah؟ بودمان لا يعرف كيف يصنع؟
نسارع إلى طمأنة ، Podman ، ويفعل ذلك تماما مثل Docker. بمعنى أنه يمكن تنفيذ التجميع إما باستخدام Dockerfile و podman build ، أو يمكنك بدء الحاوية وإجراء التغييرات اللازمة ثم الالتزام بها (تنفيذ الالتزام) ، وإنشاء علامة جديدة في صورة الحاوية. في تفسيرنا ، Buildah هي مجموعة ممتدة من الأوامر لإنشاء وإدارة الصور الحاوية ، وبالتالي فهي توفر تحكم أكثر دقة عند التعامل مع الصور. يحتوي الأمر Podman build جزئيًا على وظيفة Buildah ويستخدم نفس كود البرنامج للبناء مثل Buildah نفسه.
الطريقة الأكثر فاعلية لاستخدام Buildah هي كتابة نصوص Bash لإنشاء صور ، تمامًا مثل كتابتك لـ Dockerfile.
أما بالنسبة إلى التسلسل الزمني لظهور Buildah و Podman ، فقد وقعت الأحداث على النحو التالي تقريبًا. عندما تعلمت Kubernetes العمل مع CRI-O استنادًا إلى معيار OCI الخاص بأوقات تشغيل الحاويات ، لم تعد هناك حاجة إلى برنامج Docker. وهذا يعني أنه لم يعد من الضروري تثبيت Docker على جميع عقد نظام Kubernetes لتشغيل القرون والحاويات الموجودة فيه. بإمكان Kubernetes الآن الاتصال بـ CRI-O ، ويمكن لهذا الشخص تشغيل RunC مباشرة ، والذي بدوره يبدأ عمليات الحاوية. ومع ذلك ، إذا كنا في نفس الوقت نريد استخدام نفس مجموعة Kubernetes ليس فقط للإطلاق ، ولكن أيضًا لتجميع الحاويات (مثل ، على سبيل المثال ، في OpenShift) ، فإننا نحتاج إلى أداة بناء جديدة لا تعتمد على البرنامج الخفي Docker و ، نتيجة لذلك ، لن يتطلب تثبيت Docker. بالإضافة إلى ذلك ، فإن هذه الأداة ، التي تم إنشاؤها على أساس مشاريع الحاويات / التخزين ومشروعات الحاويات / الصور ، ستقضي على المخاطر الأمنية المرتبطة بالمقبس المفتوح لعبة Docker أثناء التجميع ، ويشعر العديد من مستخدمي Docker بالقلق إزاء هذه المخاطر.
وأصبح Buildah مثل هذه الأداة الجديدة (يقرأ الاسم مثل "build" ويحاكي لهجة بوسطن لمدير المشروع Dan Walsh عند نطق كلمة "builder"). يمكن العثور على مزيد من المعلومات حول Buildah في buildah.io ، وكذلك المدونات وأدلة الارتباط في نهاية هذه المقالة.
هناك بضعة تفاصيل أخرى لمعرفة ما إذا كنت تريد استخدام Buildah:
- يوفر تحكمًا أكثر دقة عند إنشاء طبقات الصور. على وجه الخصوص ، يتيح لك القيام بما أراده كثير من مستخدمي الحاوية منذ فترة طويلة - إجراء العديد من التغييرات دفعة واحدة باستخدام طبقة واحدة فقط.
- تشغيل Buildah وتشغيل Podman هما شيئان مختلفان. نظرًا لأن Buildah مصمم لإنشاء صور ، فإن أمر التشغيل الخاص به هو نفسه أمر RUN في Dockerfile. يتذكر ويليام هنري ، أحد مطوري Buildah ، كيف تم التوصل إلى هذا الحل: "كنت أتذمر بطريقة أو بأخرى أن بعض المنافذ أو المنافذ لم تنجح على الإطلاق كما توقعت. قام دان والش (@ رشدان) بوزن كل شيء وقال إن Buildah يجب ألا تعمل مع الحاويات بهذه الطريقة على الإطلاق. كل شيء ، لا يوجد المزيد من تعيينات المنفذ ولا وحدات تخزين التحميل. نزيل هذه العلامات ونستخدم تشغيل buildah بدلاً من ذلك لتشغيل الأوامر المطلوبة عند إنشاء صور حاوية ، على سبيل المثال ، buildah تشغيل dnf -y install nginx. "
- Buildah يمكن أن تخلق الصور من نقطة الصفر (صور الصفر). هذا هو ، الصور التي لا يوجد فيها شيء ، حرفيا. في الواقع ، إذا نظرت إلى تخزين الحاوية الذي تم إنشاؤه كنتيجة لأمر buildah من الصفر ، فسيكون هناك دليل فارغ. هذا مفيد للغاية من وجهة نظر إنشاء صور فائقة خفيفة الوزن تحتوي فقط على الحزم الضرورية لتشغيل التطبيق.
لماذا بناء من الصفر؟ دعنا نقارن صورة تطوير تطبيق Java مع صورته لبيئة الإنتاج أو لبيئة التدريج. في مرحلة التطوير ، قد تحتوي الصورة على مترجم Java ، Maven ، وغيرها من الأدوات التي يحتاجها المطور. ولكن عند الترجمة إلى الإنتاج ، يجب أن تظل مدة تشغيل Java والحزم الخاصة بك فقط في الصورة. وبالمناسبة ، لإزالة الزائدة ، لا تحتاج إلى مدير الحزم على الإطلاق ، مثل DNF / YUM ، ولا تحتاج حتى إلى Bash - يمكنك القيام بكل شيء من خلال واجهة Buildah CLI ، كما هو مبين في الشكل أدناه ، حيث توجد الحاوية متعددة الطبقات التقليدية على اليسار والحاوية أحادية الطبقة على اليمين صورة الصفر. انظر
بناء صورة حاوية Buildah لـ Kubernetes و
Buildah التجريبي لمزيد من التفاصيل .
العودة إلى التسلسل الزمني. لذلك ، تعلمت Kubernetes العمل مع CRI-O و runC ، وبالنسبة للبناء الذي قمنا بتكديس Buildah - كل شيء ، من Docker على مضيف Kubernetes ، يمكنك رفضه؟ لا ، لا يزال تصحيح الأخطاء. كيف يمكن حل مشاكل الحاويات إذا لم يكن لدى المضيف الأدوات المناسبة؟ لا تضع عامل الميناء على ذلك ، وإلا فإننا نعود مرة أخرى إلى الشيطان وكانت كل الجهود تذهب سدى. ثم يدخل Podman المشهد.
وهذا هو ، بودمان يحل مشكلتين في وقت واحد. أولاً ، يسمح لمشغلي تكنولوجيا المعلومات بفحص الحاويات والصور باستخدام أوامر مألوفة. وثانيا ، يعطي هذه الأدوات نفسها للمطورين. نتيجةً لذلك ، يمكن لجميع مستخدمي Docker - المطورين والمشغلين على حد سواء - التبديل إلى Podman وأداء المهام التي كانوا يستخدمونها في السابق بهدوء ، وكذلك حل سلسلة كاملة من المهام الجديدة.
الموارد اللازمة:
- موقع لمشاريع Podman.io و Buildah.io.
- المشاريع في github.com/containers (تواصل ، ادرس المصدر وشاهد ما هو قيد التطوير:
- libpod (Podman) ؛
- buildah.
- صورة (رمز للعمل مع صور حاوية OCI) ؛
- تخزين (رمز للتخزين المحلي للصور الحاوية).
روابط مفيدة: