أداة Weld من Runpod تبني صور الحاويات مباشرة داخل الـ Pod دون خدمة Docker

موقف مألوف: أعددتم البيئة على جهاز GPU مستأجر، وكل شيء يعمل، والآن يجب تغليفها في صورة لإعادة إنتاجها على جهاز آخر أو تسليمها للفريق. نقل كل ذلك إلى حاسوب محمول وبناء الصورة هناك ثم رفعها مجددًا إلى السحابة أمر طويل وغير مريح. تقترح Runpod طريقًا آخر: أداة Weld تبني الصور وتدفعها مباشرة من داخل الـ Pod.

ما المشكلة التي تحلّها Weld

الـ Pod على Runpod هو بالفعل حاوية. ولتنفيذ docker build المعتاد داخل حاوية تحتاجون إلى خدمة Docker (daemon). وهي تتطلب صلاحيات مرتفعة أو وصولًا إلى socket المضيف، وفي السحابة المُدارة لا يمنح أحدٌ ذلك عادةً: فهو شديد الخطورة على العزل. لذلك كانت الصور تُبنى عمليًا في مكان آخر: على جهاز محلي، أو في CI، أو على خادم بناء منفصل.

ولهذا المخطط ثمن. فصورة مشروع تعلّم آلي يسهل أن يبلغ حجمها عشرات الغيغابايت: CUDA وPyTorch والاعتمادات، وأحيانًا أوزان النموذج. وإذا بنيتموها على حاسوب Apple Silicon لمعمارية amd64، فإن المحاكاة تُبطئ البناء أيضًا. ثم تنطلق كل هذه الغيغابايتات عبر الاتصال المنزلي إلى السجل.

ما الذي تعد به Weld

بحسب الإعلان، تزيل Weld الاعتماد على الـ daemon: فالأداة تبني الصورة وترسلها إلى السجل من داخل الـ Pod، دون الحاجة إلى الـ daemon نفسه. هذا النهج ليس جديدًا: ففي عالم الحاويات توجد منذ زمن أدوات بناء بلا daemon مثل Kaniko وBuildah. الجديد هنا أن الحل مدمج في منظومة Runpod ومصمَّم خصيصًا لوحدات Pod الخاصة بها.

تصف المادة سيناريو متكاملًا من ثلاث خطوات:

• بناء صورة تجريبية؛
• دفعها إلى السجل؛
• تشغيل الصورة الناتجة على Pod.

أي أن دورة «البيئة، الصورة، التشغيل» كلها يمكن إنجازها دون مغادرة السحابة. وبالنسبة للفرق التي تكرّر العمل على بيئة الاستدلال أو إعادة التدريب، قد يوفّر ذلك ساعات في كل دورة. فالبناء يجري بجوار الـ GPU وعلى اتصال جيد في مركز البيانات، لا عبر الإنترنت المنزلي.

ما الذي لا يظهر في الإعلان

المادة الأصلية قصيرة، ولذلك تبقى عدة أسئلة مهمة مفتوحة. لا نعرف كيف تتعامل Weld مع تخزين الطبقات المؤقت: فمن ذلك يتوقف ما إذا كان البناء الثاني سيستغرق ثوانيَ أم العشرين دقيقة نفسها. وليس واضحًا إلى أي مدى تدعم صياغة Dockerfile، وخصوصًا عمليات البناء متعددة المراحل والتعليمات غير القياسية. ولا توجد معلومات عن كيفية تخزين بيانات الاعتماد للسجل الخاص ولا عمّا يحدث للأسرار أثناء البناء. كما لم تُوصف قيود القرص: فالصورة تحتاج إلى مساحة للطبقات وللملفات المؤقتة.

وهناك ملاحظة أخرى: البناء داخل الـ Pod يستهلك موارد الـ Pod نفسه الذي تدفعون ثمنه بالساعة. فإذا بنيتم على جهاز GPU باهظ، تُحاسَبون على دقائق البناء بتعرفته. وبالنسبة للصور الثقيلة من الأجدر التحقق مما إذا كان البناء على Pod بمعالج CPU رخيص أكثر جدوى.

ماذا تفعلون عمليًا

إذا كنتم تعملون بالفعل على Runpod وتعانون من تسليم الصور المخصصة، فجدير بكم تجربة Weld على مشروع صغير. خذوا ملف Dockerfile الحقيقي لديكم، لا العرض التجريبي من الإعلان، وقيسوا ثلاثة أشياء: زمن البناء البارد، وزمن إعادة البناء بعد تعديل صغير، وسلامة تشغيل النتيجة على Pod. وإذا بُني الـ Dockerfile دون تعديلات واستخدمت إعادة البناء الكاش، فسيُسترد ثمن الأداة سريعًا.

أما لمديري المنتجات والمؤسسين الذين يبنون خدمات على وحدات GPU مستأجرة، فثمة ملاحظة أخرى مفيدة: السحب تسدّ تدريجيًا الفجوة بين «جهاز التجارب» و«التسليم القابل لإعادة الإنتاج». وكلما قلّت الخطوات بين نموذج أولي يعمل وصورة يمكن نشرها على عنقود، أسرع الفريق في الوصول إلى الإنتاج. لكن حتى الآن هذا أقرب إلى إعلان نوايا منه إلى سير عمل مُثبت، وعليكم قراءة وثائق Runpod بأنفسكم.