داکر ( Docker ) چیست ؟ کانتینر ( Container ) چیست؟ تفاوت VM و Container در چیست؟ از سرور فیزیکی استفاده کنیم یا مجازی ؟ مزایا و معایب استفاده از داکر چیست؟ سناریوهای مختلف کار با داکر چیست؟ و ...
Docker یکی از موفق ترین پروژه های متن باز در تاریخ فناوری اطلاعات است. سازمان ها همواره در تلاش برای افزودن قابلیت حمل به برنامه های کاربردی خود از طریق Container ها هستند ، اما اولین قدم برای رسیدن به این هدف ، درک container ها و مزایای کلیدی آنهاست.اغلب افرادی که برای اولین بار با Docker Container کار می کنند به آن "ماشین مجازی سبک وزن" می گویند! پس به آسانی قابل فهم است که این دو تکنولوژی مشخصات مشابهی دارند. اما مشخصات مشابه چه مواردی هستند؟!! هر دو طراحی شده اند تا بتوانند:
در واقع معماری ماشین مجازی و Container از پایه با هم متفاوت است! جهت درک بهتر موضوع میشه این مثال و مقایسه رو ارائه داد:
خانه ها [VMs] کاملا مستقل هستند و قابلیت جلوگیری از ورود مهمان های ناخواسته را برای محافظت از خود ارائه می کنند.آنها همچنین زیرساخت های خود را دارند - لوله کشی، گرمایش، برق، و غیره ، علاوه بر این، در بیشتر موارد، خانه ها دارای حداقل یک اتاق خواب،هال و پذیرایی، حمام و آشپزخانه هستند.بسیار دشوار است که یک "خانه استودیویی" پیدا کنید
حتی اگر شخصی یکی از کوچکترین خانه هایی که می تواند پیدا کند را بخرد ، ممکن است بیشتر از آنچه نیاز دارد خرید کند و به بعضی از قسمت های خانه اصلا نیازی نداشته باشد. زیرا خانه ها فقط ساخته می شوند.(همه ی آن ها سفارشی ساخته نمی شوند - مثل سخت افزار سرور های مختلف که شرکت های سخت افزاری آن هارا برای استفاده عمومی (general-purpose) می سازندو ممکن است از همه ی منابع استفاده نکنید.)
آپارتمان ها (Docker Containers) نیز در برابر مهمانان های ناخواسته از خود محافظت می کنند، اما آنها بر روی زیرساخت مشترک ساخته شده اند.ساختمان آپارتمان یا Docker Host نیز همانند ماشین مجازی زیرساخت خود را دارد لوله کشی، گرمایش، برق، و غیره به هر آپارتمان.(سروری که سرویس شبه داکر(Docker-Daemon) در آن در حال اجراست به عنوان Docker Host یا میزبان داکر شناخته می شود.)
علاوه بر این، آپارتمان ها در اندازه های مختلف ارائه می شوند - از استودیو تا پنت هاوس چند خوابه و شما تنها دقیقا همان چیزی را که نیاز دارید اجاره می کنید.Docker Container ها از منابع سخت افزاری به اشتراک گذاشته شده Docker Host استفاده می کنند. به علاوه، توسعه دهندگان Docker Image می سازند و Docker Image دقیقا همان چیزی است که آنها برای اجرای برنامه خود نیاز دارند:
توسعه دهندگان قادرند تا به سرعت به برنامه اولیه ویژگی های جدید را اضافه کنند.)ماشین های مجازی در جهت مخالف ساخته شده اند. آنها با یک سیستم عامل شروع به کار می کنند و بسته به برنامه کاربردی، توسعه دهندگان ممکن است قادر نباشند اجزای ناخواسته را از بین ببرند یا با کندی میتوانند ویژگی جدید را اضافه کنند.برای بسیاری از افراد این مفاهیم به راحتی قابل درک هستند. با این حال، حتی زمانی که با تفاوت معماری Docker containers و ماشین های مجازی آشنا می شوند اغلب در تلاش هستند تا هرآنچه درباره ی VM می دانند با Container انطباق دهند مثلا:
البته در پایان متوجه خواهند شد که Docker تکنولوژی مجازی سازی نیست، بلکه یک تکنولوژی تحویل برنامه است (Application Delivery Technology) اگر VM را به صورت واحدی انتزاعی و یکپارچه (Monolithic) در نظر بگیریم در دنیای ماشین های مجازی نه تنها کد برنامه ذخیره می شود، بلکه داده ها (stateful data) نیز ممکن است به همراه آن در VM ذخیره شوند.
ماشین مجازی منابع دریافتی از سرور فیزیکی را گرفته و به صورت Binary بسته بندی می کند ، بنابریان می تواند آن را براحتی انتقال دهد.(انتقال OS+APP :معمولا حجم انتقال بالا و بسیار زمان بر خواهد بود)در Container ها واحد انتزاعی برنامه کاربردی است، در بیان دقیق تر سرویسی است که کمک می کند تا برنامه کاربردی ساخته شود. در معماری Micro-service ، بسیاری از سرویس های کوچک (که هرکدام به عنوان یک Docker Container نمایان می شوند) یک برنامه را می سازند.اکنون برنامه ها می توانند به اجزای بسیار کوچکتر شکسته شوند، این امر توسعه و مدیریت محصول را از پایه و اساس تغییر می دهد.
بنابراین، در پاسخ به این سوال که "یک sysadmin چگونه از Docker Container پشتیبان می گیرد؟" می توان گفت که او نیازی به انجام این کار ندارد. داده تولید شده توسط برنامه کاربردی در Container وجود ندارد بلکه داده ها در Volume ای وجود دارند که بین Container ها از طریق معماری نرم افزار تعیین شده توسعه دهندگان به اشتراک گذاشته می شود و Sysadmin ها تنها از Volume ها پشتیبان می گیرند و Container هارا فراموش می کنند زیرا Container ها Stateless و غیر قابل تغییر (Immutable) بوده و داده ای را درخود ذخیره نمی کنند.
مطمئنا اعمال patch هنوز هم بخشی از دنیای مدیران سیستم است، اما این امر روی Container های در حال اجرا انجام نمی گردد.در حقیقت اگر کسی یک Container در حال اجرا را پتچ کند و سپس Container جدیدی را بر اساس یک Docker Image پتچ نشده اجرا کند، همه چیز به هم خواهد ریخت.به جای اینکار مدیران سیستم Docker Image موجود خود را به روز کرده سپس Container های در حال اجرا خود را متوقف کرده و Container های جدید را اجرا می کنند.
از آنجا که یک Container می تواند در کسری از یک ثانیه متوقف و اجرا شود،بنابریان این به روز رسانی ها بسیار سریع تر از ماشین های مجازی انجام می شوند.در پاسخ به سوال سوم می توان گفت که Application Server نیز به سرویسی درون Container تبدیل خواهد شد.مطمئنا ممکن است مواردی وجود داشته باشد که برنامه های مبتنی بر معماری Micro-service نیاز به اتصال به سرویس غیر کانتینری داشته باشند، اما عمدتا برای اغلب سرورهای مستقل که کد برنامه در آن اجرا می شود، می توان از یک یا چند کانتینر برای آن عملکرد مشابه استفاده کرد که این رویکرد دو مزیت برایمان خواهد داشت:
در مقاله اول درباره موضوع Container ها ماشین های مجازی نیستند صحبت کردم ، اما اگر Container ها ماشین مجازی نباشند، یک پرسش منطقی به وجود میاد: آیا می توان از تکنولوژی های ماشین مجازی و Docker Container با هم استفاده نمود؟ در پاسخ به این سوال می توان گفت "بله" ماشین های مجازی در هر نوعی بهترین مکان برای میزبان های داکر هستند تا Container ها در آن اجرا شوند. مهم نیست که ماشین مجازی شما از چه نوعی است(vSphere VM ، Hyper-V VM ، AWS EC2 و ...)، هرکدام از این موارد نقش یکسان میزبان داکر (Docker Host) را دارند.بسته به نیاز شما ، ماشین مجازی ممکن است بهترین مکان برای کانتینر ها باشد اما مزیتی عالی برای کانتینر ها وجود دارد ، مهم نیست شما کانتینر ها را در کدام میزبان اجرا می کنید، آن ها می توانند در هر محیطی اجرا شوند و وابسته به محیط نیستند - البته اجرای کانتینر در میزبانی خاص به تصمیم شما بستگی دارد.
سؤال دیگری که اغلب مطرح می شود این است که آیا سرویس های مبتنی بر Docker Container می توانند با سرویس های مبتنی بر VM ارتباط برقرار کنند یا خیر؟ "بله کاملا".
اجرای برنامه شما دوستان در مجموعه ای از کانتینر ها ، از ارتباط با سرویس های در حال اجرای ماشین مجازی جلوگیری نمی کند. به عنوان مثال ، برنامه شما ممکن است نیاز به ارتباط با پایگاه داده موجود در ماشین مجازی داشته باشد ، بسته به شبکه تعریف شده ، برنامه شما براحتی به صورت یکپارچه می تواند با پایگاه داده ارتباط برقرار کند.
حوزه ی دیگری که ماشین های مجازی و کانتینر ها در آن می توانند با هم ارتباط برقرار کنند، حوزه استفاده بهینه از ظرفیت(منابع) موجود است. ماشین های مجازی محبوبیت زیادی با افزایش سطح بهره وری سرور ها به دست آوردند.جهت درک بهتر موضوع یک میزبان مجازی سازی(virtualization host)، می تواند شامل ماشین های مجازی یکپارچه (Monolithic) سنتی و ترکیب ماشین مجازی با داکر باشد. پس مدیران سیستم می توانند از حداکثر بهره وری سخت افزار موجود اطمینان حاصل کنند.
بنابراین داکر را می توان در انواع مجازی سازی و سکو های ابری (Cloud Platforms) استفاده نمود. دوستان از طریق Docker Cloud ، Docker Datacenter و محصولات مشابه به راحتی می توانند میزبان های Docker را بدون در نظر گرفتن مکان اجرا ، مدیریت کنند و با استفاده از Docker Machine نیز می توانند میزبان های جدید Docker را بر روی انواع Platform ها شامل VMware vSphere، Hyper-V، Microsoft Azure و AWS و .. ایجاد کنند.
یکی از مهم ترین نکات در موردDocker انعطاف پذیری است که برای سازمان های فناوری اطلاعات فراهم می کند.تصمیم مکان اجرای برنامه ها کاملا به این عامل بستگی دارد :"چه چیزی برای سودمندی کسب و کار شما مناسب است" شما مجبور به استفاده از زیرساخت خاصی نیستید، این شما هستید که انتخاب می کنید "که استفاده و یا ترکیب کدام تکنولوژی ها ، سودمندی کسب و کارتان را افزایش خواهد داد!" میزبانی داکر "روی vSphere ؟ عالیه" ، "روی Azure؟ مطمئنا"، "روی سرور فیزیکی؟فوق العادست"
با استفاده از کانتینر ها به تمامی اهداف خود خواهید رسید: " ترکیبی از چابکی و قابلیت حمل برنامه به همراه کنترل"
در مقاله قبل درباره پیاده سازی Container با ماشین مجازی صحبت کردم بنابراین ماشین های مجازی میزبان هایی عالی برای داکر هستند اما اغلب سازمان ها در فکر راه اندازی آن روی سرور فیزیکی هستند. اما چرا؟!!! زمانی که کاربران سوال زیر رو از متخصصین داکر می پرسن ، معمولا چنین بحث و گفتگویی شکل میگیره:
کاربر:از سرور فیزیکی برای پیاده سازی Docker استفاده کنم یا سرور مجازی؟
متخصص داکر:جذابیت استفاده از Docker رو میشه این مورد دونست: "تصمیم برای استفاده داکر در هر زیرساختی مثل سرور فیزیکی، مجازی ،ابری یا حتی ترکیبی از همه موارد تنها به هدف و نیاز کسب و کار شما بستگی داره(البته مرتب هم میتونه تغییر کنه)
سوالات سختی در دنیای تکنولوژی وجود داره و پاسخ "بستگی داره "اغلب می تونه راهی برای اجتناب از جواب دادن به اون ها باشه. اما در مورد محل اجرای برنامه های مبتنی بر کانتینر این پاسخ بهترین جوابه، چون شما هیچ دو برنامه کاربردی رو پیدا نمی کنید که دقیق مثل هم باشند یا حتی هیچ دو شرکتی رو پیدا نمی کنید که دقیقا نیاز های کسب و کار یکسانی داشته باشند. تصمیمات IT همیشه بر مبنای تعداد زیادی متغیر گرفته میشه: عملکرد، مقیاس پذیری، قابلیت اطمینان، امنیت، سیستم های موجود، مهارت های فعلی و هزینه و... .
داکر به شما اجازه میده که برنامه های خودتون رو روی هر زیرساختی پیاده سازی کنید! سرور فیزیکی میتونه باشه یا ماشین مجازی ، Datacenter میتونه باشه یا ابر عمومی ، حتی می تونه ترکیب سرور فیزیکی موجود در Datacenter با ماشین های مجازی موجود در انواع زیرساخت ابری متناسب با نیاز کسب و کارتون باشه.
مزیتی کلیدی ای که وجود داره اینه که شما محدود به استفاده از یک زیرساخت خاص نیستید ، برنامه های شما به آسانی و سرعت زیاد میتونن از یک زیرساخت به زیرساخت دیگه منتقل بشن.عملا تاخیر و اصطکاک میتونه صفر باشه. اما این آزادی ، فرایند تصمیم گیری در مورد محل اجرای برنامه ها رو برامون دشوار میکنه!
این تصمیم تحت تاثیر نیاز شما در زمان حال و نیاز شما در آینده گرفته میشه و به موارد زیادی بستگی داره ، کاملا موافقم که این تصمیم گیری آسان نخواهد بود! لیستی رو میخوام ارائه کنم ، این لیست احتمالا کامل نیست، اما امیدوارم به اندازه کافی برای شروع بحث و گفتگو مناسب باشه تا فرآیند تصمیم گیری رو براتون آسون کنه.
نکته آخر ، سهولت در تصمیم گیری درباره ی مکان اجرای برنامه مبتنی بر کانتینر ، کاملا وابسته به مزایاییست که آن زیرساخت برای کسب و کارتان در زمان حال و آینده خواهد داشت پس نمی بایست این سوال «سرور فیزیکی یا مجازی؟» مد نظر باشد - سوال مناسب این است که کدام زیرساخت بیشترین مزایا را برای برنامه و اهداف و نیاز های کسب و کار من خواهد داشت. بنابراین شما می توانید تمامی راه حل های مبتنی بر داکر را با هم ترکیب نموده تا به آسانی و با سرعت بالا تغییرات احتمالی حال و آینده را مدیریت کنید.
حرکت به سوی دنیای Docker می بایست از جایی شروع شود ، همیشه از مدیران سیستم انتظار می رود تا برنامه های قدیمی موجود را حفظ کرده و در عین حال برنامه های جدیدی پیاده سازی و اجرا کنند . آن ها مدام به ابزار های خود نگاه کرده و از خود می پرسند که این برنامه ها در کجا می بایست اجرا شوند؟؟
در VM یا در Container!! طبق مقالات قبل می دانیم که کانتینر ها و ماشین های مجازی می توانند با هم کار کنند، بنابراین نمی توان پاسخی واحد برای این سوال ارائه نمود.مدیران سیستم می بایست مجموعه ای از عوامل مختلف را در نظر بگیرند. با این زمینه سازی ها، سه سناریو ، برای سهولت تصمیم گیری در امر پیاده سازی برنامه های کاربردی وجود خواهد داشت:
معمولا این دسته از مشتریان به مزیت قابلیت حمل برنامه کاربردی ارائه شده توسط داکر علاقه دارند. تصور کنید اگر CIO شرکت به شما بگوید: "میخوام هزار ماشین مجازی ای که در مرکز داده داریم تا آخر هفته در Cloud به کار خودشون ادامه بدهند" انجام این کار حتی برای دزد ماشین های مجازی بسیار سخت است!
درسته که قابلیت حمل برای ماشین مجازی وجود دارد اما عالی و بدون نقص نیست زیرا تغییر Vendor وجود دارد. به عنوان مثال تصور کنید که مجازی سازی vSphere در مرکز داده دارید و اجاره دهنده زیرساخت ابری Azure است - بنابراین از چه مبدلی برای انتقال در زمان خواسته شده استفاده خواهید کرد!
انجام این کار از طریق کانتینر به تلاش بسیار کمی نیاز دارد زیرا کانتینر ها به شکل ذاتی ویژگی قابلیت حمل دارند و می توانند در یک ماشین مجازی یا حتی Cloud بدون هیچ تغییری اجرا شوند. با استفاده از قابلیت حمل ذاتی ، کانتینر ها به راحتی می توانند از ماشین مجازی به هر مقصدی مثل ماشین مجازی، سرور فیزیکی یا Cloud انتقال یابند.اگر هر کدام از این سناریوها با کسب و کار شما مطابقت داشت، احتمالا موردی مناسب برای شروع کار با Docker خواهد بود.