بحث مجازی‌سازی و کانتینرها در بیشتر تیم‌های فنی به یک انتخاب دوتایی فروکاسته می‌شود: «ماشین مجازی یا Docker؟» و بعد جلسه به دو اردوگاه تقسیم می‌شود. اما این پرسش از پایه اشتباه است؛ ماشین مجازی و کانتینر دو پاسخ به یک پرسش واحد نیستند، دو پاسخ به دو پرسش متفاوت‌اند: یکی می‌پرسد «چطور یک سیستم‌عامل کامل را چند بار و به‌صورت مستقل اجرا کنم؟» و دیگری می‌پرسد «چطور چند برنامه را با کمترین هزینهٔ اضافه از هم جدا کنم؟» در این مقاله به‌جای طرفداری از یکی، نشان می‌دهیم هر کدام چه چیزی را حل می‌کنند و معیارهای واقعی تصمیم کدام‌اند.
ماشین مجازی: یک کامپیوتر کامل، از نو
ماشین مجازی (Virtual Machine) یک سیستم‌عامل مهمان کامل را روی سخت‌افزار شبیه‌سازی‌شده اجرا می‌کند. لایهٔ میانی، ناظر مجازی‌سازی (Hypervisor) است که منابع فیزیکی را بین ماشین‌ها تقسیم می‌کند. مهم‌ترین ویژگی این مدل، استقلال کامل هر ماشین است:
- هر ماشین، هسته (Kernel) و سیستم‌عامل مستقل خودش را دارد؛ از دید برنامه، یک کامپیوتر واقعی است.
- مرز امنیتی روشن و آشناست: عبور از یک ماشین به ماشین دیگر باید از مسیر ناظر مجازی‌سازی بگذرد، نه از مسیر یک فرایند عادی.
- می‌توان وضعیت کامل ماشین را به‌عنوان الگو نگه داشت، کلون کرد یا به سرور دیگری منتقل کرد؛ گزینه‌ای بی‌رقیب برای برنامه‌های قدیمی که به نسخهٔ خاصی از سیستم‌عامل گره خورده‌اند.
- هزینه‌اش روشن است: هر ماشین حافظه و منابع خودش را می‌خواهد و چند ماشین کنار هم یعنی چند سیستم‌عامل که باید وصله و به‌روزرسانی شوند.
کانتینر: یک فرایند، با مرزهای مشخص
کانتینر (Container) به‌جای شبیه‌سازی سخت‌افزار، از سازوکارهای خود سیستم‌عامل استفاده می‌کند: فضای نام‌ها (Namespaces) برای جداسازی دید فرایند نسبت به فایل‌سیستم، شبکه و سایر پردازه‌ها، و گروه‌های کنترل (Control Groups) برای سهم‌بندی پردازنده و حافظه. نتیجه اینکه همهٔ کانتینرها یک هستهٔ مشترک دارند و همین، هم مزیت است و هم محدودیت.
- راه‌اندازی در حد ثانیه؛ مناسب برای مقیاس‌پذیری سریع و استقرار مکرر.
- تصویر (Image) لایه‌ای و قابل انتشار؛ همان تصویری که در محیط توسعه ساخته شده، روی سرور هم اجرا می‌شود و بخش زیادی از تفاوت‌های محیطی حذف می‌شود.
- چگالی بالا: ده‌ها سرویس روی یک ماشین، بدون ده‌ها سیستم‌عامل.
- محدودیت کلیدی: مرز امنیتی کانتینر در نهایت خود هسته است؛ اگر هسته آسیب‌پذیر باشد، همهٔ کانتینرهای روی آن در معرض‌اند.
مقایسه بر اساس معیارهایی که واقعاً در تصمیم اثر دارند
- سطح جداسازی: ماشین مجازی مرز سخت دارد، کانتینر مرز نرم. اگر چند مشتری با سطح اعتماد متفاوت را روی یک میزبان میزبانی می‌کنید، این تفاوت جدی است.
- سرعت و چگالی: کانتینر برنده است؛ برای بارهای کاری متغیر و استقرار چندبار در روز انتخاب طبیعی است.
- وضعیت (State): کانتینر برای فرایندهای بی‌وضعیت (Stateless) طراحی شده است. اجرای پایگاه‌داده در کانتینر ممکن است، اما به دیسک ماندگار، نسخه‌پشتیبان و انضباط عملیاتی نیاز دارد؛ در ماشین مجازی این کار ساده‌تر و کم‌ریسک‌تر است.
- سازگاری با سامانه‌های موجود: برنامه‌ای که به نسخهٔ مشخصی از سیستم‌عامل یا درایور وابسته است، در ماشین مجازی راحت‌تر زنده می‌ماند.
- هزینهٔ عملیاتی: کانتینر ابزار بیشتر و نظم بیشتری می‌خواهد: نسخه‌بندی تصویر، ثبت وقایع متمرکز، پایش و مدیریت رازها. بدون این‌ها، سادگی اولیه‌اش به سرعت تبدیل به آشفتگی می‌شود.
یک مثال عملی: فروشگاه اینترنتی با چهار جزء
فرض کنید یک فروشگاه اینترنتی داریم با چهار جزء: اپلیکیشن وب، کارگر پردازش صف (Queue Worker)، پایگاه‌داده و یک ماژول حسابداری قدیمی که فقط روی نسخهٔ قدیمی یک سیستم‌عامل اجرا می‌شود. تصمیم معقول چنین است:
- اپلیکیشن وب و کارگر صف: کانتینر. بی‌وضعیت‌اند، باید با هر تغییر کد سریع مستقر شوند و در ساعات پرترافیک چند نسخه از آن‌ها اجرا شود.
- پایگاه‌داده: ماشین مجازی یا سرویس مدیریت‌شده. داده، وضعیت است و وضعیت را داخل چیزی که هر لحظه ممکن است دور انداخته و از نو ساخته شود، نگه نمی‌داریم.
- ماژول قدیمی: ماشین مجازی. تلاش برای کانتینری کردن آن، صرفه‌جویی کوچکی را به بدهی فنی بزرگ تبدیل می‌کند.
در سامانه‌هایی که هر مشتری نمونهٔ جداگانه‌ای از سرویس را می‌خواهد — مثل سامانهٔ CRM یکپارچه با مرکز تماس و قابلیت چندمستأجری — همین منطق کمک می‌کند: سرویس‌های بی‌وضعیت هر مستأجر در کانتینر، و داده و تنظیمات در لایه‌ای پایدار و جدا.
راهنمای تصمیم‌گیری: پنج پرسش پیش از انتخاب
- این جزء وضعیت دارد یا نه؟ اگر دارد، اول به فکر ماشین مجازی یا سرویس مدیریت‌شده باشید.
- مرز اعتماد کجاست؟ اگر کد غیرقابل اعتماد یا چند مشتری با سطح دسترسی متفاوت دارید، جداسازی سخت‌تر را جدی بگیرید.
- چند بار در روز مستقر می‌کنید؟ استقرار مکرر، هزینهٔ کانتینر را توجیه می‌کند.
- وابستگی به سیستم‌عامل چقدر است؟ وابستگی سخت، به سمت ماشین مجازی می‌برد.
- تیم چه چیزی را می‌تواند نگهداری کند؟ ابزاری که تیم بلد نیست، در روز حادثه وجود ندارد.
دام‌های رایج
- نگه‌داشتن داده داخل کانتینر: با حذف و ساخت مجدد کانتینر، داده هم می‌رود. داده باید بیرون از چرخهٔ عمر کانتینر باشد.
- تصویرهای چاق: تصویری که ابزارهای ساخت و کتابخانه‌های بی‌مصرف را با خود می‌برد، سطح حمله و زمان استقرار را بالا می‌برد.
- برچسب‌های مبهم: استفاده از برچسب‌های شناور به‌جای نسخهٔ مشخص، یعنی هر استقرار ممکن است چیز دیگری اجرا کند.
- نداشتن سهمیهٔ منابع: کانتینری که بی‌حد حافظه می‌خورد، همسایه‌هایش را زمین می‌زند.
- پرش زودهنگام به هماهنگ‌سازی: وقتی چند سرویس دارید، ابزاری مثل کوبرنتیز برای هماهنگ‌سازی وسوسه‌کننده است؛ اما پیش از رسیدن به چند ده سرویس و نیاز واقعی به مقیاس‌پذیری خودکار، بیشتر بدهی عملیاتی می‌سازد تا ارزش.
جمع‌بندی
ماشین مجازی و کانتینر رقیب هم نیستند؛ دو ابزار با دو مرز متفاوت‌اند. قاعدهٔ سادهٔ کار: چیزهای بی‌وضعیت، مکرر و سریع‌التغییر را کانتینری کنید، و چیزهای دارای وضعیت، وابسته به سیستم‌عامل یا نیازمند جداسازی سخت را در ماشین مجازی نگه دارید. در بیشتر معماری‌های واقعی، پاسخ درست «هر دو» است — به شرطی که بدانید هر کدام کدام مرز را برایتان می‌کشد.
