Containerization

تجميع الحاويات أسلوب لتعبئة البرمجيات، يجمع فيه التطبيق وكل ما يحتاج إليه للتشغيل، بما في ذلك بيئة التشغيل والمكتبات وحزم النظام والإعدادات، داخل صورة تعمل كعملية معزولة تُسمى حاوية. ترى كل حاوية نظام ملفاتها وشجرة عملياتها وواجهات شبكتها الخاصة، بينما تشترك جميع الحاويات على المضيف في نواة نظام تشغيله، ما يجعلها أخف بكثير من الأجهزة الافتراضية. وفي تعلم الآلة (ML)، يزيل تجميع الحاويات التعارضات بين المشاريع التي تحتاج إلى إصدارات مختلفة من Python أو CUDA أو PyTorch، ويتيح تشغيل النموذج الذي دُرّب على محطة عمل دون تغيير على خادم أو مجموعة أو جهاز حوسبة طرفية.

آلية عمل الحاويات#

تعتمد حاويات Linux أساسًا على ميزتين في النواة. تتحكم مساحات الأسماء فيما يمكن للعملية رؤيته، إذ تمنحها معرّفات عمليات ومكدس شبكة ونقاط تركيب ومستخدمين خاصين بها، بينما تتحكم مجموعات التحكم (cgroups) فيما يمكنها استخدامه، عبر وضع حدود على CPU والذاكرة والإدخال والإخراج. تعود جذور الفكرة إلى chroot عام 1979 وسجون FreeBSD عام 2000، ودخلت cgroups نواة Linux عام 2008، ثم جعلت Docker الحاويات شائعة عام 2013. وضعت مبادرة الحاويات المفتوحة (OCI)، التي تأسست عام 2015، معايير تنسيقي الصورة وبيئة التشغيل، كي تعمل الصورة المبنية بأداة معينة باستخدام أداة أخرى.

تتولى بيئة تشغيل الحاويات تنفيذ العمل. تسحب بيئات التشغيل عالية المستوى مثل containerd وCRI-O الصور وتدير دورات حياة الحاويات، بينما تنشئ بيئة تشغيل OCI منخفضة المستوى مثل runc مساحات الأسماء ومجموعات cgroups وتبدأ العملية. وبما أن حاويات Linux تحتاج إلى نواة Linux، فإن macOS وWindows تشغّلانها داخل جهاز افتراضي صغير يعمل بنظام Linux.

الصور والطبقات والسجلات#

الصورة مكدس من طبقات للقراءة فقط، بالإضافة إلى إعداد يحدد الأمر المطلوب تشغيله. عند بدء التشغيل، تدمج بيئة التشغيل الطبقات في نظام ملفات واحد، عادةً باستخدام OverlayFS، وتضيف طبقة كتابة رقيقة لتلك الحاوية، ما يتيح لعدة حاويات مشاركة نسخة واحدة من الصورة على القرص. تخزن السجلات مثل Docker Hub وGitHub Container Registry وسجل كل مزوّد سحابي الصور تحت وسوم مثل latest وتحت بصمات المحتوى، وهي تجزئات SHA-256 تحدد دائمًا البايتات نفسها. تعيد عمليات البناء استخدام الطبقات التي لم تتغير، ولهذا تثبت ملفات Dockerfile الاعتماديات قبل نسخ الشيفرة التي تُحرر باستمرار:

تجميع الحاويات في سير عمل تعلم الآلة#

تحمل الحاويات المشروع من التجربة إلى الإنتاج ضمن مسارات MLOps. تثبّت صور الأطر، مثل الصور الموجودة في كتالوج NVIDIA NGC، إصدارات CUDA وcuDNN وإطار العمل، بحيث تشغّل كل عقدة في مهمة التدريب الموزع البرمجيات نفسها، ولا يوفر المضيف سوى برنامج تشغيل GPU، الذي تتيحه NVIDIA Container Toolkit للحاوية. تعمل اختبارات التكامل المستمر داخل الصورة نفسها التي ستُشحن لاحقًا، وتعمل خوادم الاستدلال الخاصة بـخدمة النماذج كصور يكررها Kubernetes ويوسع نطاقها بحسب حركة المرور، وتحدّث أجهزة الذكاء الاصطناعي الطرفي، مثل لوحات NVIDIA Jetson، النموذج بسحب وسم صورة جديد.

يثبّت تكامل النشر المحلي لـمنصة Ultralytics لمساحات عمل Enterprise نظام Docker عند الحاجة، ويشغّل حاوية عامل واحدة من صورة Ultralytics الرسمية المتوافقة مع عتاد المضيف: ARM64 أو CPU أو NVIDIA GPU. يحمّل العامل مجلد مجموعة البيانات للقراءة فقط، لتبقى الصور المصدر على ذلك الحاسوب، بينما تُرسل مقاييس التدريب وأفضل نقطة تحقق لكل تشغيل لـYOLO26 إلى المنصة.

الحاويات والأجهزة الافتراضية#

يشغّل الجهاز الافتراضي نظام تشغيل ضيفًا كاملًا بنواته الخاصة فوق برنامج مراقبة الأجهزة الافتراضية، لذا يحمل كل جهاز صورة نظام تشغيل بحجم عدة غيغابايتات ويقلع كحاسوب منفصل. أما الحاوية فهي عملية عادية على نواة المضيف المشتركة، لذا تبدأ بسرعة التطبيق ولا تضيف سوى ملفاتها الخاصة. ويعني اشتراك الحاويات في النواة أن ثغرة فيها قد تكشف كل الحاويات على المضيف، لذا غالبًا ما يُجمع النهجان: تشغّل السحب العامة حاويات العملاء داخل أجهزة افتراضية، وتضيف بيئات التشغيل المعزولة حدًا أمنيًا ثانيًا للشيفرة غير الموثوقة، مثل الشيفرة التي يكتبها وكلاء الذكاء الاصطناعي ويشغّلونها في بيئات عزل الوكلاء. يعترض gVisor من Google استدعاءات النظام التي تجريها الحاوية باستخدام نواة خاصة به في مساحة المستخدم. ويشغّل Kata Containers كل حاوية داخل جهاز افتراضي خفيف، كما أنشأت AWS أجهزتها الافتراضية المصغرة Firecracker لعزل وظائف AWS Lambda بالطريقة نفسها.