في AWS re: Invent 2018 ، التي تجري هذه الأيام في لاس فيغاس ،
تم الإعلان عن
Firecracker ، وهي تقنية افتراضية مفتوحة المصدر جديدة تعتمد على Linux KVM. ويعد المؤلفون بأنه "في ثانية واحدة ، يمكنك تشغيل أجهزة ظاهرية صغيرة خفيفة الوزن (microVM) في بيئة غير افتراضية ، والحصول على مزايا أجهزة VM التقليدية - في شكل أمان وعزل أعباء العمل والحاويات - في شكل استخدام فعال للموارد."
الخلفية
يقوم موظفو Amazon Web Services بتطوير برنامج Firecracker الذين شرعوا في تحسين استهلاك الموارد والحياة العامة لمستخدمي خدمات مثل AWS Lambda (تم إطلاقه في عام 2014 ويسمح لنا اليوم أن نقول أن النموذج بدون خادم
سيستمر في الوجود) و AWS Fargate (ظهر قبل عام )
اعتمد المشروع على تطوير المصادر المفتوحة من Google ،
crosvm من Chromium OS ، الذي كتب بلغة Rust ومسؤول عن إطلاق أنظمة التشغيل باستخدام ظاهرية الأجهزة (ولكن دون محاكاة الأجهزة الحقيقية). لذلك ، يتم أيضًا كتابة رمز Firecracker بلغة
Rust ، ويعد مؤلفوه بإعادة تصحيحاتهم إلى قاعدة التعليمات البرمجية للمشروع الأصلي ، على الرغم من أن المشاريع نفسها قد تباعدت بشكل كبير في الغرض.
تم إصدار الإصدار الأول العام من Firecracker -
0.1.0 - في مارس من هذا العام ، وآخر
إصدار سابق -
0.11.0 - قبل بضعة أيام فقط. لقد بدأت كتابة هذا المقال بعد وقت قصير من الإعلان على الإنترنت عن برنامج Firecracker ، عندما كان المشروع يحتوي على 76 نجمة على GitHub ، وفي وقت النشر تجاوز هذا الرقم 500.
ميزات الالعاب النارية
المكون الرئيسي لـ Firecracker هو مراقب الآلة الافتراضية (VMM) ، والذي يستخدم Linux KVM لإنشاء وتشغيل ما يسمى microVMs. يسمي المؤلفون منتجهم "بديل قائم على السحابة لـ QEMU" [تستخدمه حاويات Kata] ، "مخصص فقط لإطلاق الحاويات بشكل آمن وفعال."
وإليك مثال على نظام مضيف يقوم بتشغيل microVMs المذكورة:
يسعى المطورون إلى الحد الأدنى ، بما في ذلك في المنتج فقط الأكثر ضرورة ، وبالتالي ضمان الحد الأدنى من تكاليف الذاكرة ، وفي نفس الوقت تقليل احتمالات الثغرات المحتملة. في Firecracker ، تتم محاكاة
4 أجهزة فقط : Virtio-net و Virtio-block ووحدة تحكم تسلسلية ولوحة مفاتيح مع زر واحد ، تُستخدم لإيقاف تشغيل microVM. نظرًا لأن أنظمة تشغيل المضيف والضيف ، فإن أنظمة التشغيل المستندة إلى
إصدار نواة Linux 4.14 ( إصدار من نوفمبر من العام الماضي) وأعلى مدعومة حاليًا ، والخطط الحالية للمطورين هي دعم الفرعين المستقرين من نواة Linux. من حيث الأجهزة ، يتم دعم معالجات Intel فقط حتى الآن ، ولكن AMD و ARM على الأجندة.
يتكون Firecracker نفسه من عملية VMM واحدة ، والتي تجعل عند نقطة بدء API نقطة النهاية (RESTful) متاحة على الجهاز المضيف. يتم
وصف واجهة برمجة التطبيقات نفسها بتنسيق OpenAPI ، وتسمح لك ، على وجه الخصوص ، ببدء microVM بالمعلمات المحددة (صورة kernel ، ونظام الملفات الجذر ، ووسائط التمهيد) وإيقافه ، وتكوين الأجهزة الافتراضية (عدد vCPU ، RAM ، قالب لوحدة المعالجة المركزية) ، إضافة إلى واجهات الشبكة ، والأقراص (المقدمة على أنها أجهزة كتلة ، تتوفر أوضاع القراءة والكتابة والقراءة فقط) ، تكوين النظام للسجلات والمقاييس.
المزايا الرئيسية لـ Firecracker هي الأمان (التركيز على الحوسبة المتعددة المستأجرين ، والعديد من مستويات العزل) ، والأداء العالي (يمكن إطلاق microVM
في 125 مللي ثانية ، ويعد المؤلفون بتحسين هذا الرقم في العام المقبل) ، الحد الأدنى من الحمل (يستهلك كل microVM حوالي 5 ميغابايت الذاكرة). ما يضيف ثقلًا للمشروع - فقد تم اختباره بالفعل "في المعركة" ويوفر عمل عدد من خدمات AWS (بما في ذلك Lambda و Fargate المذكورة).
تفاصيل الأمن
من بين الميزات الرئيسية لـ Firecracker ، التي تركز على ضمان مستوى عالٍ من الأمان ، تم ذكر ما يلي:
- نموذج ضيف بسيط (لجميع الضيوف فقط يتم توفير الحد الأدنى - انظر أعلاه حوالي 4 أجهزة).
- عزل عملية Firecracker باستخدام مجموعات cg و seccomp BPF ، بالإضافة إلى مجموعة محدودة من مكالمات النظام المسموح بها.
- الربط الثابت لعملية الألعاب النارية لبدء تشغيلها بمعزل عن البيئة المضيفة.
عرض الالعاب النارية
أظهرت مدونة AWS كيف يمكنك تجربة microVMs في العمل. للقيام بذلك ، ما عليك سوى إنشاء مثيل i3.metal وتحميل 3 ملفات إليه (ملف قابل للتنفيذ في
firecracker ، وجذر FS ، و Linux kernel):
بعد ذلك - اضبط الحقوق اللازمة على / dev / kvm:
$ sudo setfacl -mu:${USER}:rw /dev/kvm
تعيين التكوين لجهاز الضيف الأول:
$ curl --unix-socket /tmp/firecracker.sock -i \ -X PUT "http://localhost/machine-config" \ -H "accept: application/json" \ -H "Content-Type: application/json" \ -d "{ \"vcpu_count\": 1, \"mem_size_mib\": 512 }"
... ثم جوهرها:
$ curl --unix-socket /tmp/firecracker.sock -i \ -X PUT "http://localhost/boot-source" \ -H "accept: application/json" \ -H "Content-Type: application/json" \ -d "{ \"kernel_image_path\": \"./hello-vmlinux.bin\", \"boot_args\": \"console=ttyS0 reboot=k panic=1 pci=off\" }"
... والجذر FS:
$ curl --unix-socket /tmp/firecracker.sock -i \ -X PUT "http://localhost/drives/rootfs" \ -H "accept: application/json" \ -H "Content-Type: application/json" \ -d "{ \"drive_id\": \"rootfs\", \"path_on_host\": \"./hello-rootfs.ext4\", \"is_root_device\": true, \"is_read_only\": false }"
يبقى إطلاق الضيف بالفعل:
النتيجة:
ماذا عن مشاريع الحاويات الأخرى؟
على الرغم من أن مؤلفي Firecracker يعدون بأنه "سوف يتكامل مع أوقات تشغيل الحاويات الشائعة" ، إليك ما
يجيبون عليه عند سؤالهم عما إذا كان يمكن استخدام المشروع مع حاويات Kubernetes أو Docker أو Kata:
”ليس بعد. نحن نعمل على تطوير Firecracker كمشروع مفتوح المصدر لأنه يقدم نهجًا مختلفًا بشكل كبير للأمان في إطلاق الحاويات. نأمل أن تجد المجتمعات الأخرى التي تنشئ تقنيات مفتوحة المصدر للحاويات أنها مفيدة. "نحن نعمل على ضمان اندماج Firecracker بسلاسة في النظام البيئي للحاويات - بهدف التكامل السلس في المستقبل ، مع مزيد من المرونة في عزل أعباء عمل الحاويات."
PS
اقرأ أيضًا في مدونتنا: