خلاصه سریع: Docker VMM لایه مجازیسازی اختصاصی و بهینهشده برای کانتینرهای Docker Desktop است. Docker این VMM بازطراحیشده را از نسخه 4.86 بهصورت Public Beta برای Mac و Windows ارائه کرده تا کنترل بیشتری روی ماشین لینوکسی زیر Docker Desktop داشته باشد، زمان راهاندازی را کاهش دهد، I/O بین Host و کانتینر را بهتر کند و حافظه بلااستفاده را سریعتر به سیستمعامل میزبان برگرداند. نکته مهم این است که Docker VMM مربوط به Docker Desktop است؛ اگر Docker Engine را مستقیم روی یک سرور لینوکسی یا VPS اجرا میکنید، این لایه مجازیسازی در مسیر اجرای شما قرار ندارد.
Docker VMM چیست و چرا Docker آن را ساخته است؟
Docker Engine ذاتاً برای لینوکس طراحی شده است. وقتی Docker Desktop روی macOS یا Windows اجرا میشود، برای اجرای کانتینرهای لینوکسی به یک ماشین مجازی سبک نیاز دارد. VMM یا Virtual Machine Manager همان لایهای است که ایجاد و مدیریت این VM را ممکن میکند.
Docker در نسخههای قبلی Desktop از چند فناوری مختلف برای این بخش استفاده میکرد. در Public Beta جدید، شرکت یک VMM اختصاصی را از پایه بازطراحی کرده و آن را برای بارهای کانتینری بهینه کرده است. طبق اعلام رسمی Docker، این لایه از Docker Desktop 4.86 روی Mac و Windows در دسترس قرار گرفته است.
برای کاربر نهایی، هدف فقط «عوض شدن Hypervisor» نیست؛ Docker میخواهد بخش بیشتری از مسیر بین سیستمعامل میزبان، فایلسیستم، حافظه و Docker Engine را خودش کنترل و بهینه کند.
چه چیزی در Docker Desktop 4.86 تغییر کرده است؟
سه تغییر عملی مهم در مستندات Docker برجسته شدهاند:
- بازگرداندن حافظه بلااستفاده به Host: وقتی کانتینرها غیرفعال هستند، Docker VMM میتواند RAM بلااستفاده را بهتر به سیستمعامل میزبان برگرداند تا Docker Desktop حافظهای را که نیاز ندارد نگه ندارد.
- بهبود File I/O بین Host و Container: در پروژههایی که کد روی Host و فرآیند Build/Test داخل کانتینر اجرا میشود، کاهش تأخیر فایلسیستم میتواند چرخه edit-compile-test را روانتر کند.
- راهاندازی سریعتر Engine و کانتینرها: Docker VMM برای کاهش زمان Boot ماشین لینوکسی و Startup کانتینرها بهینه شده است.
این بهبودها بیشتر برای توسعهدهندگانی محسوس است که هر روز چندین بار Stack را بالا و پایین میکنند، Source Code را از Host داخل کانتینر Mount میکنند یا پروژههای چندسرویسی را در Docker Desktop اجرا میکنند.
Docker VMM چه تفاوتی با Docker Engine دارد؟
این دو را نباید با هم یکی دانست. Docker Engine همان Runtime و مجموعه سرویسهایی است که Imageها، Containerها، Networkها و Volumeها را مدیریت میکند. Docker VMM یک لایه پایینتر است که در Docker Desktop، VM لینوکسی موردنیاز برای اجرای Engine را مدیریت میکند.
به زبان ساده:
| جزء | وظیفه |
|---|---|
| Docker Engine | مدیریت Image، Container، Network و Volume |
| Docker Desktop | محیط دسکتاپ و ابزارهای یکپارچه برای Mac و Windows |
| Docker VMM | مدیریت لایه مجازیسازی و VM لینوکسی زیر Docker Desktop |
بنابراین تغییر VMM معمولاً Dockerfile یا فایل Compose شما را عوض نمیکند، اما میتواند روی سرعت فایلسیستم، مصرف حافظه و زمان راهاندازی محیط توسعه اثر بگذارد.
آیا Docker VMM جایگزین libkrun شده است؟
در مستندات فعلی Docker آمده است که از Docker Desktop 4.86، Docker VMM از Hypervisor اختصاصی Docker استفاده میکند و برای کاربران Mac جایگزین libkrun شده که در نسخههای 4.35 تا 4.85 استفاده میشد.
این تغییر به Docker اجازه میدهد رفتار VMM را دقیقتر برای Container Workloadها تنظیم کند، چون کنترل Stack مجازیسازی دیگر فقط به یک مؤلفه بیرونی وابسته نیست. از دید توسعهدهنده، ارزش این تصمیم زمانی مشخص میشود که بهبودهای Startup، حافظه و I/O در پروژه واقعی قابل اندازهگیری باشند.
محدودیتهای Public Beta را جدی بگیرید
Docker VMM هنوز Public Beta است؛ بنابراین بهتر است آن را یک گزینه نهایی و بدون ریسک برای هر Workflow فرض نکنید. مستندات Docker چند نکته مهم را مطرح میکنند، از جمله اینکه حداقل حافظه تخصیصیافته به Docker Desktop باید کافی باشد و برخی سناریوهای سازگاری در دوره Beta محدودیت دارند.
در Mac، مستندات فعلی به محدودیت Rosetta اشاره میکنند؛ بنابراین اگر Workflow شما به اجرای Imageهای amd64 روی Apple Silicon متکی است، عملکرد Emulation باید جداگانه بررسی شود. قبل از مهاجرت کامل، Buildها، Testها و ابزارهای توسعه اصلی خود را روی VMM جدید امتحان کنید.
چگونه Docker VMM را فعال کنیم؟
Docker VMM در Docker Desktop جدید از بخش تنظیمات قابل انتخاب است. مسیر دقیق گزینهها ممکن است با نسخه و سیستمعامل کمی تفاوت داشته باشد، اما در مستندات Docker این انتخاب در تنظیمات منابع و VMM قرار دارد.
قبل از سوییچ:
- Docker Desktop را به نسخه 4.86 یا جدیدتر ارتقا دهید.
- حداقل حافظه موردنیاز Docker Desktop را تأمین کنید؛ مستندات فعلی برای Docker VMM حداقل 4 GB تخصیص حافظه را ذکر میکنند.
- از پروژههای مهم و Volumeهای محلی خود Backup داشته باشید.
- پس از تغییر VMM، Build، Bind Mount، Networking و سرویسهای وابسته را دوباره تست کنید.
بهخصوص اگر چند پروژه توسعه فعال دارید، بهتر است تغییر را ابتدا روی یک پروژه واقعی اما کمریسک آزمایش کنید و سپس به Workflow روزمره منتقل شوید.
Docker VMM چه اثری روی Bind Mount و فایلسیستم دارد؟
یکی از مهمترین نقاط اصطکاک Docker Desktop همیشه تبادل فایل بین Host و VM لینوکسی بوده است. وقتی Source Code روی سیستم شماست اما Build یا تست داخل کانتینر اجرا میشود، فایلها باید از مرز Host/VM عبور کنند. Docker VMM با کنترل بیشتر روی این مسیر تلاش میکند Latency را کاهش دهد.
اگر روی پروژهای کار میکنید که هزاران فایل کوچک دارد، Hot Reload سنگین است یا ابزارهای Build مرتب فایلها را Scan میکنند، بهبود File I/O میتواند محسوستر باشد. البته نتیجه واقعی به سیستمعامل، سختافزار، نوع Mount و Workload بستگی دارد و باید Benchmark روی پروژه خودتان انجام شود.
برای مرور تفاوت روشهای ذخیرهسازی و Mount میتوانید مقاله Docker Volume و Bind Mount را هم ببینید.
برای پروژههای Docker Compose چه فایدهای دارد؟
در یک پروژه Compose، چند سرویس ممکن است همزمان Boot شوند: وبسرور، App، دیتابیس، Redis و ابزارهای جانبی. کاهش زمان Startup و بهبود I/O میتواند زمان بالا آمدن کل Stack را کمتر کند، بهخصوص اگر توسعهدهنده مرتب docker compose up و Build مجدد انجام دهد.
اگر با ساختار چندکانتینری آشنا نیستید، راهنمای Docker Compose و اجرای چند کانتینر نقطه شروع مناسبتری است. Docker VMM جای Compose را نمیگیرد؛ فقط محیط زیر آن را در Docker Desktop بهینه میکند.
آیا Docker VMM روی VPS یا سرور Production هم کاربرد دارد؟
اگر Docker Engine را مستقیم روی Linux VPS اجرا میکنید، معمولاً Docker Desktop و VMM آن در مسیر شما نیستند. در این سناریو Containerها مستقیماً روی Kernel لینوکس اجرا میشوند و مسئله اصلی شما منابع سرور، Storage، Network، Security و مدیریت Docker Engine است.
به همین دلیل Docker VMM بیشتر یک موضوع محیط توسعه روی دسکتاپ است. برای استقرار Production، انتخاب سرور مجازی با منابع قابل کنترل، تنظیم Docker Engine، محدودیت منابع، Backup و مانیتورینگ اهمیت بیشتری دارد. بهتر است Development و Production را از نظر معماری یکی فرض نکنید، حتی اگر هر دو از همان Imageها استفاده کنند.
قبل از مهاجرت به Docker VMM چه چیزهایی را تست کنیم؟
۱. زمان Startup را اندازه بگیرید
قبل و بعد از تغییر، زمان بالا آمدن Docker Desktop و Stack اصلی خود را مقایسه کنید. احساس سریعتر بودن کافی نیست؛ زمان واقعی را ثبت کنید.
۲. Build و Hot Reload را بررسی کنید
پروژههایی با Bind Mount و فایلهای زیاد را اجرا کنید و ببینید Build، Watcherها و Hot Reload رفتار پایداری دارند یا نه.
۳. مصرف RAM را در حالت Idle مقایسه کنید
چند دقیقه بعد از توقف Containerها، مصرف حافظه Docker Desktop و Host را بررسی کنید تا ببینید VMM جدید در Workload شما چه تفاوتی ایجاد کرده است.
۴. Imageهای چندمعماری را تست کنید
اگر روی Apple Silicon از Imageهای amd64 استفاده میکنید، حتماً سازگاری و سرعت Emulation را جداگانه بررسی کنید؛ Beta بودن VMM در این بخش اهمیت بیشتری دارد.
۵. Rollback ساده داشته باشید
اگر Build یا ابزار خاصی با VMM جدید ناسازگار بود، باید بتوانید بدون از دست دادن داده محلی به تنظیم قبلی برگردید. Backup Volumeهای مهم و ثبت تنظیمات قبل از تغییر، این کار را سادهتر میکند.
Docker VMM برای چه کسانی جذابتر است؟
بیشترین ارزش بالقوه برای توسعهدهندگانی است که:
- Docker Desktop را روزانه روی Mac یا Windows استفاده میکنند.
- پروژههای سنگین با Bind Mount و فایلهای زیاد دارند.
- مرتب Stackهای Compose را Start/Stop یا Rebuild میکنند.
- مصرف RAM Docker Desktop برایشان مهم است.
- میخواهند عملکرد محیط توسعه را بدون تغییر در Dockerfile و Compose بهبود دهند.
اگر Docker را فقط روی سرور لینوکس اجرا میکنید، Docker VMM احتمالاً موضوع عملی مستقیمی برای شما نیست و بهتر است تمرکز را روی تنظیم Docker Engine و زیرساخت Production بگذارید.
جمعبندی
Docker VMM تلاش Docker برای در اختیار گرفتن کاملتر لایه مجازیسازی زیر Docker Desktop است. نسخه Public Beta از Docker Desktop 4.86 روی Mac و Windows عرضه شده و هدفش بهبود Startup، File I/O و مدیریت حافظه برای Workloadهای کانتینری است. با این حال Beta بودن، محدودیتهای سازگاری و تفاوت Workflowها باعث میشود مهاجرت را با Benchmark و تست واقعی انجام دهید.
مهمترین نکته برای مدیران سرور این است که Docker VMM را با Docker Engine روی VPS اشتباه نگیرند: VMM بخشی از معماری Docker Desktop است، در حالی که روی سرور لینوکسی Production معمولاً Docker Engine مستقیماً روی سیستمعامل اجرا میشود.