smolvm

شغّل ووزّع البرمجيات مع العزل افتراضيًا.

هذه أداة سطر أوامر تتيح لك:

1. إدارة وتشغيل أجهزة Linux افتراضية مخصصة محليًا مع: إقلاع بارد في أقل من ثانية، ودعم متعدد المنصات (macOS، Linux، Windows)، واستخدام مرن للذاكرة.
2. حزم جهاز افتراضي ذي حالة في ملف واحد (.smolmachine) لإعادة تشغيله على أي منصة مدعومة.

التثبيت

# التثبيت (macOS + Linux)
curl -sSL https://smolmachines.com/install.sh | bash

# لوكلاء البرمجة — التثبيت + اكتشاف جميع الأوامر
curl -sSL https://smolmachines.com/install.sh | bash && smolvm --help

أو حمّله من إصدارات GitHub، وضعه في ~/.local/share/.

Windows: حمّل إصدار windows-x86_64 (يتضمن krun.dll + libkrunfw.dll)، فك ضغطه، وشغّل smolvm.exe. يتطلب تفعيل ميزة Windows Hypervisor Platform (WHP).

بدء سريع

# تشغيل أمر في جهاز افتراضي مؤقت (يُنظَّف بعد الخروج)
smolvm machine run --net --image alpine -- sh -c "echo 'Hello world from a microVM' && uname -a"

# قشرة تفاعلية
smolvm machine run --net -it --image alpine -- /bin/sh
# داخل الجهاز الافتراضي: apk add sl && sl && exit

Smolfile

ملف Smolfile يصف جهازًا بصيغة TOML — وهو ما يعادل Dockerfile أو ملف cloud-init، لكن لجهاز افتراضي كامل: الصورة، الموارد، سياسة الشبكة، وحدات التخزين، المنافذ، وأوامر الإعداد في ملف واحد مُتتبَّع.

image = "python:3.12-alpine"
net = true
cpus = 4
memory = 4096

ports = ["8000:8000", "5173-5180:5173-5180"]
volumes = ["./src:/app"]
init = ["pip install -r /app/requirements.txt"]

[network]
allow_hosts = ["api.stripe.com", "pypi.org"]

[auth]
ssh_agent = true

smolvm machine create --name myvm -s Smolfile   # أو --smolfile <PATH>
smolvm machine start --name myvm

تعيينات المنافذ تقبل منفذًا واحدًا ("8080")، أو تعيينًا صريحًا ("8080:80")، أو نطاقات متساوية الطول واحد لواحد ("5173-5180:5173-5180"). يمكن للجهاز نشر 64 تعيينًا فعليًا كحد أقصى.

المفاتيح غير المعروفة تُرفض بدلًا من تجاهلها، لذا يَفشل الخطأ الإملائي وقت الإنشاء بدلًا من عدم فعل أي شيء بصمت.

المفاتيح الشائعة: image، cpus، memory، net، ports، volumes، env، init، workdir، gpu، cuda، docker_socket، storage، overlay، وجداول [network]، [dev]، [auth]، [health]، [restart]، [service].

التقاط لقطة لجهاز في صورة قابلة لإعادة الاستخدام

لا تحتاج إلى Dockerfile للحفاظ على بيئة. جهّز جهازًا كما تريد — يدويًا أو من Smolfile — ثم احزم الجهاز المتوقف في أداة .smolmachine وادفعها إلى أي سجل OCI:

smolvm machine shell --name myvm          # التثبيت والتهيئة تفاعليًا
smolvm machine stop  --name myvm
smolvm pack create --from-vm myvm -o myvm
smolvm pack push --file myvm.smolmachine ghcr.io/you/myvm:v1

يمكن لأي شخص بعدها سحبها وتشغيل نفس الجهاز تمامًا:

smolvm pack pull ghcr.io/you/myvm:v1

أمثلة Smolfile عاملة: python · node · docker-in-vm · local-llm · headless-browser · doom

استخدم هذا لـ

عزل الكود غير الموثوق — شغّل البرامج غير الموثوقة في جهاز افتراضي معزول على مستوى العتاد. نظام ملفات المضيف والشبكة وبيانات الاعتماد مفصولة بحدود الهايبرفايزر.

# الشبكة معطلة افتراضيًا — الكود غير الموثوق لا يمكنه الاتصال بالخارج
smolvm machine run --image alpine -- nslookup example.com
# يفشل — لا وصول للشبكة

# قيّد الاتصال الصادر — اسمح فقط بمضيفات محددة
smolvm machine run --net --image alpine --allow-host registry.npmjs.org -- wget -q -O /dev/null https://registry.npmjs.org
# يعمل — مضيف مسموح

smolvm machine run --net --image alpine --allow-host registry.npmjs.org -- wget -q -O /dev/null https://google.com
# يفشل — غير موجود في قائمة السماح

الحزم في ملفات تنفيذية محمولة — حوّل أي عبء عمل إلى ملف ثنائي مستقل. جميع التبعيات مضمّنة مسبقًا — لا خطوة تثبيت، لا تنزيلات وقت التشغيل، إقلاع في أقل من 200ms.

smolvm pack create --image python:3.12-alpine -o ./python312
./python312 run -- python3 --version
# Python 3.12.x — معزول، لا حاجة لـ pyenv/venv/conda

استخدام صور الحاويات المحلية — لـ CI والمضيفات المعزولة عن الشبكة والتكرار السريع. مرّر لـ --image أرشيف docker save / podman save، أو أنبِبه عبر stdin، أو وجّهه إلى دليل rootfs مفكوك. عمل الصور يُفوَّض إلى أدوات الحاويات لديك؛ smolvm فقط يُقلع النتيجة.

# البناء محليًا، التشغيل في الجهاز الافتراضي دون push/pull
docker build -t myapp .
docker save myapp | smolvm machine run --image - -- ./app

# من ملف أرشيف (يُقلع دون شبكة)
smolvm machine run --image ./myapp.tar -- ./app

# من دليل rootfs مفكوك مسبقًا
smolvm machine run --image ./rootfs/ -- ./app

أجهزة دائمة للتطوير — إنشاء، إيقاف، تشغيل. الحزم المثبتة تبقى بعد إعادة التشغيل.

smolvm machine create --net --name myvm
smolvm machine start --name myvm
smolvm machine exec --name myvm -- apk add sl
smolvm machine exec --name myvm -it -- /bin/sh
# بالداخل: sl, ls, uname -a — اكتب 'exit' للخروج
smolvm machine stop --name myvm

استخدام git وSSH دون نسخ المفاتيح الخاصة إلى الضيف. مرّر وكيل SSH الخاص بمضيفك إلى الجهاز الافتراضي. يمكن للضيف أن يطلب من الوكيل التوقيع بأي مفتاح مُمرَّر طالما أن المقبس متاح، لذا مرّره فقط لأعباء العمل التي تثق بها. يتطلب وكيل SSH يعمل على مضيفك (ssh-add -l للتحقق).

smolvm machine run --ssh-agent --net --image alpine -- sh -c "apk add -q openssh-client && ssh-add -l"
# يعرض مفاتيح مضيفك؛ مادة المفتاح الخاص تبقى في وكيل المضيف

smolvm machine exec --name myvm -- git clone [email protected]:org/private-repo.git

الإعلان عن البيئات في ملف — انظر Smolfile أعلاه لتهيئة جهاز قابلة للتكرار، وللالتقاط لقطة لجهاز مُهيَّأ في صورة .smolmachine قابلة لإعادة الاستخدام دون كتابة Dockerfile.

كيف يعمل

يعمل كل عبء عمل في جهاز افتراضي مُحاكى على مستوى العتاد مع نواة ضيف خاصة به على Hypervisor.framework (macOS)، أو KVM (Linux)، أو Windows Hypervisor Platform (Windows). libkrun هو VMM وlibkrunfw يوفّر نواة الضيف. احزمه في .smolmachine وسيعمل في أي مكان تتطابق فيه بنية المضيف، دون أي تبعيات.

تستخدم الصور صيغة OCI — نفس المعيار المفتوح الذي يستخدمه Docker. يمكن سحب أي صورة من Docker Hub أو ghcr.io أو سجلات OCI أخرى وتشغيلها كجهاز مصغّر. لا حاجة لخادم Docker.

الافتراضيات: 4 vCPUs، 8 GiB RAM. الذاكرة مرنة عبر virtio balloon — يلتزم المضيف فقط بما يستخدمه الضيف فعليًا ويستعيد الباقي تلقائيًا. خيوط vCPU تنام في الهايبرفايزر عند الخمول، لذا فإن الإفراط في التزويد يكاد يكون مجانيًا. تجاوز ذلك بـ --cpus و --mem.

نموذج الأمان

يقوّي smolvm حدود الضيف/المضيف بمنح كل عبء عمل جهازًا افتراضيًا ونواة ضيف منفصلين. وهو ليس، بحد ذاته، مستوى تحكم متعدد المستخدمين محصّنًا:

• عمليات CLI وVMM في smolvm تعمل بصلاحيات مستخدم المضيف المستدعي. حساب المستخدم هذا، ونظام تشغيل المضيف، وخلفية الهايبرفايزر، وlibkrun، وsmolvm كلها ضمن قاعدة الحوسبة الموثوقة.
• أدلة المضيف الممرَّرة عبر --volume مكشوفة عمدًا للضيف بالوصول المطلوب. لا تُركّب أسرارًا أو مسارات حساسة في عبء عمل غير موثوق.
• --ssh-agent لا ينسخ مادة المفتاح الخاص إلى الضيف، لكنه يمنح الضيف وصولًا إلى مقبس الوكيل المُمرَّر وبالتالي القدرة على طلب التوقيعات أثناء تشغيل الجهاز الافتراضي.
• الشبكة معطلة افتراضيًا. تفعيل --net أو إعادة توجيه المنافذ أو خدمات المضيف يوسّع السطح الذي يمكن لعبء العمل الوصول إليه.
• في الاستخدام المحلي المستقل، تكون حالة smolvm ونقاط التحكم مقصورة على بيئة المستخدم المستدعي. للمشاركين المحليين العدائيين، أضف فصل حسابات على مستوى المضيف وتقييدًا لنظام التشغيل حول عملية VMM. لا يصف هذا القسم مستوى التحكم السحابي المنفصل لـ smolmachines أو ضمانات عزل المستأجرين فيه.
• أرشيفات الإصدارات تنشر مجاميع SHA-256 ويرفض المثبّت أي عدم تطابق عند توفر ملف المجموع. الإصدارات حاليًا غير موقّعة ولا مصحوبة بشهادات مصدر، ويسمح المثبّت بالتثبيت عند تعذر تنزيل ملف المجموع.

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

المقارنة

دعم المنصات

القيود المعروفة

• الشبكة اختيارية (--net على machine create). TCP/UDP فقط، لا ICMP.
• وحدات التخزين: أدلة فقط (لا ملفات مفردة). التركيب في /workspace (-v /host/dir:/workspace) له أولوية على مساحة عمل قرص التخزين الافتراضية — يُستخدم دليل مضيفك بدلًا منه.
• macOS: يجب أن يكون الملف الثنائي موقّعًا بامتيازات Hypervisor.framework (com.apple.security.hypervisor). الإصدار المُصدَر كذلك؛ الملف الثنائي المُعاد توقيعه أو المُبنى حديثًا يفقدها بصمت ويفشل كل تشغيل VM بعدها بـ krun_start_enter returned: -22 (EINVAL). أعد توقيعه (التوقيع المؤقت مقبول): codesign --force --sign - --entitlements hv.entitlements <smolvm-bin> حيث hv.entitlements ملف plist يحتوي <key>com.apple.security.hypervisor</key><true/>.
• --ssh-agent يتطلب وكيل SSH يعمل على المضيف (SSH_AUTH_SOCK يجب أن يكون مضبوطًا).
• تسريع GPU يتطلب libkrun مبنيًا بـ GPU=1 وvirglrenderer + برنامج تشغيل Vulkan على المضيف (انظر تسريع GPU أدناه).
• Windows: --net يعمل كما في المنصات الأخرى (virtio-net مع إعادة توجيه المنافذ الواردة؛ TSI للأجهزة ذات الاتصال الصادر فقط)، وكذلك machine exec / الجلسات التفاعلية وmachine stats. غير متاح بعد على Windows: تسريع GPU وmachine fork / اللقطات. إنشاء pack يحتاج storage-template.ext4 / overlay-template.ext4 بجوار smolvm.exe (Windows لا يحتوي على mkfs.ext4 للمضيف).

تسريع GPU

يكشف smolvm GPU المضيف للضيوف عبر virtio-gpu / Venus (Vulkan عبر virtio). أعباء عمل الضيف ترى جهاز Vulkan حقيقيًا؛ على Linux + Intel يُعرض هذا كالتالي:

ANGLE (Intel, Vulkan 1.4 (Virtio-GPU Venus (Intel(R) UHD Graphics ...)), venus)

متطلبات المضيف

macOS — virglrenderer وMoltenVK مضمّنان في توزيعة smolvm. لا حاجة لتثبيتات إضافية.

Linux — يجب تثبيت virglrenderer وبرنامج تشغيل Vulkan للمضيف من مدير حزم النظام:

يعتمد virglrenderer على libEGL وlibdrm من حزمة برنامج تشغيل GPU للمضيف — وهذه خاصة بالعتاد ولا يمكن تضمينها. أي مضيف Linux قادر على GPU سيكون قد ثبّتها بالفعل عبر برنامج تشغيل GPU الخاص به.

الاستخدام

# CLI
smolvm machine run --gpu --image alpine -- vulkaninfo --summary

# Smolfile
# gpu = true
# gpu_vram = 2048   # MiB، الافتراضي 4096

يجب توجيه مُحمِّل Vulkan للضيف إلى ICD الخاص بـ virtio:

export VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/virtio_icd.x86_64.json

مثال متصفح بدون واجهة

انظر examples/headless-browser/ لإعداد Chromium عامل باستخدام ANGLE + Venus لتسريع WebGL بالعتاد داخل جهاز افتراضي بدون واجهة.

إعادة توجيه واجهة CUDA API

يوفر --gpu و --cuda واجهات مختلفة. --gpu يكشف Vulkan عبر virtio-gpu / Venus؛ ولا يوفر CUDA. --cuda يفعّل إعادة توجيه واجهة CUDA API: شِقّات ضيف بدون برنامج تشغيل تُمرّر استدعاءات CUDA عبر vsock إلى عملية مضيفة تنفّذها عبر برنامج تشغيل NVIDIA للمضيف.

تتطلب إعادة توجيه CUDA وحدة معالجة رسومية NVIDIA وبرنامج تشغيل NVIDIA عاملًا على المضيف. وهي ليست تمرير GPU: الضيف لا يستلم الجهاز الفعلي ولا برنامج تشغيل NVIDIA.

يجب على مضيفات Linux كثيفة fork استخدام نواة تحتوي إصلاح KVM العلوي 916b7f4. يمكن للنوى المتأثرة الإبلاغ بشكل متقطع عن ENOMEM عند أول KVM_RUN حتى مع ذاكرة مضيف وفيرة؛ يقلل smolvm من التعرض ويستبدل العامل الفاشل، لكن تحديث النواة هو الإصلاح الحاسم.

لا تزال حدود الجهاز الافتراضي تعزل CPU وذاكرة ونظام ملفات عبء العمل. وصول GPU يتم بوساطة عمليات المضيف وGPU المضيف المشترك، لذا يبقى عزل GPU على مستوى العملية وليس حدًا للعتاد أو الجهاز الافتراضي. لا تعامل إعادة توجيه CUDA كحد عزل GPU متعدد المستأجرين محصّن.

انظر وصول GPU عبر إعادة توجيه API: كيف يشغّل جهاز مصغّر بدون برنامج تشغيل CUDA للتصميم والمقايضات والمقارنة مع التمرير.

التطوير

انظر docs/DEVELOPMENT.md.

Apache-2.0 · صنعه @binsquare · تويتر · جيت هاب