به طور کلی تو دنیای آی تی، هر بیزینسی نیاز به یک اپلیکیشن داره. در واقع این اپلیکیشن ها هستند که بیزینس هارو میسازن. مهم نیست بیزینس شما در مورد چه موضوعی هست، بانک، فروشگاه، بلیط مسافرت و … اپلیکیشن ها هسته این بیزینس ها هستن و به نحوی درهم آمیخته شده اند که عملا تفاوتی بین این دو وجود نداره. ممکنه خیلیا این جمله رو شنیده باشند که “بدون اپلیکیشن ها بیزینس ها هم معنی ندارند” و هر روز که میگذره به این جمله نزدیک و نزدیک تر میشیم.

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

این اتفاق برای هر اپلیکیشنی که بیزینس شما نیاز داره تکرار میشه و هزینه هنگفتی روی دست بیزینس میذاره، چه از لحاظ خرید سرور، چه از لحاظ نگهداری و تامین برق و چه ادمین هایی که قراره ازین سرورها پشتیبانی کنند. بعد از همه این اتفاق ها حالتی پیش میاد که بیزینس شما تعداد زیادی سرور گرون خریده که اکثر اون ها حتی از 10% منابعی هم که دارن استفاده نمی کنن.

با اومدن vmware این مشکلات حل شد. کاری که vmware انجام میده اینه که شما با خرید یک سرور و تقسیم منابع اون، میتونین چندین سرور مجازی داشته باشین که هر کدوم سیستم عامل خودشون رو دارن و منابع سیستم بین این سرورهای مجازی تقسیم میشه.

مثلا اگر ما 4 تا اپلیکیشن داشته باشیم، با ساختن 4 سرور مجازی و اختصاص دادن منابع به هر کدوم مثل CPU، Memory و Hard Disk، خیالمون از بابت جدا کردن منابع سرور اصلی راحته، چون هر کدوم ازین سرور های مجازی فقط منابع خودشونو میشناسن. با این حساب هر کدوم از این سرورهای مجازی به عنوان یک سرور مستقل شناخته میشن و خبری از بقیه سرورها نخواهند داشت.

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

کاری که vmware با دنیای آی تی کرد قابل چشم پوشی نیست ولی این تکنولوژی یه سری مشکلاتی هم داره.

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

مشکل بعدی وقتی رخ میده که یکی ازین سرورهای مجازی از همه ظرفیتش استفاده نکنه و مقداری از منابعش بدون مصرف باقی بمونه. تو این حالت سرورهای مجازی خبری ازین اتفاق ندارن و عملا نمیتونن ازین منابع استفاده ای داشته باشن.

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

برای حل مشکلات vmware، مفهومی به نام container ایجاد شد. ما میتونیم با استفاده از یک سیستم عامل و ایجاد container به ازای هر اپلیکیشن مشکل نصب چندین سیستم عامل رو برطرف کنیم.

همچنین مشکل تخصیص بخشی از حافظه و سی پی یو و دیسک به هر اپلیکیشن حل میشه. در واقع containerها میتونند ظرفیت سرور رو با همدیگه به اشتراک بذارن.

همچنین وجود یک سیستم عامل به جای چندین سیستم عامل، مدیریت و نگهداری سرور رو آسان تر میکنه.

سوال مهمی که اینجا پیش میاد اینه که فرق بین مدل vmware و container چیه؟

در مدل vmware، بالای سرور فیزیکی hyper visor نصب میشه که بالای اون تعدادی ماشین مجازی ساخته میشه که هر کدوم سیستم عامل خودشون رو دارن که توضیح دادیم تو این حالت چقدر منابع سیستم به هدر میره و چه مشکلات دیگه ای ممکنه پیش بیاد.

در مدل container، بالای سرور فیزیکی، سیستم عامل نصب میشه و داخل سیستم عامل containerهامون ساخته میشن که توضیح دادیم چه مزیت هایی دارن. اینم بگم که فضایی که containerها میگیرن خیلی خیلی کمتر از ماشین های مجازیه و سرعت استارت و استاپ شدنشون به شکل باور نکردنیی سریعه، چون قرار نیست مثل ماشین مجازی سیستم عاملی بالا بیاد تا اپ بتونه کارشو انجام بده.

آیا میشه گفت مهم ترین مزیت containerها اینه که مارو از شر ساختن ماشین های مجازی متعدد راحت می کنن؟

نه، اتفاقی که میفته اینه که تو بیزینس های enterprise، کانتینرها و ماشین های مجازی در کنار هم وجود دارن، حالا ممکن هست یه سری بیزینس های ساده فقط با containerها کار کنن تا کارشون راحت تر جلو بره.

اپلیکیشن های موسوم به Legacy، اپلیکیشن هایی هستند که همه ماژول های ما داخل یه پروژه هستند و اصطلاحا یه فایل binary برای پابلیش دارن. مشکلی که این حالت داره اینه که وقتی یک developer میخواد یه باگی رو رفع کنه، تغییراتش ممکنه روی کل پروژه تاثیر داشته باشه، یا حتی وقتی devOps میخواد این تغییرات رو پابلیش کنه، نیاز هست نسخه جدید رو با نسخه قدیم جایگزین کنه و این اتفاق باعث down شدن کل ماژول های ما میشه. تعریفی که اینجا وسط میاد Microserviceها هستن.

در مدل Microservice، با تبدیل کردن پروژه های بزرگ به چندین مینی اپ مشکلات قبلی رو نخواهیم داشت و کسی که میخواد بر فرض روی ماژول سرچ یه سری تغییرات جدید اعمال کنه، فقط روی همون ماژول کار می کنه و کارش تاثیری روی قسمت های دیگه نداره. همین اتفاق سمت devOps هم میفته، وقتی نسخه جدید ماژول سرچ با نسخه قدیمیش جایگزین میشه، این روال، کاری با بقیه ماژول ها نداره و اون ها همچنان up هستن و اعمال تغییرات جدید باعث از کار افتادن اون ها هنگام پابلیش نمیشه.

کاری که container ها اینجا انجام میدن اینه که میتونن توی اسکیل کردن این مینی اپ ها به ما کمک کنن. مثلا اگر پروژه ما ماژول هایی مثل وب سایت، سرچ، سفارشات و … داشته باشه، و بار خیلی زیادی روی ماژول وب سایت داشته باشیم با اضافه کردن containerهای مربوط به این ماژول می تونیم اسکیلمون رو به راحتی انجام بدیم.

Docker

وقتی که از Docker صحبت میشه دو تا موضوع باید از هم تفکیک بشن. یکی شرکت داکر (Docker Inc) و اون یکی محصولش که اصطلاحا بهش میگیم Docker Technology.

ازونجایی که containerها مثل سرورهای مجازی هستن ولی با این تفاوت که بسیار سریع تر عمل می کنند؛ کار داکر قرار دادن و اجرای اپلیکیشن ها داخل این containerهاست. داکر open source هست و روی گیت هاب کدش موجوده.

نسخه open source داکر، که بهش Community Edition هم گفته میشه کاملا رایگانه. در کنار این نسخه، شرکت داکر نسخه ای به اسم Enterprise Edition هم داره که مثل همون نسخه قبلیه با این تفاوت که پولیه و یک سری امکانات برای مدیریت بهتر containerها بهمون میده و البته قرار داد پشتیبانی شرکت رو هم با خودش به همراه داره.

در هر حال، نسخه Community و Enterprise کارشون اجرا و مدیریت اپلیکیشن ها داخل containerهاست.

بحثی که اینجا پیش میاد برای مواقعی هست که شما میخواین containerهاتون رو به صورت بهینه اسکیل کنید. ینی اگه یه instance از یه container دارین که ماژول وب سایتتون رو اجرا می کنه، برای اینکه لود خیلی زیادی روش نباشه میایم یه instance از همون container دوباره ایجاد می کنیم تا load balancing رو بهتر بتونیم مدیریت کنیم. برای مدیریت بهتر اینکار دو تا ابزار وجود داره، Swarm و Kubernetes. جفتشون خوبن ولی بخاطر اینکه کوبر امکانات بهتری بهمون میده در مورد اون صحبت می کنیم.

Kubernetes

از سال 1999 گوگل برای اینکه بتونه سرویس هایی مثل Search یا Gmail رو اسکیل کنه از containerها استفاده می کرده که تعداد این containerها خیلی زیاد بوده در حالی که اون موقه اصلا مفهومی به اسم Docker هم حتی وجود نداشته. برای مدیریت این containerها، گوگل سیستم هایی برای خودش ابداع کرد تا بتونه از پس اسکیل کردنشون بر بیاد. اولین سیستمی که برای مدیریت این containerها ساخت Borg بود. بعدش Omega ساخته شد؛ بعدش به دلایلی با استفاده از تجاربی که از Borg و Omega بدست آورده بودن تصمیمی گرفتن سیستم جدیدی رو خلق کنن. اینجا Kubernetes به وجود اومد. پس کوبر از دل گوگل بیرون اومده و البته open source هم هست.

الان ممکنه از خودتون بپرسین فرق بین Docker و Kubernetes چیه؟

داکر مسئول کار های low-level هست، مثلا start, stop یا حتی delete کردن containerها.

اما کوبر مسئول یه سری کارای high-level مثل scheduling, scaling, healing یا updating کانتینرهای شماست. یعنی اگر اتفاقی برای یکی از containerها بیفته و باعث بشه که اپلیکیشن شما داخل اون container از کار بیفته، وظیفه کوبر اینه که مراقب این مسئله باشه و سریع این اتفاق رو تشخصی بده و یک container دیگه از اپ ما بسازه. یا حتی برای وقتی که یکی از containerهای ما زیر فشاره، باز کوبر این موضوع رو تشخصی میده و یک container برای ما ایجاد می کنه. یا اگر برای container ما آپدیتی وجود داشته باشه توسط مکانیزمی همه instanceهایی که ازون container وجود دارن توسط کوبر آپدیت میشن.

برای فهم بهتر Kubernetes یک مثال ساده میزنم:

یه ارکستر رو در نظر بگیرین، هر ارکستر از انواع مختلفی از الات موسیقی تشکیل شده؛ ویولون، گیتار، درام و خیلی چیزای دیگه که هر کدوم نوت های خودشونو دارن و البته نوع استفاده از اون سازها و کاری که انجام میدن متفاوته. شخصی که جلوی همه نوازنده ها وایمیسته و به رهبر ارکستر معروفه وظیفه هماهنگی همه این نوازنده ها و سازهاشون رو بر عهده داره. اینکه چه تعداد از یک ساز باید وجود داشته باشه یا هر کدوم از نوازنده ها کی باید شروع به نواختن کنن و کی باید تموم کنن.

کاری که کوبر انجام میده دقیقا مثل رهبر ارکستر هست. در واقع کوبر با زیر نظر گرفتن containerها، برای ایجاد تغییراتی که منجر به اسکیل کردن پروژه میشه یه سری دستورات به داکر ارسال می کنه.

اگر بخوام یه مثال فنی تر بزنم میشه Docker رو به یه low-level hyper visor مثل ESXi تشبیه کرد، و کوبر هم مثل vCenter هست که بالای همه این hyper visor ها میشینه.

حالا اگه بخوایم یکم دقیق تر به مسئله نگاه کنیم، حالتی رو در نظر بگیرین که چندین تا سرور داریم که هر کدوم کوبر و داکر و کانتینر های خودشون رو دارن.

بالای همه این سرورها، مغز اصلی کوبر قرار داره که از همه این سرورها و و ضعیت containerهاشون خبر داره و وقتی بهش میگیم ازین اپمون دو تا container می خوایم، خودش همه کارارو انجام میده و تشخیص میده که روی کدوم سرور باید این containerها اجرا بشن و همون طور که قبلا هم گفتیم مراقب لود روی اپ هامون هست که با زیاد کردن کانتینر ها اینکارو انجام میده.

نویسنده: علی دهقان