در رویکرد سنتی VM ، تغییر برنامه ی داخل VM نیازمند انجام عملیات ایجاد( operations folk : این روش امروزه حتی در VM ها منسوخ شده است) یا استفاده از ابزار configuration management برای دسترسی به VM و نصب نسخه ی جدید برنامه بود. راهکار immutable containers به معنای این است که زمانی که تغییرات در برنامه رخ می دهد، نسخه ی جدید برنامه در یک تصویر( container image ) جدید ساخته( build ) می شود، و به عنوان یک تصویر جدید(latest) با آن برخورد می شود و نسخه ی قبلی در حافظه ی ریپازیتوری باقی می ماند. اگر نسخه ی جدید نیاز به بازگشت به نسخه ی قبل( roll back :این اصطلاح به معنی نیاز به بازگشت به نسخه ی قبل است چرا که نسخه ی فعلی درست کار نمی کند ) داشته باشد، تنها کافی است نسخه ی قبلی را دانلود کرده و آن را به صورت کانتینری اجرا کنیم.

بکارگیری روش containerized به تیم های توسعه ی نرم افزار اجازه می دهد تا تست های مختلفی را بر روی برنامه ی خود انجام دهند و سناریوها و محیط های متفاوتی را برای اجرای نرم افزار(به صورت local ) تست و بررسی کنند. این تست ها قابلیت اعتماد ( reliablity ) و پیشبینی ( predictablity ) شرایط مختلف برنامه را قبل از اینکه به دست کاربر برسد می دهند. از آنجایی که Docker runtime environment یک محیط اجرای استاندارد را در اختیار توسعه دهندگان قرار می دهد، آنها میتوانند به سرعت issueها و errorهای پیش آمده را مجددا در برنامه ی خود ایجاد کرده و به سادگی مشکلات را debug کنند. همچنین container immutability به توسعه دهندگان اطمینان می دهد که یک نسخه از کد بین تمام محیط ها و بر روی تمام سیستم عامل ها در حال اجرا است، چرا که تصاویر در داکر در یک محیط مشابه اجرا می شوند.

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

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

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

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

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

در ادامه به مسئله ی process isolation و تفاوت آن با virtualization می پردازیم.

نکته

اگر هنوز داکر را نصب نکرده اید به فصل قبل رفته و آن را نصب کنید