Pullrun: یک محیط اجرای واحد برای کانتینرها و میکرو-ماشین‌های مجازی

تصور کنید یک برنامه‌نویس بتواند دقیقاً همان ایمیجی را که در محیط توسعه روی لپ‌تاپش اجرا می‌کند، بدون تغییر حتی یک بیت، در محیط تولید با بالاترین سطح ایزولاسیون سخت‌افزاری مستقر کند. Pullrun در ۲۳ ژوئیه ۲۰۲۶ با شعار «یک باینری برای پل زدن میان شکاف‌ها» معرفی شد تا هدف بلندپروازانه خود را در قالب ادغام کانتینرهای توسعه و میکرو-ماشین‌های مجازی (microVMs) تولید محقق کند. این ابزار اجازه می‌دهد یک ایمیج واحد OCI بسته به نیاز، یا به عنوان یک پردازش سبک (lightweight process) یا به عنوان یک ماشین مجازی کاملاً ایزوله بوت شود.

در حال حاضر، زیرساخت‌های ابری مدرن میان چندین موتور اجرا تقسیم شده‌اند. توسعه‌دهندگان معمولاً برای کارهای محلی از Docker، برای محیط تولید از containerd و برای بارهای کاری که نیاز به ایزولاسیون بسیار بالا دارند از Firecracker استفاده می‌کنند. هر یک از این موتورها مدل عملیاتی، لایه‌های ذخیره‌سازی و مکانیسم‌های مدیریت متفاوتی دارند، حتی اگر همگی از ایمیج‌های استاندارد OCI (Open Container Initiative) استفاده کنند. این تکه‌تکه بودن زیرساخت، پیچیدگی‌های عملیاتی زیادی ایجاد می‌کند.

همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت لایه‌های ذخیره‌سازی مدل‌های باز-متن اشاره کردیم، پیچیدگی لایه‌ها همیشه نقطه‌ای برای آسیب‌پذیری بوده است. Pullrun به عنوان یک جایگزین واحد و یکپارچه وارد می‌شود؛ این ابزار شامل یک CLI بسیار سبک با حجم حدود ۱۴ مگابایت و یک دیمون (Daemon) اجرایی با حجم حدود ۶ مگابایت (در حالت stripped) است که به‌طور خاص طراحی شده تا نیاز به یک دیمون مرکزی و سنگین مانند dockerd را کاملاً حذف کند. طبق مستندات این پروژه، با تبدیل مانیفست OCI به rootfs ماشین مجازی، مرحله‌ی مجزای ساخت VM به‌طور کامل حذف شده است. کاربر می‌تواند از طریق دستور pullrun run یک تجربه‌ی کاملاً «بدون دیمون» (daemonless) داشته باشد، اگرچه یک دیمون اختیاری برای مدیریت سرویس‌های پس‌زمینه در دسترس است.

نصب و پیکربندی پلتفرم

به نقل از تیم توسعه، Pullrun برای استقرار سریع در تمام پلتفرم‌های اصلی از طریق یک دستور ساده طراحی شده است: curl -fsSL https://github.com/pullrun/pullrun/raw/main/install.sh | bash.

• در macOS: این ابزار از طریق دستور brew tap pullrun/tap && brew install pullrun نصب می‌شود و یک باینری بومی را فراهم می‌کند که نیازی به وابستگی‌های پیچیده Xcode برای بیلد ندارد. این بهینه‌سازی روی مک یادآور تلاش‌های اخیر برای افزایش کارایی سخت‌افزاری است، همان‌طور که فریم‌ورک Espresso توانست سرعت استنتاج مدل‌ها را روی مک به‌شدت افزایش دهد.
• در لینوکس: Pullrun به عنوان یک پکیج APT یا از طریق دانلود مستقیم در دسترس است. این ابزار با سرویس‌های systemd ادغام شده و برای اجرای کانتینر به runc و برای فراهم کردن قابلیت‌های VM به /dev/kvm نیاز دارد.
• در ویندوز: ابزار در قالب pullrun.exe عرضه شده و شامل قابلیت Provisioning خودکار برای WSL2 است تا هم از runc و هم از Firecracker پشتیبانی کند.
• از طریق سورس کد: کاربران می‌توانند با استفاده از دستور make build آن را بیلد کنند. همچنین قابلیت Cross-compilation برای ویندوز با دستور GOOS=windows GOARCH=amd64 CGO_ENABLED=0 go build -o pullrun.exe . فراهم شده است.

معماری Zero-Copy DAG: قلب تپنده سیستم

هسته‌ی این سیستم یک ذخیره‌ساز گراف جهت‌دار بدون دور (DAG) است که با استفاده از محتوا آدرس‌دهی شده (content-addressed) و بر پایه کتابخانه‌های rkyv و mmap بنا شده است. برای درک ساده‌تر، ساختار DAG — شبیه به یک درخت تصمیم پیچیده است که در آن هر شاخه به یک قطعه از داده اشاره می‌کند و هیچ راهی برای بازگشت به عقب وجود ندارد — جایگزین سیستم‌های لایه‌ای OverlayFS در داکر شده است. در حالی که داکر از یک لایه‌ی فایل‌سیستمی استفاده می‌کند، Pullrun لایه‌ها را دقیقاً به همان شکلی که هستند ذخیره کرده و آن‌ها را از طریق هش محتوا تایید می‌کند. این رویکرد اجازه می‌دهد داده‌ها بدون کپی شدن (Zero-Copy) خوانده شوند و تضمین می‌کند که هر گره‌ای که یک نسخه خاص از ایمیج را دریافت می‌کند، فایل‌های کاملاً یکسانی را روی دیسک ذخیره کرده است.

از نظر فنی، این ذخیره‌ساز از DashMap<Digest, Arc<Mmap>> برای خواندن‌های هم‌زمان بدون قفل (lock-free) استفاده می‌کند. در این مدل، اولین خواننده هزینه مربوط به mmap() و خطاهای صفحه (page faults) را می‌پردازد، اما هر خواننده بعدی تنها یک بارگذاری اتمیک (atomic load) ساده انجام می‌دهد. این یعنی دیگر نیازی به پردازش سنگین توسط یک پروسه‌ی dockerd برای مالکیت داده‌ها یا استخراج هزینه‌بر فایل‌های tar نیست. این مدیریت بهینه از حافظه و دیسک، شباهت زیادی به رویکردهای پیشرفته در اجرای مدل‌های عظیم دارد؛ برای مثال پروژه‌ی Colibrì توانست مدل‌های ۷۴۴ میلیارد پارامتری را با استفاده از استریمینگ دیسک در رم‌های محدود اجرا کند.

این معماری به‌طور مشخص نقاط ضعف امنیتی را هدف قرار داده است. بر اساس بررسی‌های فنی، با حذف overlayfs، ریسک‌های مربوط به فرار از کانتینر (مانند CVE-2023-0386 و CVE-2023-32629) به‌شدت کاهش می‌یابد. علاوه بر این، استفاده از بک‌اندهای VM (مانند Firecracker یا Apple Virtualization) خطر اشتراک کرنل را از بین می‌برد (مانند باگ "Copy Fail" در CVE-2026-31431) زیرا هر نمونه دارای کرنل اختصاصی خود است. Pullrun به‌صورت پیش‌فرض rootless است و با حذف دیمون مرکزی که به TCP گوش می‌دهد، سطح حمله (Attack Surface) را به‌طور کامل محدود می‌کند.

بنچمارک‌ها و عملکرد

طبق داده‌های منتشر شده از اسکریپت hack/bench.sh که بر روی یک سیستم Apple M3 (macOS 14) اجرا شده و با استفاده از ابزار hyperfine در ۱۰ تکرار یا بیشتر تست شده است، عملکرد Pullrun به‌طور قابل‌توجهی بهتر از Docker Desktop 4.27 است:

• اولین دریافت ایمیج (First Image Pull): ایمیج Alpine 3.18 در ۹۶۸ میلی‌ثانیه دریافت شد، در حالی که این زمان در داکر حدود ۲ ثانیه است.
• تأخیر اجرای کانتینر: زمان اجرای دستور (از لحظه خروج دستور تا زنده شدن PID) حدود ۴۰۰ میلی‌ثانیه است، در مقابل ۸۰۰ میلی‌ثانیه در داکر.
• زمان بوت VM: در Apple Virtualization، سیستم در حدود ۱۶۰ میلی‌ثانیه به یک Prompt تعاملی می‌رسد. در Firecracker، بوت سرد (Cold Boot) حدود ۵۰۰ میلی‌ثانیه زمان می‌برد، اما با استفاده از یک Warm Pool (پیکربندی شده با --vm-warm-pool-size 4) این زمان به ۲۰۰ میلی‌ثانیه کاهش می‌یابد.
• اشغال حافظه: دیمون در حالت بیکار تنها ۲۴.۶ مگابایت حافظه RSS اشغال می‌کند، در حالی که این مقدار برای داکر حدود ۹۰ مگابایت است.

پشتیبانی گسترده از بک‌اندهای ایزولاسیون

Pullrun ایزولاسیون را متناسب با پلتفرم میزبان تنظیم می‌کند تا یک ایمیج و دستور واحد در سیستم‌عامل‌های مختلف یکسان عمل کند. برای مثال، دستور pullrun run alpine:3.18 --cmd "echo" --cmd "hello pullrun" در لینوکس و ویندوز WSL2 دقیقاً یک نتیجه می‌دهد:

• کانتینرهای لینوکسی: از runc برای ایزولاسیون در سطح پردازش در لینوکس، macOS و ویندوز (WSL2) استفاده می‌کند.
• میکرو-VMهای Firecracker: ایزولاسیون کرنل اختصاصی برای هر VM فراهم می‌کند (برای لینوکس و ویندوز WSL2). این VMها مانند ماشین‌های هایبرناته شده عمل می‌کنند؛ به این معنا که VMهای متوقف شده تمام تغییرات (writes) را حفظ کرده و در صورت درخواست، از طریق exec و با استفاده از ایمیج ext4 مجدداً استارت می‌شوند.
• VMهای اپل سیلیکون: از Hypervisor.framework برای توسعه بومی macOS و محیط‌های CI استفاده می‌کند و rootfs را از طریق VirtioFS پایدار می‌سازد.

قابلیت‌های عملیاتی پیشرفته

این پلتفرم فراتر از اجرا، ابزارهای زیرساختی کاملی را ادغام کرده است. Pullrun شامل یک سازنده (Builder) بومی Dockerfile است که از دستورات FROM ،RUN ،COPY ،ADD ،WORKDIR ،ENV ،CMD و ENTRYPOINT پشتیبانی می‌کند. این سازنده برای دستورات RUN مستقیماً از runc استفاده کرده و سیستم کشینگ لایه‌ها را بر اساس هش دستورات پیاده کرده است. همچنین از بیلد‌های چند-پلتفرمی از طریق فلگ --platform linux/amd64,linux/arm64 پشتیبانی می‌کند.

در مدیریت ایمیج‌ها و بارهای کاری، قابلیت‌های عمیقی ارائه شده است:

• مدیریت ایمیج: دستور commit یک لایه جدید از فایل‌سیستم کانتینر جاری ایجاد می‌کند (از طریق محاسبه Delta نسبت به ایمیج اصلی). دستور diff تغییرات سطح فایل (افزودن/تغییر/حذف) را با مقایسه درخت‌های DAG لیست می‌کند. دستور rmi ایمیج‌ها را بر اساس تگ یا Digest حذف کرده و گره‌های زیرشاخه‌ی غیرقابل دسترس را پاک می‌کند. این کار با استفاده از فایل‌های Sidecar برای شمارش مراجع (node.refcount) انجام می‌شود تا لایه‌های مشترک تنها زمانی پاک شوند که آخرین ایمیج ارجاع‌دهنده حذف شده باشد.
• جمع‌آوری زباله (GC): دستور gc گره‌های یتیم (orphaned layers) را پاک می‌کند. این قابلیت دارای حالت Dry-run و فلگ --force برای دور زدن گارد امنیتی ۹۰٪ است و از قفل‌های عملیاتی (op-lock) برای محافظت از عملیات در حال اجرا و پین کردن ایمیج‌های کرنل VM استفاده می‌کند.
• کنترل بارهای کاری: دستور update اجازه تغییر زنده مقدار CPU (به میلی-کور) و حافظه (به بایت) را بدون ری‌استارت دادن به ورک‌لود می‌دهد. دستور cp برای کپی دوطرفه فایل بین میزبان و ورک‌لود تعبیه شده است. دستورات save و load برای خروجی/ورودی Tarball سازگار با OCI جهت استفاده در محیط‌های Air-gapped فراهم شده‌اند.
• سلامت و پایداری: پشتیبانی از health-cmd برای بررسی دوره‌ای سلامت (مثل curl -f http://localhost:80) با بازه‌های زمانی و تایم-اوت قابل تنظیم. سیاست‌های restart شامل on-failure ،always و unless-stopped برای مدیریت خودکار خروج‌هاست. دستور exec اجازه اتصال مجدد به ورک‌لودهای Detached را از طریق /bin/sh یا استریم I/O دوطرفه می‌دهد.
• شبکه: شامل شبکه‌های Bridge تعریف شده توسط کاربر با IPAM و DNS است. پنج حالت شبکه تعریف شده است: isolated (پیش‌فرض کانتینرها، فقط loopback از طریق پروکسی میزبان در 10.42.0.1)، bridge (به اشتراک گذاشتن pullrun-br0)، slirp (پیش‌فرض VMها از طریق slirp4netns)، host (اشتراک فضای نام/namespace) و none.

یکپارچگی با Kubernetes و Docker Compose

Pullrun از طریق باینری pullrun-compose از گردش‌کارهای استاندارد داکر کامپوز پشتیبانی می‌کند و فایل‌های docker-compose.yml را با استفاده از کتابخانه compose-spec/compose-go پارس می‌کند. این ابزار از مرتب‌سازی توپولوژیک وابستگی‌ها، مپ کردن پورت‌ها، متغیرهای محیطی، Bind-mount volumes و شبکه‌های Bridge هر پروژه پشتیبانی می‌کند. یک ویژگی کلیدی این است که با یک فلگ ساده --backend vm می‌توان کل استک را بدون تغییر در فایل کامپوز، به ایزولاسیون Firecracker منتقل کرد.

برای کوبرنتیز، Pullrun یک CRI shim در مسیر cri/pullrun-cri/ ارائه می‌دهد که سرویس‌های RuntimeService و ImageService را پیاده می‌کند. این امر اجازه می‌دهد پادها از طریق RuntimeClass (به‌طور خاص pullrun-container یا pullrun-vm) به ورک‌لودهای Pullrun مپ شوند. همچنین از Annotationهای پاد برای بازنویسی CPU و حافظه (مثلاً pullrun.io/cpu-millicores) و استریم برای exec و port-forward پشتیبانی می‌شود.

استقرار در کوبرنتیز به‌صورت یک DaemonSet با استفاده از مانیفست‌های runtime-daemon.yaml ،serviceaccount.yaml و servicemonitor.yaml انجام می‌شود. یک Stub کنترل-پلین بومی (pullrun-controller و pullrun-agent) از طریق gRPC ارتباط برقرار می‌کند و پشتیبانی از etcd و DNSهای .pullrun.local در نقشه‌ی راه آینده قرار دارد.

قابلیت‌های پیشرو: عامل‌های هوش مصنوعی و P2P

یکی از متمایزترین ویژگی‌ها، سرور بومی پروتکل زمینهٔ مدل (MCP) است. این قابلیت به عامل‌های هوش مصنوعی (AI Agents) — مانند Claude Code، Cursor یا opencode — اجازه می‌دهد تا از طریق زبان طبیعی، runtime را کنترل کنند. این سرور ۱۵ ابزار عملیاتی (شامل run ،stop ،exec ،list ،get ،inspect ،logs ،stats ،pull_image ،list_images ،build ،push ،prune ،compose_up و compose_down) و ۴ نوع منبع (مثلاً pullrun://workload/{id}/logs) را در اختیار عامل‌ها قرار می‌دهد. این سرور در حالت stdio برای عامل‌های محلی یا حالت SSE (از طریق --sse :8080) برای عامل‌های ریموت عمل می‌کند. این رویکرد برای کنترل زیرساخت توسط AI، مشابه ایده‌ی پروژه‌ی FableCut است که از JSON برای تبدیل دستورات عامل‌های هوش مصنوعی به عملیات تدوین ویدیو استفاده می‌کند.

برای رفع گلوگاه ریجستری در خوشه‌های بزرگ، Pullrun توزیع P2P ایمیج‌ها را پیاده کرده است. گره‌ها بلوک‌های ایمیج را از طریق gRPC و فیلترهای Bloom با سرعت شبکه محلی (LAN) به اشتراک می‌گذارند. در این مدل، تنها یک گره از ریجستری دانلود می‌کند و بقیه گره‌ها به‌صورت دلتا-سینک از یکدیگر داده می‌گیرند. سیستم از mDNS برای کشف خودکار (zero-config) و پروتکل Gossip برای مدیریت وضعیت هم‌سایگان استفاده می‌کند. هر بلوک قبل از پذیرش با هش محتوا تایید می‌شود تا نیازی به اعتماد به گره همسایه نباشد.

امنیت و اجرای سیاست‌ها

یک موتور سیاست‌گذاری (Policy Engine) деклараاتیو برای کنترل دسترسی بارهای کاری وجود دارد. سیاست‌های پشتیبانی شده عبارتند از:

• تایید Cosign: تطبیق جفت‌کلید Ed25519 و ID کلید.
• ارزیابی SBOM: امتیازدهی CVSS و ممنوع کردن لایسنس‌های خاص (مثلاً deny_licenses: ["GPL-3.0"]).
• محدودیت‌های سیستمی: پروفایل‌های Seccomp (با لیست سفید پیش‌فرض حدود ۵۰ syscall)، استفاده از readonly-rootfs برای جلوگیری از دستکاری در زمان اجرا و no_new_privileges برای مسدود کردن ارتقای سطح دسترسی setuid و capset.

مدیریت اسرار (Secrets) از طریق pullrun secret create انجام می‌شود. داده‌ها در حالت سکون با AES-256-GCM رمزگذاری شده و در لحظه اجرا مستقیماً در tmpfs ورک‌لود رمزگشایی می‌شوند تا تضمین شود داده‌های حساس هرگز به صورت متن ساده (plaintext) روی دیسک دائمی ذخیره نمی‌شوند.

معماری داخلی و طراحی

Pullrun به عنوان یک Workspace در زبان Rust شامل ۱۱ کریت (crate) و یک CLI مبتنی بر Go ساختار یافته است. دیت-پلین هسته شامل موارد زیر است:

• pullrun-store: ذخیره‌ساز Zero-copy DAG با استفاده از rkyv و mmap.
• pullrun-oci: کلاینت OCI و مبدل DAG.
• pullrun-exec: Trait اجراکننده و Wrapper دور runc.
• pullrun-vm: مدیریت بک‌اندهای Firecracker و Apple Virt، شامل pool.rs برای Warm VM Pool و عامل pullrun-init در مهمان.
• pullrun-net: مدیریت IPAM، پروکسی، DNS، iptables و slirp4netns.
• pullrun-sync: پیاده‌سازی سینک بلوکی P2P از طریق Bloom filters و Gossip.
• pullrun-policy: مدیریت گیت‌های Cosign و SBOM.

باینری‌های کرنل نیز به عنوان محتوای درجه-یک OCI تلقی می‌شوند. کاربران با دستور pullrun kernel install می‌توانند vmlinux را از یک ریجستری به ذخیره‌ساز DAG دانلود کنند. سپس با فلگ --kernel-image هر ورک‌لود می‌تواند یک کرنل سفارشی را با ارجاع OCI مشخص کند، که تضمین می‌کند کرنل‌ها از طریق Digest تایید شده و برای همیشه کش شوند.

این تغییر به سمت یک runtime مبتنی بر DAG و چند-بک‌انداز، این فرض بنیادین را می‌شکند که برای سطوح مختلف ایزولاسیون به فرمت‌های ایمیج متفاوت نیاز داریم. برای توسعه‌دهندگان، این یعنی فاصله بین «روی سیستم من کار می‌کند» و «در محیط تولید امن است» به‌طور موثر از بین رفته است. کاربران می‌توانند همین حالا با اسکریپت نصب تک‌خطی یا استقرار CRI shim به عنوان یک DaemonSet در کوبرنتیز، این ابزار را تجربه کنند.

گام بعدی شما

• اگر از Docker Desktop خسته شده‌اید، اسکریپت نصب تک‌خطی Pullrun را روی مک یا لینوکس تست کنید.
• برای محیط‌های حساس، حالت --backend vm را جایگزین کانتینرهای معمولی کنید تا از ایزولاسیون کامل کرنال بهره‌مند شوید.
• اگر از Cursor یا Claude Code استفاده می‌کنید، سرور MCP را فعال کنید تا هوش مصنوعی بتواند مستقیماً کانتینرها و ورک‌لودهای شما را مدیریت کند.

اما داستان توزیع داده‌ها در مقیاس هزاران گره حتی پیچیده‌تر است — به بررسی ما درباره‌ی پروتکل‌های Gossip در سیستم‌های توزیع‌شده مراجعه کنید.