البحث في الموقع

ستتعلم في هذا المقال كيفية التعامل مع الحاويات محدودة الصلاحية Rootless Containers باستخدام أداة بودمان. إن كنت تستخدم الحاويات لنشر البرمجيات، أو تستخدم أداة بودمان، أو أنك ترغب في رفع مستوى الأمان عن طريق تشغيل الحاويات محدودة الصلاحية rootless containers، فهذا المقال مناسب لك. ما هي أداة بودمان Podman إن أداة بودمان Podman هي أحد منتجات شركة Red Hat طُرِحَت كبديل فعّال عن أداة دوكر Docker ويمكنها أداء 99% من المهام التي تؤديها أداة دوكر. بعض ميزات بودمان هي دعم الحاويات محدودة الصلاحية rootless containers، واستخدام نموذج fork/exec لتشغيل الحاويات، وأنه لا يعمل وفق مبدأ البرنامج الخفي أي إنه daemon-less، وثمة كثير من الميزات الأخرى. أما مزايا الحاويات محدودة الصلاحية فهي واضحة، فهي لا تحتاج لصلاحيات الجذر الذي يملك وصولًا كاملًا إلى جميع موارد وملفات النظام كي تعمل، لذلك فإن تشغيلها أكثر أمانًا. تشغيل حاويات بودمان محدودة الصلاحية Rootless Containers إذا كنت متمرسًا في مجال تقنية المعلومات، فمن المحتمل أنك وقعت في أحد الخطأين التاليين: تشغيل الأمر docker باستخدام Sudo، وبالتالي زيادة امتيازاته. إضافة مستخدم محدود الصلاحيات non-root إلى مجموعة دوكر docker group. تلك أخطاء تُضِر بأمان النظام بصورة كبيرة؛ لأنك تسمح لبرنامج دوكر الخفي Docker daemon بالوصول إلى جهازك. وهذا يعرضك للخطر بطريقتين: يعمل برنامج دوكر الخفي (dockerd) كجذر، فإذا كانت ثمة ثغرة أمنية فيه، سيكون نظامك بكامله عرضةً للخطر لأن dockerd هي عملية تابعة للمستخدم الجذر. قد تحتوي الصورة التي تستخدمها على ثغرات أمنية. تخيّل ماذا سيحدث عند استخدام هذه الصورة بواسطة حاوية تعمل كعملية للمستخدم الجذر root process. يمكن لأحد المخترقين استخدام هذه الصورة للوصول إلى كافة موراد النظام. الحل بسيط، عليك الامتناع عن تشغيل البرامج بصلاحيات الجذر، حتى لو كنت تثق بها. تذكر أنه لا يوجد شيء آمن بنسبة 100%. وهنا تأتي ميزة بودمان في إدارة الحاويات دون الحاجة إلى الوصول إلى الجذر. فعند تشغيل حاوية باستخدام بودمان كمستخدم غير جذر، لن تحصل تلك الحاوية على امتيازات إضافية، ولن يطلب منك بودمان كلمة مرور sudo. إليك المزايا التي توفرها أداة بودمان عند إدارة الحاويات محدودة الصلاحية root-less containers: يمكنك تخصيص مجموعة من الحاويات المشتركة لكل مستخدم محلي. (على سبيل المثال، بإمكانك تشغيل Nextcloud وMariaDB لدى المستخدم nextcloud_user وتشغيل الحاويات Gitea وPostgreSQL لدى المستخدم gitea_user). حتى لو اختُرِقَت الحاوية، فلا يمكن التحكم بالنظام المضيف بكامله، لأن المستخدم المسؤول عن الحاوية ليس جذرًا. لكنه لن يعود صالحًا للاستخدام. قيود استخدام حاويات بودمان محدودة الصلاحية عند استخدام أداتي بودمان ودوكر مع صلاحيات المستخدم الجذر أي بنمط عمل root-full، فأنت تمنحها امتيازات على مستوى المستخدم المسؤول أو المميز super-user. وهذا ليس أمرًا محمودًا، ولكنه يضمن أن جميع الوظائف تعمل على النحو المطلوب. ومن الناحية الأخرى، ثمة بعض القيود على تشغيل حاويات بودمان بدون امتيازات الجذر، إليك أهمها: لا يمكن تشارك صور الحاويات بين المستخدمين إذا سحب المستخدم user0 صورة الحاوية nginx:stable-alpine فيجب على المستخدم user1 سحبها بنفسه مرةً أخرى. لا توجد لحد الآن طريقة تسمح تشارك الصور بين المستخدمين، لكن يمكنك نسخ الصور من مستخدم لآخر باتباع هذا الدليل من شركة ريد هات Red Hat. لا يمكن ربط المنافذ ports binding ذوات الأرقام الأدنى من 1024، لكن ثمة طريقة لحل هذه المشكلة. لا يمكن للحاوية محدودة الصلاحية إرسال الطلب ping لأي من المضيفين hosts. لكن ثمة طريقة لحل هذه المشكلة. إذا عيّنت معرّفًا مميزًا UID لحاوية بودمان محدودة الصلاحية، فقد يفشل ذلك إن لم تسند المعرّف المميز UID إلى حاوية موجودة مسبقًا. إذًا، من الأفضل تشغيل بودمان من صدفة طرفية (shell) مستخدم موجود، والخيار الأفضل هو إنشاء خدمة systemd لتشغيلها تلقائيًا. تشغيل حاويات محدودة الصلاحية Rootless Containers باستخدام بودمان قبل أن تبدأ بتشغيل الحاويات محدودة الصلاحية، ثمة بعض المتطلبات التي عليك توفيرها. تثبيت حزمة slirp4netns تُستخدم الحزمة slirp4netns لتوفير خيارات الشبكة لوضع المستخدم user-mode networking لفضاءات أسماء الشبكة. يعد هذا الأمر ضروريًا كي تتفاعل الحاوية محدودة الصلاحية مع أي شبكة وبدونها لا يمكن للحاويات محدودة الصلاحية الاتصال بالإنترنت أو الشبكات الداخلية، مما يحد من فائدتها بشكل كبير. يمكنك تثبيت حزمة slirp4netns على التوزيعات المعتمدة على نظامي ديبيان Debian وأوبنتو Ubuntu باستخدام مدير الحزم apt: sudo apt install slirp4netns أما في التوزيعات المعتمدة على نظامي فيدورا Fedora وريد هات Red Hat فاستخدم مدير الحزم dnf لتثبيت الحزمة، على النحو التالي: sudo dnf install slirp4netns بالنسبة لمستخدمي Arch Linux فعليك استخدام الأمر pacman على النحو التالي: sudo pacman -Sy slirp4netns ضبط subuid و subgid على النحو الصحيح نظرًا لأن حاويات بودمان محدودة الصلاحية تُشَغّل بواسطة مستخدم موجود على النظام، فإن المستخدم يحتاج إلى إذن لتشغيل هذه الحاوية بمعرّف مميز UID مختلف عن معرف المستخدم. وهذا ينطبق أيضًا على معرّف المجموعة GID. يُمنح كل مستخدم نطاقًا من المعرفات التي يُسمح له باستخدامها، تذكر المعرفات الفريدة UID في الملف ‎‎/etc/subuid‎‎‎‎‎‎، أما معرفات المجموعات GID فتذكر في الملف ‎‎‎‎‎‎‎/etc/subgid‎. وصيغة الملف هي على النحو التالي: username:initial UID/GID allocated to user:range/size of allowed UIDs/GIDs فلنفرض أن اسم المستخدم pratham يريد مئة معرّف مميز، والمستخدم krishna يريد ألفًا، إذًا ستكون صيغة الملف ‎/etc/subuid على النحو التالي: pratham:100000:100 Krishna:100100:1000 يعني هذا أن المستخدم pratham يمكنه استخدام المعرّفات UID من المعرّف 100000 إلى 100100، والمستخدم krishna يمكنه استخدامها بدءً من المعرّف 100100 إلى 101100. يكون هذا عادةً مُعَدًا مسبقًا لكل مستخدم تنشئه، ويُحَدد للنطاق 65536 معرفًا قابلًا للاستخدام سواء كان معرفًا مميزًا UID أم معرّف مجموعة GID. ولكن، يجب أن تضبطه يدويًا في بعض الحالات. ولكن ليس عليك ضبط ذلك يدويًا لكل مستخدم، إذ يمكنك استخدام الأمر usermod لهذا الغرض. إليك صيغة الأمر المطلوبة: sudo usermod --add-subuids START-RANGE --add-subgids START-RANGE USERNAME والآن استبدل كل من السلسلة START و RANGE و USERNAME بما يناسبك. ** تنبيه:** احرص على ضبط سماحيات الملفين ‎/etc/subuid و‎/etc/subgid على القيمة 644 وأن يكونا تابعين للمستخدم الجذر root:root. ربط المنافذ ذات الأرقام الأدنى من 1024 إن استخدمت وكيلًا عكسيًا reverse proxy لبروتوكول SSL، فأنت تعلم أن المنفذين 80 و443 يجب أن يكونا متاحين لمزود الشهادات مثلLet's Encrypt. إذا حاولت ربط المنافذ الأقل من 1024 بحاوية بودمان محدودة الصلاحية، فستلاحظ أن ذلك غير متاح كميّزة جاهزة out of the box. إذ لا يُسمح للمستخدم غير الجذر بربط أي شيء على المنافذ الأدنى من المنفذ 1024. إذًا، كيف يمكن ربط المنافذ الأدنى بحاويات بودمان محدودة الصلاحية؟ عليك أولاً تحديد المنفذ الأدنى الذي تحتاجه. في حالتنا، تحتاج إلى المنفذين 80 و443 لنشر بروتوكول SSL، لذا فإن أقل منفذ تحتاجه هو المنفذ 80. والآن، أضف السطر التالي إلى الملف ‎/etc/sysctl.conf: net.ipv4.ip_unprivileged_port_start=YOUR_PORT_NUMBER ما ستفعله هو تغيير قيمة net.ipv4.ip_unprivileged_port_start إلى قيمة أدنى منفذ تحتاجه، إذًا عليك استبدال YOUR_PORT_NUMBER بالقيمة 80 كي تربط المنفذ 80 بحاوية محدودة الصلاحية. أين توجد صور الحاويات كما ذكرنا سابقًا فأحد قيود عمل أداة بودمان هي أنها لا تتيح مشاركة الصور بين المستخدمين. فيجب أن يسحب كل مستخدم الصورة، أو يجب نسخ الصورة من مستخدم لآخر. كلا الخيارين سيحجز ضعف أو أضعاف المساحة، حسب عدد نسخ الصور.حيث تُخَزّن صور حاويات المستخدم في المجلد الرئيسي، وبالتحديد داخل المجلد‎ ~/local/share/containers/storage/‎‎ والآن، بعد أن تحققتَ من توفر المتطلبات السابقة، يمكنك تشغيل الأمر podman run من صدفة خارجية non-root user's shell وإنشاء حاوية. سنستخدم خادم Caddy في مثالنا لنشر بروتوكول SSL. شغّل خادم Caddy في حاوية محدودة الصلاحية واربطه بمنفذ أدنى من المنفذ 1024 على النحو التالي: $ whoami pratham $ podman run -d --name=prathams-caddy -p 80:80 -p 443:443 caddy:alpine e6ed67eb90e6d0f3475d78b287af941bc873f6d62db60d5c13b1106af80dc5ff $ podman ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES e6ed67eb90e6 docker.io/library/caddy:alpine caddy run --confi... 2 seconds ago Up 2 seconds ago 0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp prathams-caddy $ ps aux | grep caddy pratham 3022 0.0 0.0 85672 2140 ? Ssl 06:53 0:00 /usr/bin/conmon --api-version 1 -c e6ed67eb90e6d0f3475d78b287af941bc873f6d62db60d5c13b1106af80dc5ff [...] pratham 3025 0.1 0.3 753060 32320 ? Ssl 06:53 0:00 caddy run --config /etc/caddy/Caddyfile --adapter caddyfile لاحظ أن المستخدم pratham ليس جذرًا وأنه لا حاجة لاستخدام الأمر sudo لزيادة صلاحيات المستخدم. إذ استطعت تشغيل حاوية خادم Caddy محدودة الصلاحية باستخدام أداة بودمان. يُظهِر خرج الأمر ps أن رمز العملية PID ذو الرقم 3022هو عملية تابعة للمستخدم pratham وهي حاوية خادم Caddy (لكننا لم نُظهِر الخرج كاملًا في مثالنا). أما العملية 3025 فهي تابعة child process للعملية 3022 وهما تابعتان للمستخدم نفسه. الخلاصة وضّحنا في هذا المقال كيفية إدارة الحاويات محدودة الصلاحية باستخدام أداة بودمان، وتحدثنا عن البرامج الضرورية لذلك، وتطرقنا إلى بعض المشكلات الشائعة التي قد تواجهها وكيفية حلها. إن واجهت مشكلةً لم نأتِ على ذكرها مع حاويات بودمان محدودة الصلاحية، فذلك لأن أداة بودمان لا تزال جديدةً بالنسبة للبرمجيات، لذا من المحتمل ظهور بعض المشكلات، في هذه الحالة، شاركنا استفسارك في قسم الأسئلة والأجوبة في أكاديمية حسوب. كما يمكنك الاطلاع على التوثيق الرسمي من موقع بودمان. ترجمة -وبتصرّف- للمقال Getting Started With Rootless Container Using Podman من Linux Handbook. اقرأ أيضًا المقال السابق: تحديث حاويات بودمان Podman تلقائيًا تعلم الحوسبة السحابيّة: المتطلبات الأساسيّة، وكيف تصبح مهندس حوسبة سحابيّة الفرق بين أداتي دوكر Docker وبودمان Podman الفرق بين دوكر Docker وكوبيرنيتيس Kubernetes؟ ما عليك معرفته عن الفرق بين دوكر والأجهزة الافتراضية أساسيات تنسيق الحاويات

سنقدم لك في هذا المقال دليلًا مفصلًا حول كيفية ضبط التحديثات التلقائية للحاويات المُدارة بواسطة أداة بودمان Podman وتفعيلها. فتحديث البرامج أمر محبّذ، لا سيما عندما تحتوي التحديثات على ميزات جديدة أو خيارات لزيادة الأمان. لتسهيل العمل سنستخدم في هذا المقال صورة الخادم Caddy من مستودع Docker Hub. تعيين مصدر جلب صور الحاويات كي تستطيع استخدام صورة حاوية (container image) يجب أولًا سحب هذه الصورة من أحد المصادر باستخدام أداة إدارة الحاويات بودمان، يدعى هذا المصدر بسياسة التحديث التلقائي auto-update policy وهي تتضمن قواعد أو إعدادات تحدد زمان وكيفية تحديث الصور أو الحاويات بشكل تلقائي دون تدخل يدوي، مثلاً عند إصدار تحديث جديد للصورة، يتم تحميل التحديث وتطبيقه بشكل تلقائي دون تدخل المستخدم وذلك على النحو التالي: سجل registry: عند إسناد سجل (موقع) ما إلى سياسة التحديث التلقائي auto-update policy فإن بودمان سيسحب الصورة من سجل خارجي remote registry مثل Docker Hub أو Quay.io. مصدر محلي local: عند إسناد الخيار local إلى سياسة التحديث التلقائي، فإن أداة بودمان ستجلب الصورة من الصور المحلية. يُعدّ هذا الخيار هذا الخيار مفيدًا للمطورين الذين يرغبون في اختبار التعديلات المحلية قبل دفعها إلى سجل بعيد. ملاحظة: نستخدم في أمثلة هذا المقال حاوية محدودة الصلاحية root-less container، وحاولنا قدر الإمكان ذكر الأوامر الخاصة بالحاويات كاملة الصلاحية root-full container. فإن استخدمت حاوية كاملة الصلاحية وواجهك خطأ يتعلق بصلاحيات المستخدم، فعليك استخدام الأمر sudo. تفعيل التحديثات التلقائية لحاويات Podman يمكنك الآن تفعيل التحديثات التلقائية لحاويات بودمان بعد أن أصبحت تعلم ما هو مفهوم سياسة التحديث التلقائي، وذلك باستخدام الأمر التالي: io.containers.autoupdate=AUTO_UPDATE_POLICY والآن استبدل السلسلة AUTO_UPDATE_POLICY بالخيار registry أو local. ولكن كيف ستتحدث الحاوية تلقائيًا وأداة بودمان لا تعمل كبرنامج خفي؟ ضبط خدمة systemd عليك إدارة الحاويات التي تحتاج إلى التحديث التلقائي بواسطة نظام التمهيد systemd، وذلك لأن أداة بودمان لا تعمل كبرنامج خفي. إن أردت تشغيل الحاويات تلقائيًا عند إقلاع النظام، فلا شك أنك تستخدم systemd. سنشرح في الخطوات التالية كيفية دمج حاويات بودمان سواء كانت حاويات كاملة أو محدودة الصلاحية، مع خدمة systemd وتشغيلها تلقائيًا عند الاقلاع. الخطوة التمهيدية، إنشاء الحاوية عليك التأكد أولًا أن لديك حاوية بودمان، سواء كانت قيد العمل أو متوقفة. استخدم الأمر التالي للتحقق من الحاويات الموجودة عندك: podman container list لتوضيح أمثلة هذا المقال، اسحب صورةً قديمةً من خادم Caddy (الإصدار 2.5.2-alpine) ثم أعد تسميتها بالاسم alpine، إذ ستساعد إعادة تسمية الصورة في توضيح عملية التحديث. ويمكنك التحقق من ذلك لأن معرف الصورتين هو نفسه. ثم أنشئ حاويةً من الصورة وسمّها prathams-caddy: $ podman images REPOSITORY TAG IMAGE ID CREATED SIZE docker.io/library/caddy 2.5.2-alpine d83af79bf9e2 2 weeks ago 45.5 MB docker.io/library/caddy alpine d83af79bf9e2 2 weeks ago 45.5 MB $ podman container list CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 99d1838dd999 localhost/caddy:alpine caddy run --confi... 5 seconds ago Up 6 seconds ago prathams-caddy كما تلاحظ فإن لدينا حاويةً تدعى prathams-caddy تعمل على صورة Caddy (الإصدار الأقدم). عندما تنشئ الحاوية Prathams-caddy أسند سياسة التحديث التلقائي io.containers.autoupdate على خيار السجل registry كما تعلمنا في الخطوة السابقة. إذا كان لديك حاوية بدون هذا التعديل، فلست بحاجة إلى إعادة إنشاء حاوية جديدة. سنتحدث عن ذلك في الخطوة التالية. الخطوة الأولى، إنشاء ملف خدمة systemd للحاوية كي تتمكن من إدارة حاويات بودمان باستخدام نظام systemd، يجب عليك تحويله إلى خدمة، لتشغيل الحاويات عند إقلاع النظام وإيقافها عند إيقاف تشغيل النظام. إذًا، يجب تشغيل الحاوية كخدمة systemd. ولكن كي لا تضطر إلى كتابة ملف خدمة systemd لكل حاوية، أوجد مطورو أداة بودمان حلًا لذلك، وهو تشغيل أمر معين لكل حاوية. عليك تشغيل الأمر التالي للحاويات كاملة الصلاحية root-full container: sudo podman generate systemd -f --new --name CONTAINER_NAME والأمر التالي للحاويات محدودة الصلاحية root-less container: podman generate systemd -f --new --name CONTAINER_NAME ثم استبدل CONTAINER_NAME باسم حاويتك، وسيتولد بعدها ملف باسم الحاوية كما يلي: $ podman generate systemd -f --new --name prathams-caddy /home/pratham/container-prathams-caddy.service لاحظ من الخرج السابق إنشاء حاوية باسم container-prathams-caddy.service في الملف الحالي. سبق أن ضبطتَ ميزة التحديث التلقائي لهذه الحاوية. أما بالنسبة للحاويات التي لم تضبط فيها هذه الميزة، فليس عليك إعادة إنشاء الحاوية بل يكفي تعديل ملف خدمة systemd وإضافة السطر التالي إلى حقل ExecStart على النحو التالي: [...] ExecStart=/usr/bin/podman run \ [...] --label io.containers.autoupdate=registry [...] وهكذا يستدعي ملف خدمة systemd أمر تشغيل حاويات بودمان podman run. وكل ما عليك فعله هو إضافة io.containers.autoupdate إلى الأمر podman run. الخطوة الثانية، نقل ملف خدمة systemd قبل تفعيل خدمة systemd، يجب عليك نقل ملف الخدمة إلى أحد المجلدين التاليين: /etc/systemd/system/ : إذا كانت الحاوية كاملة الصلاحية وتحتاج إلى امتيازات المستخدم المسؤول superuser. ~/.config/systemd/user/ : إذا كانت الحاوية محدودة الصلاحية، ضعها في مجلد المستخدم الذي سيشغلها. إن الحاوية Prathams-caddy في مثالنا هي حاوية محدودة الصلاحية، لذا عليك نقلها إلى مجلد المستخدم الخاص بك: $ mv -v container-prathams-caddy.service ~/.config/systemd/user/ renamed 'container-prathams-caddy.service' -> '/home/pratham/.config/systemd/user/container-prathams-caddy.service' الخطوة الثالثة، تفعيل خدمة systemd أصبح بإمكانك الآن تفعيل خدمة systemd بعد أن نقلت ملف الخدمة إلى المجلد المناسب. لكن، يجب أولاً إعلام نظام systemd بالخدمة التي أنشأتها قبل إعادة تشغيل حاسوبك. وذلك بإعادة تحميل systemd باستخدام الأمر التالي إذا كانت الخدمة خاصةً بحاوية كاملة الصلاحية: sudo systemctl daemon-reload والأمر التالي للحاويات محدودة الصلاحية: systemctl --user daemon-reload أصبح بإمكانك الآن استخدام الأمر systemctl enable لتفعيل الخدمة: # للحاويات كاملة الصلاحية sudo systemctl enable SERVICE_NAME.service # للحاويات محدودة الصلاحية systemctl --user enable SERVICE_NAME.service تحقق من حالة الخدمة، ستلاحظ أنها غير نشطة inactive (dead) وذلك لأن الخدمة تعمل عند إعادة إقلاع الحاسوب أو النظام، ولم ننفذ ذلك بعد. $ systemctl --user enable container-prathams-caddy.service Created symlink /home/pratham/.config/systemd/user/default.target.wants/container-prathams-caddy.service → /home/pratham/.config/systemd/user/container-prathams-caddy.service. $ systemctl --user status container-prathams-caddy.service ○ container-prathams-caddy.service - Podman container-prathams-caddy.service Loaded: loaded (/home/pratham/.config/systemd/user/container-prathams-caddy.service; enabled; vendor preset: enabled) Active: inactive (dead) Docs: man:podman-generate-systemd(1) والآن أوقف عمل الحاوية ثم استخدم الأمر التالي لحذفها podman container rm وأعد إقلاع جهازك بعدها. $ podman stop prathams-caddy prathams-caddy $ podman container rm prathams-caddy 99d1838dd9990b2f79b4f2c83bc9bc16dfbaf3fdeeb6c6418ddd6e641535ce21 الخطوة الرابعة، تفعيل بقاء المستخدم نشطًا (اختيارية) إذا كانت حاويتك محدودة الصلاحية فمن الأفضل أن يبقى المستخدم المسؤول عنها نشطًا، وذلك باستخدام الأمر التالي: sudo loginctl enable-linger الخطوة الخامسة، تفعيل خدمة التحديث التلقائي كل ما عليك فعله الآن هو تفعيل خدمة التحديث التلقائي في بودمان باستخدام الأمر التالي: sudo systemctl enable podman-auto-update.service بعد تفعيل خدمة التحديث التلقائي podman-auto-update في بودمان، سيتحقق systemd من وجود صورة بحاجة إلى تحديث. إذا كان هناك تحديثات، تُحدّث الصور التي جلبت أولاً، ثم يُعاد تشغيل الحاوية، مع الاحتفاظ بالصورة القديمة في حالة الحاجة إلى التراجع عن التحديث لعدة أسباب. ملاحظة: على الرغم من أن خدمة التحديث التلقائي في بودمان podman-auto-update.service تُفعّل على مستوى النظام، إلا أن أداة بودمان ليست أساسية في عديد من التوزيعات غير التابعة لتوزيعة فيدورا Fedora. لذلك، ربما تحتاج إلى تشغيل الأمر التالي لتفعيل الخدمة عند المستخدمين محدودي الصلاحية: systemctl --user Enable --now podman-auto-update.service التحديث اليدوي إن لم تكن من محبي التحديثات التلقائية، فيمكنك تحديث الحاويات يدويًا باستخدام أمر واحد فقط، بشرط أن تكون مدارةً بواسطة systemd. هذا الأمر هو podman auto-update. وإن أردت التحقق من وجود تحديثات جديدة فقط، فأضف خيار dry-run-- حتى لا تُحَدّث أي حاوية. والآن لنتحقق من إمكانية تحديث صورة الحاوية "2.5.2-alpine" إلى الإصدار "2.6.1-alpine" باستخدام الأمر podman auto-update: $ podman container list CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES a712a3c8846b docker.io/library/caddy:alpine caddy run --confi... 2 seconds ago Up 2 seconds ago prathams-caddy $ podman auto-update --dry-run UNIT CONTAINER IMAGE POLICY UPDATED container-prathams-caddy.service a712a3c8846b (prathams-caddy) caddy:alpine registry pending لاحظ أن حالة العمود updated في خرج أمر التحديث التلقائي هي pending أو معلقة وهذا يعني أنه ثم تحديث متوفر. كي تحدّث الحاوية، أزل الخيار dry-run-- من الأمر السابق. الخلاصة قد تبدو عملية تفعيل التحديثات التلقائية لحاويات بودمان معقدةً بعض الشيء، ولكنها ستؤتي ثمارها على المدى الطويل. تُحدّث جميع الحاويات المُدارة عادة بصورة تلقائية عند منتصف الليل في حال وجود التحديثات. وإن حدثت اي مشكلة في الحاوية فإن systemd سيعيدها إلى صورة قديمة، بحيث تستمر الحاوية في العمل. ترجمة وبتصرّف للمقال Automatically Updating Podman Containers من Linux Handbook. اقرأ أيضًا المقال السابق: تشغيل الحاويات تلقائيًا باستخدام أداة بودمان Podman أساسيات تنسيق الحاويات ما الفرق بين دوكر Docker وكوبيرنيتيس Kubernetes؟ ما عليك معرفته عن الفرق بين دوكر والأجهزة الافتراضية

لا شك أن أداة بودمان ممتازة لإدارة الحاويات بما تقدمه من ميزات متعددة، لكنها لا توفر خاصية التشغيل التلقائي للحاويات عند إقلاع النظام، سنتعلم في هذا المقال كيف نجد حلًا لهذه المشكلة. على الرغم من أن أداة بودمان لا تعمل كبرنامج خفي daemon، وتسمح للمستخدم محدود الصلاحيات unprivileged user بتشغيل الحاويات دون الحاجة إلى الوصول إلى الجذر، مما يزيد من أمان النظام. لكنها ليست أداةً مثاليةً بالكامل فهي لا تُتيح إعادة تشغيل الحاويات تلقائيًا بعد إقلاع الخادم. سياسة إعادة تشغيل الحاويات عند الاطلاع على صفحة التعليمات man الخاصة بالأمر podman-run ستجد أن خيار إعادة التشغيل restart-- لا يعيد تشغيل الحاويات عندما يقلع النظام. وسبب هذا يرجع إلى أن بنية بودمان لا تعتمد مبدأ البرنامج الخفي، أي إن بودمان لا يعمل تلقائيًا عند إقلاع النظام، وبالتالي فإن الحاويات لا تعمل عند الإقلاع أيضًا. على عكس أداة دوكر التي تعتمد مبدأ البرنامج الخفي الذي يعمل عند إقلاع النظام ويُشَغّل الحاويات المحددة. حل مشكلة عدم التشغيل التلقائي للحاويات أيًّا كانت توزيعة نظام التشغيل التي تعمل عليها فلا بد أنها تستخدم systemd كنظام تمهيد init، وهذا ما سنحاول الاستفادة منه في إيجاد حل للمشكلة. الخطوة الأولى: إعداد الحاوية وتشغيلها ثمة عدة طرق ممكنة لتشغيل الحاوية. إن كان لديك حاوية بسيطة فبإمكانك استخدام الأمر podman run. أو يمكنك استخدام ملف دوكر إن أردت حاويةً بإعدادات معقدة واحتجت لمزيد من التحكم بهذه الإعدادات. لتوضيح ذلك، سننشئ حاويةً من صورة الحاوية mariadb وسنسميها chitragupta-db. $ podman ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 422eed872347 docker.io/library/mariadb:latest --transaction-iso... 58 seconds ago Up 58 seconds ago chitragupta-db يمكنك إيقاف الحاوية الجديدة لاحقًا. الخطوة الثانية: إنشاء خدمة systemd كما ذكرنا سابقًا، فإن بودمان ليس برنامجًا خفيًا أي إنه daemon-less لإدارة الحاويات. إذًا، فإن تشغيل حاويات بودمان يحتاج إلى تشغيل يدوي أو خارجي. سننفذ ذلك من خلال إنشاء خدمة systemd. حيث إن خدمة systemd هي نظام تمهيد init يدير الخدمات والبرامج الخفية في أنظمة تشغيل لينكس. إنشاء ملف وحدة systemd ليس عليك إنشاء ملف وحدة systemd يدويًا، إذ يمكن تنفيذ ذلك باستخدام الأمر podman generator systemd على النحو التالي: podman generate systemd --new --name CONTAINER_NAME لإنشاء ملف وحدة systemd للحاوية استخدم الأمر podman generate systemd متبوعًا باسم الحاوية، اسم الحاوية في مثالنا هو chitragupta-db: كما تلاحظ فإن الأمر السابق نفّذ العمل المطلوب، ولكننا لم ننته من العمل بعد. إن خرج الأمر podman generate systemd هو ما يجب أن يكون موجودًا في ملف وحدة systemd، لكن ثمة خيار مفيد يمكنك الاستعانة به بدلًا من نسخ الخرج ولصقه، وهو الخيار files -- أو اختصارًا f-. إذ سيؤدي استخدام هذا الخيار أولًا إلى ملء الملف بالمحتوى المطلوب بدلاً من طباعته على الطرفية، وثانيًا، إنشاء ملف باسم Container-CONTAINER_NAME.service في مجلد العمل الحالي. $ podman generate systemd --new --name chitragupta-db -f /home/pratham/container-chitragupta-db.service $ ls *.service Container-chitragupta-db.service لاحظ أن اسم الحاوية في مثالنا هو chitragupta-db، وأنه أصبح لدينا ملف باسم container-chitragupta-db.service في المجلد الحالي. بما أن الأمر podman generate systemd سوف ينشئ ملف وحدة systemd فإن بإمكانك استخدام الخيارات التالية =after=, --requires=, --wants-- لتحديد الاعتماديات للحاويات. نقل ملف خدمة systemd إلى موقع محدد كما لاحظت فإن الأمر السابق سينشئ ملف وحدة systemd جديد في مجلد العمل الحالي، لكن ذلك ليس الخيار الأنسب. إليك المسار المناسب للملف بالنسبة للمستخدم المسؤول superuser: /etc/systemd/system/ أما بالنسبة للمستخدم محدود الصلاحيات non-root user فهو: ~/.config/systemd/user/ والآن عليك نقل الملف إلى المجلد المناسب. بما أن الحاوية في مثالنا هي حاوية محدودة الصلاحية، فعليك نقلها إلى المجلد config/systemd/user/.~. $ mv -v container-chitragupta-db.service ~/.config/systemd/user/ renamed 'container-chitragupta-db.service' -> '/home/pratham/.config/systemd/user/container-chitragupta-db.service' وهكذا بعد أن أنشأت ملف وحدة systemd بالاستعانة بأوامر الطرفية ونقلته إلى المجلد الصحيح، ما تبقى عليك الآن هو تفعيله. الخطوة الثالثة: تفعيل حاوية خدمة systemd عليك الآن أن تعيد إقلاع systemd كي تتفعل الخدمة التي أنشأتها في الخطوة السابقة. استخدم الأمر التالي لإعادة تشغيل خدمة systemd للمستخدم الجذر: sudo systemctl daemon-reload أما بالنسبة للمستخدم محدود الصلاحيات فعليك إزالة الأمر sudo وإضافة الخيار user--، كي يصبح الأمر على الشكل التالي: systemctl --user daemon-reload وهكذا سيُعاد تشغيل خدمة systemd دون إعادة إقلاع النظام، وسيُحدّث وتظهر الخدمة الجديدة container-chitragupta-db.service. والآن أصبح بإمكانك تفعيل الخدمة الجديدة. استخدم الأمر التالي لتفعيل الخدمة للمستخدم الجذر: sudo systemctl enable SERVICE_NAME.service أما بالنسبة للمستخدم محدود الصلاحيات فعليك إزالة الأمر sudo وإضافة الخيار user--، كي يصبح الأمر على الشكل التالي: systemctl --user enable SERVICE_NAME.service ستحصل على الخرج التالي عند تفعيل الحاوية محدودة الصلاحية root-less container: $ systemctl --user enable container-chitragupta-db.service Created symlink /home/pratham/.config/systemd/user/default.target.wants/container-chitragupta-db.service → /home/pratham/.config/systemd/user/container-chitragupta-db.service. يمكنك التحقق من حالة الخدمة بعد تفعيلها بإضافة الأمر status على الأمر السابق للمستخدم الجذر والمستخدم محدود الصلاحية وفقًا لما يلي: # للمستخدم الجذر sudo systemctl status SERVICE_NAME.service # للمستخدم محدود الصلاحية systemctl --user status SERVICE_NAME.service إليك حالة الخدمة container-chitragupta-db: $ systemctl --user status container-chitragupta-db.service ○ container-chitragupta-db.service - Podman container-chitragupta-db.service Loaded: loaded (/home/pratham/.config/systemd/user/container-chitragupta-db.service; enabled; vendor preset: disabled) Active: inactive (dead) Docs: man:podman-generate-systemd(1) لا تقلق لأن حالة الخدمة تظهر غير نشطة inactive (dead)، إذ فعّلنا الخدمة الآن ويجب أن تعمل الخدمة عند إقلاع النظام، وليس الآن، وهذا هو المطلوب. إذا لم توقف الحاوية في الخطوة الأولى، فهذا هو الوقت المناسب لإيقافها عن طريق استخدام الأمر podman stop ثم استخدام الأمر podman container rm لحذفها، وإعادة إقلاع النظام بعدها لتشغيل خدمة الحاوية. الخطوة الرابعة: تفعيل خدمة إعادة التشغيل قد تحتاج في بعض التوزيعات إلى تفعيل خدمة إعادة التشغيل في بودمان أيضًا. ينطبق هذا على التوزيعات غير المعتمدة على نظام فيدورا، وخاصةً توزيعة NixOS. لتفعيل خدمة إعادة التشغيل عليك استخدام الأمر التالي: systemctl --user enable podman-restart.service يحرص الأمر podman-restart على إعادة تشغيل جميع الحاويات التي ضُبطت ليُعاد تشغيل دائمًا أي عند ضبط الأمر restart-policy على الخيار always. الخطوة الخامسة، تفعيل بقاء المستخدم محدود الصلاحية نشطًا (خطوة اختيارية) بما أنك فعّلت هذه الخدمة بواسطة مستخدم عادي محدود الصلاحية وليس المستخدم الجذر، هذا يعني أن المستخدم يحتاج إلى تسجيل الدخول عند التشغيل ويجب أن يظل نشطًا إن خرج من جلسة واجهة المستخدم الرسومية GUI أو من الطرفية. ويمكن تحقيق ذلك باستخدام الأمر loginctl من طرفية المستخدم نفسه، على النحو التالي: sudo loginctl enable-linger يضمن هذا الأمر تفعيل جلسة المستخدم عند الإقلاع وبقاءها نشطةً حتى بعد تسجيل الخروج من واجهة المستخدم الرسومية أو الطرفية. وبهذا تكون قد فعّلتَ إعادة تشغيل حاويات بودمان عند الإقلاع. حيث ستؤدي إعادة تشغيل النظام إلى التشغيل التلقائي للحاويات التي أنشأت لها ملف وحدة systemd. تعديل خدمة systemd نعلم جميعًا أن الإعدادات الافتراضية تفيد المبتدئين دائمًا، إذ تساعد على تخفيف شعور الارتباك لديهم. تُعد الإعدادات الإفتراضية لملف systemd الذي أنشأته مثاليةً لمعظم الأشخاص، لكن إن لم تكن مبتدئًا فبإمكانك إضافة مزيد من التعديلات من خلال تعديل ملف systemd أو إنشاء خدمة مخصصة جديدة من الصفر. الخلاصة تعلمنا في هذا المقال كيفية إنشاء ملفات وحدة systemd للتشغيل التلقائي لحاويات بودمان عند إقلاع النظام. حيث أن استخدام خدمة systemd سيساعدك في مراقبة الحاويات التي تستخدم واجهة systemd. ترجمة وبتصرّف للمقال Autostarting Podman Containers من موقع Linux Handbook. اقرأ أيضًا المقال السابق: إنشاء الحاويات وحذفها باستخدام أداة بودمان Podman نظام كوبيرنتس Kubernetes وكيفية عمله كيفية تأمين الحاويات عن طريق سي لينكس SELinux الفرق بين أداتي دوكر Docker وبودمان Podman

هل أنت حديث العهد باستخدام أداة بودمان؟ إن كان جوابك نعم، فلا تقلق، سنتعلم في هذا المقال كيفية إنشاء الحاويات وكيفية عرضها وإيقافها وحذفها باستخدام بودمان. هذا المقال جزء من سلسلة مقالات بودمان Podman وهي تهدف لتعريفك على هذه الأداة كي تستطيع عند نهاية هذه المقالات، التعرف على الفرق بين دوكر وبودمان، وبدء استخدام بودمان بكفاءة عند العمل مع الحاويات. ما ستتعلمه في سلسلة تعرف على أداة بودمان Podman سنتعلم في هذه سلسلة ما يلي: الفرق بين أداتي دوكر وبودمان إنشاء الحاويات وحذفها باستخدام أداة بودمان تفعيل حاويات بودمان تلقائيًا عند إقلاع النظام تحديث الحاويات مفهوم الحاويات محدودة الصلاحية Rootless containers مفهوم بودمان كومبوز Podman Compose متطلبات هذه السلسلة معرفة مسبقة بمفهوم الحاويات تجربة مسبقة في التعامل مع دوكر خبرة في التعامل مع سطر الأوامر أو الطرفية Terminal في لينكس كما تعلمنا في مقال سابق فإن أداة بودمان هي أداة بديلة عن دوكر تستخدم لإدارة الحاويات، ولها بنية أوامر مشابهة لأوامر دوكر. وسنتعلم في مقال اليوم كيفية إنشاء الحاويات وحذفها. سحب الصور من سجل الصور باستخدام بودمان عند إنشاء الحاويات، ستحتاج أولًا إلى صورة للحاوية image، إذ لا يمكنك تنفيذ شيء بدون الصورة. ولذلك عليك سحب pull الصورة من سجل الصور. إليك بعض سجلات الصور الشهيرة: Docker Hub Quay.io سجلات الصور المستضافة مثل linuxserver.io ولسحب صورة باستخدام بودمان فعليك استخدام الصيغة التالية: podman pull [OPTIONS] FULLY_QUALIFIED_IMAGE_NAME[:tag|@digest] لمعرفة معنى اسم الصورة المؤهل بالكامل FULLY_QUALIFIED_IMAGE_NAME واختصارًا FQIN، ألقِ نظرةً على الأمرين التاليين: # باستخدام اسم الصورة المؤهل تمامًا podman pull docker.io/library/debian # بدون اسم الصورة المؤهل تمامًا podman pull debian كما تلاحظ، في اسم الصورة المؤهل بالكامل، يكون التنسيق على النحو التالي: السجل/اسم المستخدم/اسم الصورة. في مثالنا فإن docker.io هو عنوان سجل دوكر hub.docker.com. لسحب وسم tag محدد، اكتب اسم الوسم بعد اسم الصورة، مسبوقًا بنقطتين (:). إليك مثالًا عن سحب الوسم stable-slim لصورة ديبيان: podman pull docker.io/library/debian:stable-slim عرض الصور المتاحة بعد سحب صورة أو أكثر، يمكنك معاينة الصور المتوفرة محليًا باستخدام الأمر podman Images. عند سحب صورة debian:stable-slim، ستحصل على الخرج التالي: $ podman images REPOSITORY TAG IMAGE ID CREATED SIZE docker.io/library/debian stable-slim 86f9b934c377 2 days ago 77.8 MB والآن بعد أن حصلت على الصورة يمكنك إنشاء حاوية جديدة إنشاء حاوية جديدة لإنشاء حاوية جديدة في بودمان، عليك استخدام الأمر podman run بالطريقة التالية: podman run [OPTIONS] image [COMMAND [ARGS]] والآن، سنضيف بعض الخيارات options على الأمر السابق، سنضيف أولًا الخيار d- لتشغيل الحاوية باستمرار في الخلفية، والخيار t- لتخصيص طرفية زائفة pseudo-TTY لصورة ديبيان كي تعمل باستمرار. يمكنك الاطلاع على قائمة الخيارات المتاحة من توثيقات بودمان. والآن، سننشئ حاوية بسيطة تعتمد على صورة توزيعة ديبيان stable-slim التي سحبناها مسبقًا. podman run -d -t debian:stable-slim عند نجاح إنشاء الحاوية، ستحصل في الخرج output على سلسلة عشوائية من الأحرف والأرقام. هذه السلسلة هي معرف الحاوية الفريد unique container ID. 61d1b10b5818f397c6fd8f1fc542a83810d21f81825bbfb9603b7d99f6322845 عرض الحاويات أولًا، لعرض الحاويات قيد التشغيل، عليك استخدم الأمر podman ps، وهو يشبه الأمر ps في لينكس، لكن بدلاً من إظهار عمليات النظام، فإنه يظهر الحاويات قيد التشغيل وتفاصيلها. بما أننا استخدمنا الخيار t- لتشغيل حاوية دبيان، فلنرَ كيف تبدو نتيجة الأمر podman ps: $ podman ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 61d1b10b5818 docker.io/library/debian:stable-slim bash 44 seconds ago Up 44 seconds ago gallant_mahavira يمكنك الحصول على معلومات عن الحاوية باستخدام الأمر ps كمعرّف الحاوية الفريد القصير، والصورة المستخدمة لإنشاء هذه الحاوية، ومتى أُنشِئت الحاوية، ومنافذ الجهاز المضيف المسندة إلى منافذ الحاوية واسمها. ونلاحظ من الخرج أن الصورة المستخدمة هي debian:stable-slim أُنشِئت قبل 44 ثانية، أما اسم الحاوية فهو gallant_mahavira. يمكنك تسمية الحاوية عند إنشائها باستخدام الخيار name CONTAINER_NAME--، فعندما لا تحدد اسم الحاوية، يُولَد اسم عشوائي لها. ثانيًا، لعرض الحاويات المتوقفة عن العمل Stopped containers عليك استخدام الأمر التالي: podman container list -a والآن، سنتعلم كيفية إيقاف الحاويات. إيقاف الحاويات لإيقاف الحاويات عليك استخدام الأمر podman stop مع معرّف الحاوية أو اسمها، وذلك وفق الصيغة التالية: podman stop [CONTAINER_NAME|CONTAINER_ID] والآن سنوقف الحاوية الجارية باستخدام اسمها: $ podman stop gallant_mahavira gallant_mahavira والآن بإمكانك استخدام الأمر السابق لعرض جميع الحاويات الجارية والمتوقفة: $ podman container list -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 61d1b10b5818 docker.io/library/debian:stable-slim bash 14 minutes ago Exited (137) 3 minutes ago gallant_mahavira ملاحظة: ترتبط كل من الأوامر podman container list and podman container ls، podman ps، podman container ps بنفس الملف الثنائي binary ولها نفس الاستخدام وتعطي نفس الخرج. إعادة تشغيل الحاوية لإعادة تشغيل حاوية ما بعد إيقاف عملها أو فشله، عليك استخدام الأمر podman start. فلنفترض أن الحاوية التي أنشأتها من صورة ديبيان فشلت لسبب ما، إذًا يمكنك إعادة تشغيلها عن طريق كتابة اسمها أو معرّفها بعد الأمر podman start كالتالي: $ podman start 61d1b10b5818f397c6fd8f1fc542a83810d21f81825bbfb9603b7d99f6322845 حذف الحاويات قبل حذف حاوية أو تدميرها عليك أولًا إيقافها، وبعدها يمكنك استخدام الأمر podman rm لحذفها. بمجرد حذف الحاوية، فإنها ستختفي ولن تظهر في خرج الأمر podman Container list -a. إليك المثال التالي على إيقاف وحذف حاوية باستخدام بودمان، والذي استخدمنا فيه اسم الحاوية ومعرفها. $ podman ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 61d1b10b5818 docker.io/library/debian:stable-slim bash 44 minutes ago Up 1 second ago gallant_mahavira $ podman stop gallant_mahavira gallant_mahavira $ podman rm 61d1b10b5818 61d1b10b5818f397c6fd8f1fc542a83810d21f81825bbfb9603b7d99f6322845 $ podman container list -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES كما ترى فإن الحاوية اختفت تمامًا. يمكنك الآن إن أردت، إنشاء حاوية جديدة باستخدام أي صورة وفق الأوامر الخطوات التي تعلمتها. الخاتمة تهانينا، لقد وصلت إلى نهاية المقال الثالث في سلسلتنا التعليمية حول أداة بودمان، وتعلمت كيفية إنشاء الحاويات وعرضها وإيقافها وحذفها، تابع قراءة باقي المقالات كي تتعلم المزيد حول بودمان. ترجمة -وبتصرف- للمقال Creating and Destroying Containers Using Podman من موقع Linux Handbook. اقرأ أيضًا المقال السابق: الفرق بين أداتي دوكر Docker وبودمان Podman مدخل إلى حاويات لينكس LXC ما هي صورة الحاوية container image؟ نظرة عامّة على إعداد الحاويات containerization على Docker

إن أداة بودمان 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. اقرأ أيضًا مدخل إلى دوكر Docker ما الفرق بين دوكر Docker وكوبيرنيتيس Kubernetes؟ كيفية تأمين الحاويات عن طريق سي لينكس SELinux نظام كوبيرنتس Kubernetes وكيفية عمله