إذا كنت قد قرأت أي شيء عن تشغيل الشيفرة التي يولّدها الذكاء الاصطناعي بأمان، فقد رأيت كلمة microVM، وغالباً بجوار Firecracker. وعادةً ما تُشرح إما بأنها „آلة افتراضية خفيفة“ (صحيح، لكنه لا يفيد) أو برسم تخطيطي لأحشاء النواة. هذه هي النسخة التي تقع بين الاثنين.
خياران أقدم، ولماذا لا يناسب أي منهما
لنبدأ بالشيئين اللذين تقع آلة microVM بينهما.
الحاوية مجموعة من العمليات العادية على جهازك، وافقت النواة على أن „تكذب“ عليها. تُريها namespaces نظام ملفات وقائمة عمليات وشبكة خاصة بها، وتحدّ cgroups من مقدار المعالج والذاكرة الذي يمكنها استخدامه. وهي تبدأ في أجزاء من الثانية لأنه لا يُقلع شيء جديد. لكن كل الحاويات على المضيف تتحدث إلى النواة نفسها. وأي ثغرة في النواة يمكن الوصول إليها من داخل حاوية واحدة هي طريق للخروج منها جميعاً.
الآلة الافتراضية تجلب نواتها الخاصة. ويشغّل معالج المضيف، عبر المحاكاة الافتراضية بالعتاد (KVM على Linux)، النظامَ الضيف كأن له حاسوبه الخاص. والحد الفاصل هو المشرف الافتراضي، الذي يكشف أقل بكثير من مئات استدعاءات النظام في النواة. والثمن هو الثقل. فالآلة الافتراضية التقليدية تحاكي حاسوباً كاملاً: البرنامج الثابت، وناقل PCI، ووحدات تحكم USB، وبطاقة رسوميات، وأحياناً بطاقة صوت. وهي تقلع مروراً بكل ذلك، فتستغرق من ثوانٍ إلى دقائق، وكل نسخة تحمل عشرات أو مئات الميغابايتات من الحمل الإضافي.
تشبيه يصمد إلى حد معقول: الحاويات شقق في مبنى واحد، تتشارك الأساسات والأنابيب والأسلاك. والآلات الافتراضية بيوت منفصلة. البيوت جيران أكثر أماناً، لكن لا أحد يبني بيتاً من أجل زيارة تدوم 20 ثانية.
ما الذي يزيله Firecracker
Firecracker هو مراقب آلات افتراضية (البرنامج الذي يجهّز الآلة الافتراضية ويشغّلها فوق KVM)، مكتوب بلغة Rust ومفتوح المصدر منذ 2018. صُمّم لمهمة واحدة: تشغيل أعداد هائلة من الأحمال قصيرة العمر التي لا يثق بعضها ببعض على عتاد مشترك. ويصل إلى ذلك في الغالب بحذف الأشياء:
- لا برنامج ثابت، ولا اكتشاف للعتاد. تُحمَّل النواة مباشرة في الذاكرة وتبدأ. لا شيء يبحث عن أجهزة غير موجودة.
- نموذج أجهزة صغير جداً. بطاقة شبكة، وجهاز كتلي، وطرفية تسلسلية، وبضعة أجهزة أخرى، كلها من نوع virtio (أجهزة مصممة للآلات الافتراضية بدلاً من تقليد الأجهزة المادية). لا USB، ولا رسوميات، ولا PCI.
- قاعدة شيفرة صغيرة وآمنة الذاكرة. كلما قلّت الشيفرة التي تحاكي الأجهزة، قلّت الأماكن التي قد تختبئ فيها ثغرة تتيح للضيف الوصول إلى المضيف.
- قفص حول مراقب الآلة نفسه. تعمل كل عملية Firecracker داخل chroot، مع مرشحات seccomp تقيّد استدعاءات النظام الخاصة بها وcgroups تحدّ مواردها. ولو أفلت شيء من الضيف، لوقع في قفص لا على المضيف.
الأرقام التي ينشرها المشروع نفسه: الوصول إلى فضاء المستخدم في 125 ms فقط، وأقل من 5 MiB من الحمل الإضافي للذاكرة لكل microVM. هذه أفضل أرقام المختبر؛ فصندوق الرمل الحقيقي يحتاج أيضاً إلى تجهيز القرص والشبكة ووكيل بداخله جاهز لاستقبال الأوامر، ولهذا يجهز صندوقنا في نحو ثانية. وهذا لا يزال قريباً بما يكفي من سرعة الحاوية لتنشئ واحداً لكل مهمة وتتخلص منه بعدها.
الحاوية مقابل microVM عملياً
| الحاوية | Firecracker microVM | |
|---|---|---|
| النواة | مشتركة مع المضيف | خاصة بها |
| الحد الفاصل مع المضيف | استدعاءات نظام إلى نواة مشتركة | مشرف افتراضي + مراقب صغير |
| زمن البدء | أجزاء من الثانية | ~0.1–1 ث |
| الحمل الإضافي لكل نسخة | صغير جداً | بضعة MiB |
| الأجهزة | ما يكشفه المضيف | شبكة، قرص، طرفية |
| GPU | ممكن | لا |
| مناسبة لـ | شيفرة تثق بها، تغليف التطبيقات | شيفرة غير موثوقة، أحمال متعددة المستأجرين |
الصف المهم هو الثاني. مع الحاوية، يصبح السؤال „هل تستطيع هذه الشيفرة الهروب؟“ هو „هل توجد ثغرة يمكن الوصول إليها في أي مكان من نواة المضيف؟“. ومع microVM يصبح „هل توجد ثغرة في المشرف الافتراضي أو في حفنة من الأجهزة الافتراضية؟“. السطح الثاني أصغر بكثير، وهو السطح نفسه الذي تدافع عنه منصات السحابة أصلاً لاستضافتها متعددة المستأجرين.
ما الذي تتخلى عنه
آلة microVM ليست ترقية مجانية.
- لا GPU ولا شاشات. إنها لتشغيل الشيفرة، لا لأسطح المكتب أو أحمال الرسوميات.
- أجهزة أقل، مرونة أقل. أي شيء يتوقع عتاداً حقيقياً أو قائمة طويلة من وحدات النواة لن يشعر بالراحة.
- الحدود ما زالت تحتاج إلى سياسة. آلة microVM بحركة صادرة مفتوحة يمكنها إرسال حركة لا تريدها، وأخرى تحوي مفاتيح API الخاصة بك يمكنها تسريبها. العزل يحمي المضيف من الضيف، لا أسرارك من الشيفرة التي سلّمتها إياها.
كيف تستخدمها صناديق الرمل لدينا
كل صندوق رمل في EQVPS هو آلة Firecracker microVM واحدة بنواة خاصة، من 0.25 vCPU و512 MB حتى 8 vCPU و16 GB. يأتي مع Python 3.12 وNode.js 22 وbash وgit وcurl، وفيه اتصال صادر بالإنترنت ولا منافذ واردة. تُحذف صناديق الرمل المؤقتة حين تنتهي، وتحتفظ صناديق persistent بقرصها، والإيقاف المؤقت يكتب لقطة من آلة microVM على القرص فلا تكلّف شيئاً حتى تُستأنف. تُحفظ اللقطات الموقوفة 14 يوماً. بعدها يُحذف الصندوق ويرد معرّفه بـ 410 sandbox_deleted.
اخترنا microVM بدلاً من الحاويات لسبب واحد: الشيفرة التي تعمل في صندوق الرمل هي، بحكم التصميم، شيفرة لم يراجعها أحد. مخرجات وكيل ذكاء اصطناعي، أو طلب pull request من شخص غريب، أو اختبار أداء من ألف برنامج كتبها نموذج. ولهذه الحالات، النواة الخاصة هي الحد الذي يستحق أن تدفع ثمنه. وتفاصيل ما وضعناه حوله — الباقات، والحصص، وحد الـ55 ثانية للأوامر المتزامنة — موجودة في توثيق صناديق الرمل.
إن أردت مقارنة هذا الحد بالخيارات الأخرى بعمق أكبر، فمقال مستويات العزل للشيفرة غير الموثوقة يضع العمليات والحاويات وmicroVM والآلات الافتراضية الكاملة جنباً إلى جنب. وإن كان السعر بالثانية هو ما لفت انتباهك، فمقال كيف تعمل الفوترة بالثانية فعلاً يعرض الحسابات.
التعليقات
لا تعليقات بعد. كن الأول.