اگر از داکر دسکتوپ خسته شده‌اید و می‌خواهید هر سرویس را در محیطی کاملاً ایزوله اجرا کنید، ابزار جدید اپل دقیقاً برای شماست. تصور کنید به جای یک آپارتمنت بزرگ که همه در آن مشترک‌اند، برای هر مهمان یک ویلای کوچک و مجزا می‌سازید تا امنیت به حداکثر برسد.
طبق مستندات منتشر شده در marktechpost.com، تیم پژوهشی اپل ابزاری متن‌باز به نام container را معرفی کرده است که با زبان سویفت (Swift) نوشته شده و به جای تکیه بر معماری‌های سنتی، برای هر کانتینر یک ماشین مجازی سبک (Lightweight VM) ایجاد می‌کند. در معماری‌های سنتی کانتینرها از یک هسته مشترک استفاده می‌کنند، اما در مدل اپل، هر محیط جداسازی کامل یک ماشین مجازی را دارد که سطح حملات امنیتی را به‌شدت کاهش می‌دهد.
همان‌طور که در تحلیل‌های پیشین ما درباره امنیت محیط‌های توسعه اشاره کردیم، جداسازی سخت‌افزاری همیشه امن‌تر از جداسازی نرم‌افزاری است. برای سال‌ها، توسعه‌دهندگان مک به ابزارهایی مثل داکر دسکتوپ (Docker Desktop) متکی بودند که معمولاً یک ماشین مجازی سنگین و همیشه فعال را برای میزبانی از تمام کانتینرها اجرا می‌کرد. اما ابزار جدید اپل این بار اضافیات (Overhead) را حذف کرده است؛ به طوری که سیستمی ایجاد شده که در آن هزینه حافظه در حالت بیکاری تقریباً صفر است، زیرا کانتینرهای متوقف شده، اثر (Footprint) خود را به‌طور کامل آزاد می‌کنند.
این ابزار به‌طور اختصاصی برای اپل سیلیکون (Apple Silicon) ساخته شده و از مک‌های اینتل پشتیبانی نمی‌کند. container تحت لایسنس Apache 2.0 منتشر شده است. اگرچه این ابزار روی macOS 15 اجرا می‌شود، اما برای بهره‌مندی از تمام قابلیت‌های مجازی‌سازی و بهبودهای شبکه، نیاز به macOS 26 دارد. این ابزار با چارچوب‌های اصلی macOS ادغام شده است و برای مدیریت ماشین‌های مجازی از Virtualization framework و برای شبکه از vmnet framework استفاده می‌کند.
زمینه و معماری
موتور زمان اجرا (The Runtime Engine)
این ابزار برای مدیریت سطح پایین کانتینرها، تصاویر و فرآیندها از بسته متن‌باز Containerization Swift استفاده می‌کند. بر اساس مستندات فنی، برای ارتباط بین پردازش‌ها (IPC) از XPC و برای مدیریت سرویس‌ها از launchd بهره می‌برد. همچنین اعتبارنامه‌های ریجستری توسط خدمات Keychain مدیریت می‌شوند تا امنیت دسترسی‌ها حفظ شود.
لایه کنترل (The Control Plane)
سیستم از چندین بخش متحرک تشکیل شده است. با اجرای دستور container system start ابتدا container-apiserver به عنوان یک Launch Agent فعال می‌شود. سپس این سرور یک کمکی XPC به نام container-core-images را برای مدیریت تصاویر محلی و ذخیره‌سازی محتوا فراخوانی می‌کند. در کنار این‌ها، container-network-vmnet برای مدیریت شبکه مجازی‌سازی فعال می‌گردد. در نهایت، برای هر کانتینر مجزایی که ایجاد شود، یک نمونه از container-runtime-linux اجرا می‌گردد تا محیط اجرای لینوکسی را فراهم کند.
مشخصات فنی و قابلیت‌ها
- سازگاری تصاویر: این ابزار تصاویر سازگار با استاندارد OCI را مصرف و تولید می‌کند. این بدان معناست که شما می‌توانید مستقیماً از داکر هاب (Docker Hub) یا گیتهاب کانتینر ریجستری (GitHub Container Registry) تصویر دریافت کنید. همچنین می‌توانید تصاویری که به‌صورت محلی ساخته‌اید را به هر ریجستری استانداردی ارسال (Push) کنید.
- منابع پیش‌فرض: هر نمونه به‌طور پیش‌فرض با ۱ گیگابایت رم و ۴ پردازنده (CPU) شروع می‌شود. با این حال، کاربران می‌توانند این مقادیر را از طریق خط فرمان تغییر دهند؛ برای مثال با دستور
container run --rm --cpus 8 --memory 32g bigمی‌توان منابع را افزایش داد. - پشتیبانی معماری: این ابزار هم از تصاویر arm64 و هم x86-64 پشتیبانی می‌کند. تصاویر x86-64 از طریق لایه ترجمه روزیتا (Rosetta) اجرا می‌شوند. این قابلیت اجازه می‌دهد تا یک تصویر واحد را برای هر دو محیط اپل سیلیکون و سرورهای x86-64 بسازید.
- موتور ساخت: برای ساخت تصاویر از BuildKit استفاده می‌کند که در یک کانتینر سازنده (Builder Utility Container) اختصاصی اجرا می‌شود. کاربران می‌توانند اندازه این ماشین مجازی را برای ساخت‌های سنگین با دستور
container builder start --cpus 8 --memory 32gتنظیم کنند.
یکی از مهم‌ترین اضافات در نسخه ۱.۰.۰، معرفی «ماشین‌های کانتینری» (Container Machines) است. این‌ها محیط‌های لینوکسی پایداری هستند که از تصاویر OCI ساخته شده‌اند و سیستم‌فایل آن‌ها پس از چرخه‌های توقف و شروع مجدد، حفظ می‌شود (Persistent). در این حالت، پوشه Home کاربر مک به داخل متصل (Mount) شده و کاربر لاگین شده در لینوکس به‌طور خودکار با حساب کاربری مک مطابقت می‌کند. هر تصویری که شامل مسیر /sbin/init باشد، واجد شرایط تبدیل شدن به یک ماشین کانتینری است.
تغییرات نسخه ۱.۰.۰
- پیکربندی: تنظیمات سیستم به یک فایل TOML در مسیر
~/.config/container/config.tomlمنتقل شده است. - تغییرات CLI: زیردستورهای
container system property getوsetاز ابزار حذف شده‌اند. - اتوماسیون: این ابزار اکنون از خروجی‌های ساختاریافته JSON، YAML و TOML برای دستورات
listوinspectپشتیبانی می‌کند تا ادغام با سایر ابزارهای اتوماسیون آسان‌تر شود.
مقایسه‌ی Apple container با Docker Desktop
برخلاف مدل هسته مشترک در داکر دسکتوپ، container جداسازی سخت‌گیرانه‌ای فراهم می‌کند. برای مثال، شما می‌توانید کدهای نامطمئن را از یک تصویر ناشناس، بدون اینکه هسته میزبان (Host Kernel) را در معرض خطر قرار دهید، ایزوله کرده و اجرا کنید؛ زیرا هر کانتینر در ماشین مجازی خودش اجرا می‌شود.
اما این مدل هزینه دارد: در حال حاضر هیچ قابلیت داخلی برای داکر کامپوز (Docker Compose) وجود ندارد و برخی کاربران ممکن است با مشکل «تورم حافظه» (Memory Ballooning) مواجه شوند. به دلیل اینکه چارچوب مجازی‌سازی macOS تنها از تورم حافظه جزئی پشتیبانی می‌کند، صفحاتی که در داخل کانتینر آزاد می‌شوند، همیشه به میزبان برنمی‌گردند. این یعنی در بارهای کاری بسیار سنگین، ممکن است نیاز به ری‌استارت‌های گاه‌به‌گاه باشد.
این تغییر به این معناست که توسعه‌دهندگان اکنون می‌توانند یک سرویس را در ماشین مجازی ایزوله خود اجرا کرده و پورت آن را به یک آدرس لوکال (Loopback) منتقل کنند. برای مثال با دستور ساده: container run -d -p 127.0.0.1:8080:8000 node:latest. همچنین در macOS 26 امکان ایجاد شبکه‌های ایزوله با دستور container network create foo --subnet 192.168.100.0/24 فراهم شده است، تا اطمینان حاصل شود کانتینرهای موجود در شبکه‌های مختلف نمی‌توانند با هم ارتباط برقرار کنند.
برای یک توسعه‌دهنده معمولی، این حرکت تأییدی بر روند حرکت به سمت «میکرو-ماشین‌های مجازی» (micro-VMs) برای ارتقای امنیت است. با پذیرفتن تأخیری اندک در زمان بوت — که اپل ادعا می‌کند اکنون با ماشین‌های مجازی مشترک قابل مقایسه است — جهشی بزرگ در حریم خصوصی و امنیت خواهید داشت. دیگر نیازی نیست کل پوشه Home خود را با یک ماشین مجازی عظیم و یکپارچه به اشتراک بگذارید؛ بلکه می‌توانید فقط داده‌های مورد نیاز هر VM را از طریق پرچم --volume متصل کنید.
این ابزار برای اجرای تک‌کانتینرهایی که نیاز به ایزولاسیون بالا دارند، ایده‌آل است. کسانی که در جریان‌های کاری پیچیده Compose غرق شده‌اند، فعلاً داکر دسکتوپ را به دلیل اکوسیستم بالغ‌ترش کاربردی‌تر می‌بینند، اما مسیر بومی اپل، «دیوار پرداخت» (Commercial Paywall) یا هزینه‌های تجاری مرتبط با ابزارهای سازمانی کانتینر را حذف می‌کند.
گام بعدی شما
- اگر از مک‌های سری M استفاده می‌کنید و در حال بهینه‌سازی استک توسعه محلی هستید، توانایی این ابزار در اجرای تصاویر چند-معماری (Multi-arch) را برای استقرار در دیتاسنتر تست کنید.
- برای کارهای حساس امنیتی، به جای داکر، از این ابزار برای اجرای ایمیج‌های ناشناس استفاده کنید تا هسته سیستم‌عامل شما در امان بماند.
- بررسی کنید که آیا نیاز شما به مدیریت شبکه‌های پیچیده است یا جداسازی کامل هر سرویس برای افزایش حریم خصوصی.
اما نقطه حساس بعدی این است که آیا اپل معادل بومی برای Compose می‌سازد یا این ابزار را صرفاً روی اجرای سبک و ایزوله متمرکز نگه می‌دارد؛ تحولی که می‌تواند جایگاه داکر را در اکوسیستم مک به چالش بکشد.
گفتگو