داکر ، راحت و دوست داشتنی !
مقدمه
دقت کرده باشین از سال 2015 خیلی از افراد به سمت داکر رفتن و خیلی از شرکت ها هم تویه این cycle قرار گرفتنو رفتن جلو ! اصلا چی شد که داکر روی کار اومد ؟ اصلا چرا داکر ؟ اصلا خوده داکر چیه و ....
قرار اینجا راجبش صحبت کنیم که البته توصیه میکنم اگه میخواین توش Deep تر بشین به youtube من سر بزنید.
چرا داکر ؟
اگه یادتون باشه قبل از روی کار اومدن داکر ، virtualization و بحث hypervisor بوجود اومده بود و قبل اون هم bare metal server ها بودن که راجبشون صحبت میکنیم :
سرور های Bare metal :
اون اوایل که سرور های Bara metal وجود داشت ، از لایه HW و OS و بعد اون هم app های که روشون قرار میگرفتن تشکل میشدن اما یه مشکلی اینجا وجود داشت ! اونم این بود که اصلا بحث isolate ای بین app هایی که میاوردیم بالا وجود نداشت یعنی مثلا app1 ، app2 رو به راحتی بهش access داشت و میتونست از اون استفاده کنه ! که این یعنی access کامل هر دو app به resource هم دیگه و همین باعث میشد که هر دوتاشون به هم دیگه access داشته باشن از جهتی من باید برای هر app مقدار زیادی resource استفاده میکردم که فقط برای اون app باشه که خب این اصلا نبست به سال 2022 که الان توشیم منطقی نبود ( البته اون موقع بود )
مجازی سازی و virtualization :
زمانی که مجازی سازی روی کار اومد تویه لایه os یک قسمت یا بهتر بگم یک feature قرار گرفت به اسم hyoervisor که باعث تغییر زیادی از زمان bare metal ها شد ! هم باعث شد app ها از هم isolate بشن و هم به هرکدوم از app ها resource جداگانه میداد اما یک مشکلی که داشت دقیقا همین قسمت resource بود اما چرا ؟!
فرضاً من یک app دارم و نیاز به 30GB Storage داره ، تا اینجاش مشکلی نداره اما وقتی من این app رو نیاز ندارم اون 30GB آزاد نمیشه ! برای تست این موضوع بهتون پیشنهاد میکنم یک ubuntu نصب کنید روی vm و بهش 30GB فضا بدین و بعد ماشین که اومد بالا shutdown اش کنید ، حالا وارد drive c بشین ( اگر زمان assigned کردن storage اون location اش رو تغییر ندین خودش میره از drive c اون مقداری که شما میخواین رو بر میداره ) اگه دقت کنید با توجه به خاموش شدن ماشین هنوز هم اون فضا اشغال هست .
جدا از این موضوع مصرف resource هنوز هم در این سناریو بالا بود و بهنیه مصرف نمیشد با این که hypervisor وظیفه مدیریت resource ها رو بین hardware و vm داشت .
داکر و containerization :
تقریباً از سال 2012/2015 containerization روی کار اومد که خیلی به صرفه تر بود : از نظر مصرف منابع ، isolate شدن مصرف resource بین app ، عدم write مستقیم app روی os .
از موارد دیگه ای که باعث شد سمت containerization بریم ، بحثی مثل
agile , resource consumption,zero down time
و ... بود
ساخنارش به چه شکل بود ؟
لایه containerization بین os و app ها قرار میگرفت بدین شکل که هیچ app ای با اون یکی app در ارتباط نبود مگر این که خودمون میخواستیم یا حتی اگر ما از یه app یا سرویس چنتا scale میکردیم ، فقط اندازه یکی استفاده میشد یعنی چی ؟ یعنی مثلا nginx مون 100MG فضا میخواست و اگه من از nginx ام 3 تا میوردم بالا بازم همون 100MG ای که یه بار use شده وجود داشت یعنی این مورد به 300MG ارتقاع پیدا نمیکرد .
از جهتی با توجه به قابلیت COW روی Docker روی Image یا app مون ما هیچ write ای نداشتم و فقط read میکردین و اگه چیزی میخواستیم write کنیم روی directory که ایجاد شده بود به نام
cow(copy on write )
نوشتن رو انجام میداد .
کانتینر
زمانی که ما داکر رو استفاده میکنیم در اصل داریم یک سری کانتینر میاریم بالا یعنی چی ؟
مثلا من به nginx نیاز دارم ، پس اول image اش رو باید بگیرم و بعد container رو از روی اون image میاریم بالا .
حالا چرا container ؟
دقت کرده باشین یک سری افراد هستن خونه هاشون همیشه باهاشونه پشت ماشینشون ( تویه فیلما خیلی هست اگه دیده باشین ) این خونه ها اکثرا برق و گاز ندارن و باید به یه منبعی وصل بشن برای گاز، برق و آب .
دقیقا container هم همینطوریه یعنی چی ؟ فقط باید بهش ram/cpu بدیم تا شروع به کار کردن کنه و اون سرویس یا مثلا ngixn که میخواستیم رو بیاره بالا و ما استفاده کنیم
امیدوارم تا به اینجای مطالب براتون جذاب بوده باشه و اگر میخواین داکر رو به زبان ساده و روان یاد بگیرید حتما به channel youtube من سربزنید .
در بخش های بعدی هم راجب image و بقیه موارد صحبت کنیم ...
مطلبی دیگر از این انتشارات
اشتباهات برنامه نویسان مبتدی
مطلبی دیگر از این انتشارات
کانال های یوتیوب برای بازی سازی (به خصوص یونیتی)!!!!
مطلبی دیگر از این انتشارات
ساختار اصلی زبان HTML-جلسه دوم