مقایسه داکر (Docker) با VServer و OpenVZ و LXC

این روزها، توسعه­ دهندگان نرم ­افزار، شاهد ارز اندام مقتدرانه تکنولوژی کانتینرها هستند. در این بخش، ابتدا مجازی سازی مبتنی بر کانتینر و پیاده ­سازی های آن شرح داده می­شود و سپس، سکوی محبوب داکر (Docker) بصورت ویژه مورد توجه قرار می­گیرد تا بتوانیم با مفاهیم مجازی سازی با کانتینر داکر بیشتر آشنا شویم. در بخش های بعد نیز به جزئیات داکر خواهیم پرداخت.

مجازی سازی در بستر سیستم عامل مبتنی بر کانتینرها (Container-based):

 تاریخچه کانتینر ها

ابرناظرها که توسط Xen و VMware معروف شده­ اند، برای بسیاری از سناریوها مناسب هستند اما برای سناریوهایی که نیاز به مجازی­ سازی سیستمی با کارایی بالا دارند، مناسب نیستند برای نمونه، خوشه های رایانش با کارایی بالا(high performance computing).

مجازی­سازی مبتنی بر کانتینر ، جایگزینی سبک وزن برای ابرناظرها است و به عنوان مجازی­سازی سطح سیستم عامل نیز شناخته می­شود. این نوع از مجازی­سازی، با ایجاد چند نمونه فضای مجزای کاربر، منابع ماشین فیزیکی را تقسیم می­کند. مجازی­ سازی مبتنی بر ابرناظر، در سطح انتزاع سخت افزار کار انجام می­شود، در حالیکه کانتینر ها در سطح فراخوان یا ABI سیستم کار می­کنند. ABIرابط هایی را بین اجزاء برنامه در سطح کد ماشین تعریف می کند(برخلاف API که در سطح کد منبع، رابط هایی را تعریف می کند).

تمام نمونه­ های مجازی تحت مجازی­سازی مبتنی بر کانتینر ، یک هسته واحد سیستم عامل میزبان را به اشتراک می­گذارند(کل کانتینرها در یک میزبان، فقط نیاز به یک هسته سیستم عامل دارند) زیرا این نوع مجازی­ سازی در سطح سیستم عامل کار می­کند و به این دلیل دارای انزوای ضعیف­تری نسبت به مجازی­سازی سطح ابرناظر است (ضعف مجازی ­سازی مبتنی بر کانتینر ). با اینحال، از دید کاربران، هر کانتینر دقیقا همانند یک سیستم عامل مستقل کار می­کند. انزوا در این نوع مجازی سازی از طریق فضاهای نام ^(namespace) هسته ارایه می­شود. در واقع، کانتینر ها لینوکس مفهومی هستند که بر پایه­ی ویژگی فضاهای نام هسته ساخته شده­اند. این ویژگی با فراخوانی سیستمی  قابل دسترسی است و قابلیت ایجاد نمونه­ های مجزا از فضاهای نامی که قبلا عمومی بوده ­اند (فضای نام میزبان) را ممکن می­سازد.

لینیکس، فضاهای نام سیستم فایل، شناسه فرآیند، شبکه، کاربر IPC، نام میزبان و شبکه را پیاده­سازی می­کند. رایج­ترین رویکرد در استفاده از فضاهای نام، ساختن حامل مجزایی است که دید یا دسترسی به اشیاء خارج از کانتینر ندارند. مدیریت منابع توسط گروه­های کنترل یا cgroup انجام می­شود. توسط cgroup می توانیم منابعی مانند زمان پردازنده، حافظه سیستم، پهنای باند یا ترکیبی از این منابع را در میان گروه هایی از فرآیندهایی(تعریف شده توسط کاربر) که در سیستم اجرا می شوند، تخصیص دهیم. که مصرف منابع را برای هر گروهی از فرآیندها مدیریت می­کند. در نتیجه اولویت­بندی استفاده  پردازنده، حافظه و ورودی/خروجی برای حامل های مختلف ممکن می باشد. با cgroup می­توان به سادگی مقیاس یک کانتینر را تغییر (با تغییر حدود cgroup آن کانتینر) یا تمام فرآیندهای داخل یک کانتینر را خاتمه داد.

ویژگی اصلی مجازی سازی مبتنی بر کانتینر این است که بر خلاف VM که سیستم­عامل کاملی را اجرا می­کند، حامل می­تواند شامل تنها یک فرآیند باشد. ارتباط بین کانتینرها یا بین یک حامل و میزبان(فضای نام والد)، بصورت کارامد مانند یک IPC لینیکس معمولی انجام می­شود. در یک سیستم لینیکس که در آن از مجازی­سازی مبتنی بر کانتینر استفاده شده است، تنها یک سطح از تخصیص و زمانبندی منابع وجود دارد زیرا این سیستم تنها یک هسته دارد و این هسته نیز دارای دید یا دسترسی کاملی به کانتینرها است.

متاسفانه فرآیندهایی که در کانتینر اجرا می­شوند از محدودیت­های منابع­شان آگاه نیستند و با وجود اینکه تنها مجاز به اجرای زیرمجموعه­ای از منابع هستند، می توانند تمام هسته­های پردازشی و کل حافظه را ببینند. برقراری امنیت در کانتینرها ساده است؛ یک حامل نمی­تواند به چیزی که نمی­بیند دسترسی داشته باشد. اولین نوع از آسیب­پذیری امنیتی در کانتینرها، در فراخوان­های سیستمی است زیرا فراخوان­های سیستمی، آگاه از فضای نام(آگاه از زمینه) نیستند و بنابراین ممکن است موجب نشت تصادفی بین کانتینرها شوند.

VServer-از قدیمی­ترین پیاده­ سازی سیستم مبتنی بر کانتینرها لینیکس است. در این پیاده­سازی بجای استفاده از فضا­ های نام برای تضمین انزوا، ازفراخوان سیستمی سنتی chroot برای انزوای سیستم فایل در کانتینرها استفاده می­شود. بنابراین حوزه سیستم فایل برای فرآیندها، محدود می­شود. انزوای فرآیندها از طریق فضای PID عمومی انجام می­شود که تمام فرآیندهای خارج از حوزه یک کانتینر را مخفی می­کند و از ارتباطات ناخواسته بین فرآیندهای حامل­های مختلف جلوگیری می­کند. مزیت این رویکرد در مقیاس­پذیری تعداد کانتینرها است اما مشکل آن در عدم قابلیت پیاده­سازی نیازمندی­هایی همچون مهاجرت زنده، نقطه بازرسی (checkpoint) و از سرگیری ^(resume) است زیرا نمونه­ سازی مجدد فرآیندها با PID یکسان ممکن نیست.

OpenVZ-این پیاده ­سازی نیز کارکرد مشابهی با VServer ارایه می­کند، اما بر اساس فضاهای نام هسته ساخته شده است و توسط فضای نام PID انزوای میان کانتینرها مختلف را تضمین می­کند. بخاطر استفاده از PID، برخلاف سیستم قبلی(VServer) استفاده از تکنیک­های مجازی­ سازی معمول مانند مهاجرت زنده، نقطه بازرسی و ازسرگیری ممکن می­باشد. در این سیستم، هر حامل از طریق قابلیت فضای نام هسته IPC، حافظه اشتراکی، قطعات، سمافورها و پیام­ها و همچنین بدلیل استفاده از فضای نام شبکه، پشته شبکه خودش را دارد که شامل دستگاه­های شبکه، جداول مسیریابی، قوانین دیواره آتش و غیره خودش را دارد. OpenVZ دارای ۴ جزء مدیریت منابع برای زمانبندی پردازنده(زمانبندی CPU بصورت منصفانه)، حافظه(User Beancounters)، دیسک(^{Disk Quotas]}) و ورودی/خروجی(صف بندی منصفانه) است.

LXC-این پیاده­ سازی نیز همانند OpenVZ از فضاهای نام برای ارائه انزوا در میان تمام کانتینرها و میزبان استفاده می­کند. برای مثال از فضای نام کاربر برای انزوای پایگاه داده کاربر کانتینر و پایگاه داده کاربر میزبان، از فضای نام فرآیند برای تضمین دسترسی و مدیریت کانتینر به تنها فرآیندهای در حال اجرا در آن حامل و از فضای نام شبکه نیز جهت ارایه دستگاه­ های شبکه و آدرس IP مجازی یک حامل را استفاده می­شود. برخلاف دو پیاده­سازی قبل، مدیریت منابع در این سیستم تنها از طریق cgroups ممکن است. همچنین کنترل فرآیند نیز توسط cgroups انجام می­شود که دارای قابلیت محدودکردن استفاده از پردازنده و انزوای کانتینرها و فرآیندها است. عملیات ورودی/خروجی مانند OpenVZ با زمانبند CFQ کنترل می­شود.

در  مطالعات نمونه ­ای از پیاده­ سازی این رویکرد با نام VServer با Xen(به عنوان نماینده­ای از ابرناظرها)، از نظر انزوا و بهره­ وری مقایسه می­شوند و در پایان نتیجه می­گیرد که کارایی رویکرد مبتنی بر حامل، تقریبا در بسیاری از شرایط، برابر است با هسته لینوکس بومی(لینوکس در حالت عادی یا ماشین مجازی­سازی نشده) و همچنین نسبت به Xen دارای ردپای کمتری(سربار کمتری) در هسته لینوکس است.

در ارزیابی­های به روزی بین پیاده­ سازی­های مبتنی بر حامل و Xen از نظر کارایی محاسباتی، توان عملیاتی حافظه و دیسک، تاخیر شبکه و سربار کارایی در سیستم­های مبتنی بر حامل برای اجرای برنامه­های HPC انجام شده است. در قسمت کارایی محاسباتی، نتایج LXC از دیگر سیستم ها بهتر و تقریبا برابر با سیستم بومی(bare-metal) می­باشد. در بخش­های توان عملیاتی حافظه، OpenVZ موفق به دست­یابی نتیجه بهتری از دیگر سیستم­ها شد. در بخش توان عملیاتی دیسک و تاخیر شبکه، VServer از بقیه بهتر عمل کرده است. در بخش سربار کارایی در اجری برنامه HPC در محیط توزیع شده نیز LXC و VServer نتایج بهتری نسبت به بقیه کسب کرده­اند. در پایان در بخش بررسی­های مربوط به ارزیابی انزوا، مشاهده می­شود که Xen بخاطر عدم اشتراک­گذاری سیستم عامل، قادر به تضمین انزوای بهتری نسبت به سیستم­های مبتنی بر کانتینر است که نشان از ضعف سیستم­های مبتنی بر حامل در تضمین انزوای بین کانتینرها می­دهد، بخصوص در انزوای حافظه، دیسک و شبکه به بلوغ قابل قبول نرسیده ­اند.

مجازی سازی با کانتینر داکر (Docker)

داکر (Docker) یک پروژه متن‌باز است که فرایند استقرار نرم‌افزارها و سرویس‌ها رو با معرفی مفهوم “Container”ها سرعت می‌بخشد. داکر  پروژهٔ متن‌بازی است که توسعه های نرم‌افزارهای کاربردی را درون کانتینر نرم‌افزاری به وسیلهٔ فراهم کردن لایهٔ انتزاعی اضافه‌ای فراهم می‌کند.بعضی از افراد فکر می کنند داکر، ابزار مجازی سازی مانند وی‌ام‌ویر یا ویرچوال باکس است. عده ای نیز فکر می کنند داکر ابزار مدیریت ماشین مجازی مانند وگرنت (Vagrant) است؛ ولی در واقع این‌گونه نیست. به عبارت ساده، داکر یک پلت فرم جدید و متفاوت برای توسعه دهندگان و مدیران سیستم‌هاست که به آنها در ساخت، عرضه و اجرای  نرم افزارهای های توزیع شده با استفاده از کانتینرها کمک می کند. کانتینر یا محفظه، به توسعه دهنده اجازه می دهد تا یک  نرم افزارهای را با تمام بخش های مورد نیاز مانند کتابخانه ها و دیگر وابستگی ها، بسته بندی کند و به عنوان یک پکیج مجزا بر روی سیستم های دیگر استفاده کند.

مولفه های تشکیل دهنده مجازی سازی با کانتینر داکر

Docker daemon: سرویس اصلی داکر که وظیفه مدیریت و اجرا کردن کانتینر ها را به عهده داره.
Docker CLI: اینترفیس کامند لاینی هست که باهاش به Docker Daemon دستور میدیم

Container و Docker image: کانتینر، سیستم‌ در حال اجرایی است که توسط یک تصویر مشخص، تعریف می‌شود. تصاویر و کانتینرها را می‌توان به عنوان برنامه‌ها و فرآیندها در نظر گرفت. در‌واقع، حامل داکر می‌تواند به عنوان تصویر داکری درنظر گرفته شود که در حال اجرا است. از منظر شیء گرایی، تصاویر را می‌توان به عنوان کلاس‌ها و حامل ها را به عنوان اشیاء درنظر گرفت. در‌واقع حامل ها نمونه‌ هایی از تصاویر هستند. می‌توان چند کانتینر را از یک تصویر واحد ساخت، بطوری که انزوا بین کانتینرها برقرار است.

Resource Managment: داکر ابزارهایی را به منظور سهولت ایجاد و کارکردن با کانتینرها فراهم می­کند. LXC هسته داکر را تشکیل می­دهد. همان­طور که در بخش قبلی بیان شد، LXC برای انزوای حامل­ها از میزبان، از فضاهای نام سطح هسته استفاده می­کند. فضای نام کاربر، پایگاه داده کاربر کانتینرها و میزبان را جدا و تضمین می­کند که کاربر ریشه کانتینر، مجوز ریشه در میزبان را نداشته باشد. جزء دیگر داکر که توسط LXC ارایه می­شود، cgroups است که مسئول مدیریت و محدودسازی استفاده منابع در حامل­ها است. همچنین cgroups معیارهای گوناگونی را از منابعی که مدیریت می­کند، به خارج عرضه می­کند(چاپ می­کند) و داکر نیز از این معیارها برای نظارت بر مصرف منابع فرآیندهای مختلف کانتینرها استفاده می­کند.

File System: آخرین جزء کلیدی داکر AuFS  یا Advanced Multi-Layered Unification Filesystem است که از آن به عنوان سیستم فایلی برای کانتینرها استفاده می­کند و این جزء وجه تمایز داکر با دیگر ابزارهای مبتنی بر کانتینر است. AuFS سیستم فایلی لایه ­ای است که می­تواند بطور شفاف یک یا چند سیستم فایل موجود را پوشش  دهد یا روی هم قرار دهد. AuFS قادر است چندین لایه را به نمایش واحدی از یک سیستم فایل ادغام کند. اگر نیاز باشد تا چند نسخه حامل از یک تصویر ساخته شود، برخلاف تصور، چندین نسخه از تصویر اصلی ساخته نمی‌شود، بلکه توسط مکانیزم copy_on_write، فقط تغییراتی که هر حامل ایجاد می‌کنند، در قسمت مجزایی ثبت می‌شود. در نتیجه، در مصرف حافظه و دیسک صرفه جویی و همچنین سرعت راه­اندازی داکر نیز افزایش می‌یابد. در بسیاری از حالات، تصاویر حامل داکر، نیازمند فضای دیسک و ورودی/خروجی کمتری نسبت به تصاویر دیسک VM معادل است .

Docker Repository: یک مزیت بزرگی که مجازی سازی با کانتینر داکر ارائه میدهد، Registry آن هست. Registry را به چشم Repository ای از Image های مختلف ببینید. بزرگترین Registry مربوط میشود به Docker Hub که انواع و اقسام Image ها رو میشه داخلش پیدا کرد. یکی از ویژگی­های مهم داکر قابلیت جستجو، بارگیری و راه­اندازی image های کانتینرها است که توسط دیگر توسعه دهندگان ایجاد شده­ ند. مکانی که تصاویر ذخیره می­شوند، رجیستری نام دارد، و داکر نیز یک رجیستری عمومی به نام Docker Hub ارایه می­کند. مفهوم رجیستری در داکر معادل NPM در Node و RubyGems در Ruby است. در واقع رجیستری داکر سرویس یا برنامه­ی سمت سرویس­دهنده است که توسعه­دهندگان می­توانند توسط آن تصاویر خود را در مخزن عمومی ذخیره(یا push) یا به اشتراک گذارند و دیگر توسعه دهندگان آن را بارگیری(یا pull) کنند(مانند GitHub). می­توان تصاویر مورد نظر را در سایت https://hub.docker.com نیز جستجو و مستندات آن را مشاهده کرد. رجیستری عمومی داکر شامل تصاویری از نرم افزارهای آماده اجرا از قبیل پایگاه­های داده، سیستم­های مدیریت محتوا، محیط­های توسعه، سرویس­دهنده های وب و غیره هستند. بارگذاری یا بارگیری تصاویر تنها نیازمند ایجاد حساب کاربری(مجانی) در داکر است. در لینک زیر بین Docker و KVM از نظر کارایی منابع محاسباتی، حافظه، دیسک و شبکه تحت اجرای مجموعه ای از بارهای کاری، ارزیابی بسیار خوبی صورت گرفته است.

Swarm : از ویژگی‌هایی که مربوط به مجازی سازی با کانتینر داکر میشود ،میتوان به Swarm اشاره کرد که قابلیت مدیریت چند سیستم دارای Docker رو ارایه میدهد و میتوان از یک نقطه به صورت توزیع شده Application خود را پیاده‌سازی کینم و دیگر به این فکر نکنیم که الان باید روی کدوم سیستم Container را بالا بیارم.

به عنوان مزیت دیگر میتوان به HealthCheck اشاره کرد که با وجود Swarm دیگر نگرانی این را نداریم که اگر Application از دسترس خارج شد. با وجود این ویژگی در اسرع زمان، در یکی از نقاط در دسترس Application به صورت اتوماتیک اجرا خواهد شد.

 

 

آدرس کانال تلگرام سایت بیگ دیتا:

t.me/bigdata_channel

آدرس کانال سروش ما:
https://sapp.ir/bigdata_channel

جهت دیدن سرفصل های دوره های آموزشی بر روی اینجا کلیک کنید.

 

بازدیدها: 3155