داکر چیست؟ معرفی Docker به زبان ساده و شروع کار با Docker

داکر ( Docker ) چیست ؟ کانتینر ( Container ) چیست؟ تفاوت VM و Container در چیست؟ از سرور فیزیکی استفاده کنیم یا مجازی ؟ مزایا و معایب استفاده از داکر چیست؟ سناریوهای مختلف کار با داکر چیست؟ و ...

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

آموزش داکر (Docker) قسمت 1 : مقایسه Container و VM

Docker یکی از موفق ترین پروژه های متن باز در تاریخ فناوری اطلاعات است. سازمان ها همواره در تلاش برای افزودن قابلیت حمل به برنامه های کاربردی خود از طریق Container ها هستند ، اما اولین قدم برای رسیدن به این هدف ، درک container ها و مزایای کلیدی آنهاست.اغلب افرادی که برای اولین بار با Docker Container کار می کنند به آن "ماشین مجازی سبک وزن" می گویند! پس به آسانی قابل فهم است که این دو تکنولوژی مشخصات مشابهی دارند. اما مشخصات مشابه چه مواردی هستند؟!! هر دو طراحی شده اند تا بتوانند:

  • محیطی ایزوله برای برنامه های کاربردی فراهم کنند.
  • به راحتی بین میزبان ها (Hosts) جابجا شوند.

در واقع معماری ماشین مجازی و Container از پایه با هم متفاوت است! جهت درک بهتر موضوع میشه این مثال و مقایسه رو ارائه داد:

  • خانه ها ====> [ ماشین های مجازی ]
  • آپارتمان ها ====> [ Docker Containers ]
داکر چیست؟

خانه ها [VMs] کاملا مستقل هستند و قابلیت جلوگیری از ورود مهمان های ناخواسته را برای محافظت از خود ارائه می کنند.آنها همچنین زیرساخت های خود را دارند - لوله کشی، گرمایش، برق، و غیره ، علاوه بر این، در بیشتر موارد، خانه ها دارای حداقل یک اتاق خواب،هال و پذیرایی، حمام و آشپزخانه هستند.بسیار دشوار است که یک "خانه استودیویی" پیدا کنید

حتی اگر شخصی یکی از کوچکترین خانه هایی که می تواند پیدا کند را بخرد ، ممکن است بیشتر از آنچه نیاز دارد خرید کند و به بعضی از قسمت های خانه اصلا نیازی نداشته باشد. زیرا خانه ها فقط ساخته می شوند.(همه ی آن ها سفارشی ساخته نمی شوند - مثل سخت افزار سرور های مختلف که شرکت های سخت افزاری آن هارا برای استفاده عمومی (general-purpose) می سازندو ممکن است از همه ی منابع استفاده نکنید.)

آپارتمان ها (Docker Containers) نیز در برابر مهمانان های ناخواسته از خود محافظت می کنند، اما آنها بر روی زیرساخت مشترک ساخته شده اند.ساختمان آپارتمان یا Docker Host نیز همانند ماشین مجازی زیرساخت خود را دارد لوله کشی، گرمایش، برق، و غیره به هر آپارتمان.(سروری که سرویس شبه داکر(Docker-Daemon) در آن در حال اجراست به عنوان Docker Host یا میزبان داکر شناخته می شود.)

علاوه بر این، آپارتمان ها در اندازه های مختلف ارائه می شوند - از استودیو تا پنت هاوس چند خوابه و شما تنها دقیقا همان چیزی را که نیاز دارید اجاره می کنید.Docker Container ها از منابع سخت افزاری به اشتراک گذاشته شده Docker Host استفاده می کنند. به علاوه، توسعه دهندگان Docker Image می سازند و Docker Image دقیقا همان چیزی است که آنها برای اجرای برنامه خود نیاز دارند:

توسعه دهندگان قادرند تا به سرعت به برنامه اولیه ویژگی های جدید را اضافه کنند.)ماشین های مجازی در جهت مخالف ساخته شده اند. آنها با یک سیستم عامل شروع به کار می کنند و بسته به برنامه کاربردی، توسعه دهندگان ممکن است قادر نباشند اجزای ناخواسته را از بین ببرند یا با کندی میتوانند ویژگی جدید را اضافه کنند.برای بسیاری از افراد این مفاهیم به راحتی قابل درک هستند. با این حال، حتی زمانی که با تفاوت معماری Docker containers و ماشین های مجازی آشنا می شوند اغلب در تلاش هستند تا هرآنچه درباره ی VM می دانند با Container انطباق دهند مثلا:

  1. چطور میتوانم از Container پشتیبان بگیرم؟
  2. از کدام استراتژی مدیریتی برای اعمال patch در container های در حال اجرا استفاده کنم؟
  3. Application server کجا در حال اجراست؟

البته در پایان متوجه خواهند شد که 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 نیاز به اتصال به سرویس غیر کانتینری داشته باشند، اما عمدتا برای اغلب سرورهای مستقل که کد برنامه در آن اجرا می شود، می توان از یک یا چند کانتینر برای آن عملکرد مشابه استفاده کرد که این رویکرد دو مزیت برایمان خواهد داشت:

  1. کاهش سربار
  2. افزایش مقیاس پذیری افقی برنامه ها (لطفا جهت درک بهتر مقیاس پذیری افقی شکل زیر را مشاهده کنید)
مثالی برای مقیاس پذیری افقی برنامه

آموزش داکر (Docker) قسمت 2 : Container همراه VM

در مقاله اول درباره موضوع 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؟ مطمئنا"، "روی سرور فیزیکی؟فوق العادست"

با استفاده از کانتینر ها به تمامی اهداف خود خواهید رسید: " ترکیبی از چابکی و قابلیت حمل برنامه به همراه کنترل"

سه مورد از مزایای داکر

آموزش داکر (Docker) قسمت 3 : استفاده از سرور فیزیکی یا مجازی ؟

در مقاله قبل درباره پیاده سازی Container با ماشین مجازی صحبت کردم بنابراین ماشین های مجازی میزبان هایی عالی برای داکر هستند اما اغلب سازمان ها در فکر راه اندازی آن روی سرور فیزیکی هستند. اما چرا؟!!! زمانی که کاربران سوال زیر رو از متخصصین داکر می پرسن ، معمولا چنین بحث و گفتگویی شکل میگیره:

سرور فیزیکی برای Docker استفاده کنم یا سرور مجازی؟

کاربر:از سرور فیزیکی برای پیاده سازی Docker استفاده کنم یا سرور مجازی؟

متخصص داکر:جذابیت استفاده از Docker رو میشه این مورد دونست: "تصمیم برای استفاده داکر در هر زیرساختی مثل سرور فیزیکی، مجازی ،ابری یا حتی ترکیبی از همه موارد تنها به هدف و نیاز کسب و کار شما بستگی داره(البته مرتب هم میتونه تغییر کنه)

  • کاربر: اما مطمئنا شما توصیه ای دارید!!!
  • متخصص داکر: من به شما پاسخ دو کلمه ای میدم که کسی این پاسخو دوست نداره : "بستگی داره"
  • کاربر: شما درست می فرمایید بله اصلا پاسخ جالبی نیست.
  • متخصص داکر:بله متوجه شدم که این پاسخ جالبی نبود اما برای Docker واقعا پاسخی دقیق و درست بود.

سوالات سختی در دنیای تکنولوژی وجود داره و پاسخ "بستگی داره "اغلب می تونه راهی برای اجتناب از جواب دادن به اون ها باشه. اما در مورد محل اجرای برنامه های مبتنی بر کانتینر این پاسخ بهترین جوابه، چون شما هیچ دو برنامه کاربردی رو پیدا نمی کنید که دقیق مثل هم باشند یا حتی هیچ دو شرکتی رو پیدا نمی کنید که دقیقا نیاز های کسب و کار یکسانی داشته باشند. تصمیمات IT همیشه بر مبنای تعداد زیادی متغیر گرفته میشه: عملکرد، مقیاس پذیری، قابلیت اطمینان، امنیت، سیستم های موجود، مهارت های فعلی و هزینه و... .

داکر به شما اجازه میده که برنامه های خودتون رو روی هر زیرساختی پیاده سازی کنید! سرور فیزیکی میتونه باشه یا ماشین مجازی ، Datacenter میتونه باشه یا ابر عمومی ، حتی می تونه ترکیب سرور فیزیکی موجود در Datacenter با ماشین های مجازی موجود در انواع زیرساخت ابری متناسب با نیاز کسب و کارتون باشه.

مزیتی کلیدی ای که وجود داره اینه که شما محدود به استفاده از یک زیرساخت خاص نیستید ، برنامه های شما به آسانی و سرعت زیاد میتونن از یک زیرساخت به زیرساخت دیگه منتقل بشن.عملا تاخیر و اصطکاک میتونه صفر باشه. اما این آزادی ، فرایند تصمیم گیری در مورد محل اجرای برنامه ها رو برامون دشوار میکنه!

این تصمیم تحت تاثیر نیاز شما در زمان حال و نیاز شما در آینده گرفته میشه و به موارد زیادی بستگی داره ، کاملا موافقم که این تصمیم گیری آسان نخواهد بود! لیستی رو میخوام ارائه کنم ، این لیست احتمالا کامل نیست، اما امیدوارم به اندازه کافی برای شروع بحث و گفتگو مناسب باشه تا فرآیند تصمیم گیری رو براتون آسون کنه.

  • Latency(تاخیر): برنامه هایی که به تاخیر حساس هستند بهتر روی سرور فیزیکی ایفای نقش می کنند. حساس بودن به تاخیر در سرویس های مالی بسیار مشاهده می شود( مثل برنامه هایی مربوط به معاملات تجاری و ...).
  • Capacity(ظرفیت):ماشین های مجازی جهت استفاده مناسب از ظرفیت بهینه شده اند.اگر برنامه مبتنی بر کانتینر شما ، تمام ظرفیت زیرساخت فیزیکی رو اشغال نکنه ، مجازی سازی هنوز میتونه مفید باشه.
  • Mixed Workloads: روی سرور فیزیکی تنها می توانید یک سیستم عامل اجرا کنید، بنابراین، اگر بخواهید از ترکیب کانتینر های ویندوزی و لینوکسی استفاده کنید، می بایست از مجازی سازی استفاده کنید.
  • Disaster Recovery (بازیابی فاجعه): همانند بهینه سازی ظرفیت، یکی از مزایای عالی VM ها قابلیت های پیشرفته در حوزه بازیابی اطلاعات(site recovery) و در دسترس بودن بالای سیستم ها(High Availablity)است. در حالی که این قابلیت ها ممکن است در میزبان های فیزیکی وجود داشته باشند اما انتخاب های بیشتری از طریق مجازی سازی خواهید داشت.
  • Existing Investments and Automation Frameworks (سرمایه گذاری های موجود و چارچوب اتوماسیون): بسیاری از سازمان ها در حال حاضر مجموعه وسیعی از ابزارها را در زمینه هایی مانند پیاده سازی زیرساخت ایجاد کرده اند بنابریان باید بتوان از زیرساخت و سرمایه گذاری موجود در حوزه های جدید استفاده نمود.
  • Multitenancy:برخی از مشتریان دارای حجم کاری خاصی هستند و نمی توانند هسته های لینوکسی و ویندوزی(Kernels) را به اشتراک بگذارند. در این مورد VM ها لایه ای اضافی برای ایزوله سازی علاوه بر Container ها ایجاد می کنند.
  • Resource Pools / Quotas: بسیاری از راه حل های مجازی سازی مجموعه ای از ویژگی های گسترده ای برای کنترل اینکه چگونه ماشین های مجازی از منابع استفاده کنند را ارائه می دهند.Docker نیز مفهوم محدودیت منابع را فراهم می کند، اما برای سرور فیزیکی مدیریت منابع به شما بستگی دارد.
  • Automation / API (اتوماسیون و واسط های برنامه نویسی): تعداد بسیار کمی از افراد در یک سازمان به طور معمول توانایی پیاده سازی با API روی سرور فیزیکی را دارند. اگر هدف اتوماسیون است، شما به API نیاز خواهید داشت، که این معیار را سرور های فیزیکی ندارند.
  • Licensing Costs (هزینه های صدور مجوز): اجرا بدون واسط روی سرور فیزیکی به خودی خود هزینه ها را کاهش می دهد، زیرا مجبور نیستید License های Hypervisor را خریداری کنید و حتی نیازی به پرداخت هزینه برای سیستم عامل های مختلف جهت میزبانی داکر نخواهید داشت و تنها از یک سیستم عامل استفاده خواهید کرد(آن هم می تواند متن باز باشد)

نکته آخر ، سهولت در تصمیم گیری درباره ی مکان اجرای برنامه مبتنی بر کانتینر ، کاملا وابسته به مزایاییست که آن زیرساخت برای کسب و کارتان در زمان حال و آینده خواهد داشت پس نمی بایست این سوال «سرور فیزیکی یا مجازی؟» مد نظر باشد - سوال مناسب این است که کدام زیرساخت بیشترین مزایا را برای برنامه و اهداف و نیاز های کسب و کار من خواهد داشت. بنابراین شما می توانید تمامی راه حل های مبتنی بر داکر را با هم ترکیب نموده تا به آسانی و با سرعت بالا تغییرات احتمالی حال و آینده را مدیریت کنید.

آموزش داکر (Docker) قسمت 4 : شروع کار با Docker

حرکت به سوی دنیای Docker می بایست از جایی شروع شود ، همیشه از مدیران سیستم انتظار می رود تا برنامه های قدیمی موجود را حفظ کرده و در عین حال برنامه های جدیدی پیاده سازی و اجرا کنند . آن ها مدام به ابزار های خود نگاه کرده و از خود می پرسند که این برنامه ها در کجا می بایست اجرا شوند؟؟

در VM یا در Container!! طبق مقالات قبل می دانیم که کانتینر ها و ماشین های مجازی می توانند با هم کار کنند، بنابراین نمی توان پاسخی واحد برای این سوال ارائه نمود.مدیران سیستم می بایست مجموعه ای از عوامل مختلف را در نظر بگیرند. با این زمینه سازی ها، سه سناریو ، برای سهولت تصمیم گیری در امر پیاده سازی برنامه های کاربردی وجود خواهد داشت:

داکر برای کارشناسان مجازی سازی
  • سناریو اول : "می خواهید برنامه کاربردی جدید یا برنامه های کاربردی نوشته شده قبلی خود را از صفر تا صد با استفاده از معماری Micro-service مبتنی بر Container بنویسید." در بسیاری از موارد شرکت ها مدل یکپارچه برنامه خود را رها کرده و نسخه جدید آن را بر پایه مدل Micro-service مبتنی بر Container می نویسند. با استفاده از Docker، شرکت ها نیز می توانند توسعه و تحویل برنامه ها را سرعت بخشیده و همان کد را بدون هیچ تغییری روی هر زیرساختی اجرا کنند.
  • سناریو دوم : "می خواهید نرم افزار موجود خود را طبق معماری Micro-service توسعه داده و قبل از اتمام کدنویسی از مزایای داکر بهره مند شوید." در این سناریو، شرکت ها سعی می کنند یک برنامه موجود در ماشین مجازی را تغییر دهند تا آرام آرام به کانتینر ها مهاجرت کنند. با اجرای برنامه یکپارچه در یک کانتینر تیم توسعه می تواند به مرور زمان سعی در شکستن آن به واحد های کوچکتر کند. آن ها این کار را با شکستن برخی از توابع به سرویس های کوچکتر انجام می دهند. کانتینرهای جدید می توانند با برنامه های کاربردی قدیمی تر (بدون توجه به مکان اجرای برنامه) در صورت لزوم ارتباط برقرار کنند ، با گذر زمان و تلاش توسعه دهندگان ، کل برنامه کاربردی به سرویس های کوچکتر قابل حمل مقیاس پذیر شکسته شده و هریک از این سرویس ها در یک کانتینر مجزا اجرا خواهند شد.
  • سناریو سوم : "می خواهید بدون نوشتن کد جدید برنامه خود را از مدل مبتنی بر ماشین مجازی یکپارچه (Monolithic VM) به مدل مبتنی بر Container بدون هیچ دردسری منتقل کنید."

معمولا این دسته از مشتریان به مزیت قابلیت حمل برنامه کاربردی ارائه شده توسط داکر علاقه دارند. تصور کنید اگر CIO شرکت به شما بگوید: "میخوام هزار ماشین مجازی ای که در مرکز داده داریم تا آخر هفته در Cloud به کار خودشون ادامه بدهند" انجام این کار حتی برای دزد ماشین های مجازی بسیار سخت است!

درسته که قابلیت حمل برای ماشین مجازی وجود دارد اما عالی و بدون نقص نیست زیرا تغییر Vendor وجود دارد. به عنوان مثال تصور کنید که مجازی سازی vSphere در مرکز داده دارید و اجاره دهنده زیرساخت ابری Azure است - بنابراین از چه مبدلی برای انتقال در زمان خواسته شده استفاده خواهید کرد!

انجام این کار از طریق کانتینر به تلاش بسیار کمی نیاز دارد زیرا کانتینر ها به شکل ذاتی ویژگی قابلیت حمل دارند و می توانند در یک ماشین مجازی یا حتی Cloud بدون هیچ تغییری اجرا شوند. با استفاده از قابلیت حمل ذاتی ، کانتینر ها به راحتی می توانند از ماشین مجازی به هر مقصدی مثل ماشین مجازی، سرور فیزیکی یا Cloud انتقال یابند.اگر هر کدام از این سناریوها با کسب و کار شما مطابقت داشت، احتمالا موردی مناسب برای شروع کار با Docker خواهد بود.

  • داکر ( Docker ) چیست؟

    به زبان ساده داکر یک سرویس مجازی سازی سیستم عامل یا OS Virtualization است که با استفاده از مکانیزم استفاده از هسته سیستم عامل اصلی میزبان ( Host ) امکان ساخت و استفاده از سریعترین ماشین های مجازی را به شما می دهد.

نظرات