در مسیر دواپس اینبار: پشت داکر چه خبره؟ (قسمت دوم)

تکنولوژی که داکر ازش داره استفاده می‌کنه چیه؟

در ادامه‌ی مسیرمون به سمت دواپس، اینبار توی قسمت دوم داکر میخواهیم بررسی کنیم که داکر از چه تکنولوژی هایی استفاده میکنه و هرکدوم چه کمکی بهش میکنن. درک این مفاهیم در ادامه مسیر بسیار بهمون کمک میکنه تا با عمق بیشتری داکر رو بفهمیم و ازش استفاده کنیم.

خب یه مروری کنیم پست‌های قبلی رو:

• دواپس چیه و چرا لازمه؟  اینجا در مورد دواپس و ضرورت استفاده از آن صحبت کردم.

• چطور اپلیکیشن مناسب کلاد آماده کنیم؟ و اینجا توضیح دادم که چطور می‌تونیم یه اپلیکیشن مناسب کلاد توسعه بدیم.

• چه عمقی از لینوکس برای دواپس لازمه؟ و اینجا توضیح دادم که کدوم موارد لینوکس برای دواپس الزامی هست که اول سراغ اون موارد بریم.

• خودکارش کن,مشکلاتت حل میشه در اینجا در مورد اتومیشن و اینکه انسیبل چیه و چه کمکی به ما می‌کنه صحبت کردم.

• در مسیر دواپس اینبار اجزای اصلی انسیبل تو این پست اجزای انسیبل رو معرفی کردم و آنها را شرح دادم.

• در مسیر دواپس به داکر رسیدیم (قسمت اول) تو این پست داکر رو شروع کردیم و اونو معرفی کردیم.

• در مسیر دواپس اینبار: پشت داکر چه خبره؟ (قسمت دوم) توی این پست در مورد تکنولوژی هایی که داکر ازشون استفاده میکنه توضیح دادیم.

• تست نوشتن و شروع مسیر CI/CD (قسمت اول) توی این پست انواع تست رو بررسی کردیم و با ابزارهای CI/CD آشنا شدیم و یه مقایسه بین گیت‌لب و جنکینز داشتیم.

• در مسیر CI/CD گیت رو بررسی می‌کنیم (قسمت دوم) توی این پست قبل ورود به گیت‌لب نیاز بود که گیت و ورژن کنترل سیستم ها رو یه بررسی کنیم.

• در مسیر ‌CI/CD شناخت گیت‌لب (قسمت سوم) توی این پست اجزای گیت‌لب رو بررسی کردیم و با کامپوننت‌های مختلفی که داره بیشتر آشنا شدیم.

• در مسیر ‌CI/CD پایپ‌لاین و رانر گیت‌لب (قسمت چهارم) توی این پست پایپ‌لاین و رانر گیت‌لب رو بررسی کردیم.

• در مسیر CI/CD وریبل، گیت‌آپس و جمع‌بندی (قسمت پنجم) توی این پست وریبل‌های گیت‌لب رو بررسی کردیم و یه معرفی کوتاه از گیت‌آپس و آتودواپس کردیم و در انتها یه مقدار تجربه‌های خودم رو در گیت‌لب باهاتون به اشتراک گذاشتم.

• در مسیر Observability، الک (قسمت دوم) توی این پست استک قدرتمند ELK رو بررسی کردیم.

• در مسیر Observability، جمع بندی استک الک (قسمت سوم) توی این پست بقیه کامپوننت‌های استک الک رو بررسی کردیم و fluentd و fluentbit رو مقایسه کردیم و نهایتا یه معرفی هم روی opensearch داشتیم.

• در مسیر Observability، استک پرومتئوس (قسمت چهارم) توی این پست یه معرفی اولیه داشتیم روی استک پرومتئوس.

• در مسیر Observability، استک پرومتئوس (قسمت پنجم) توی این پست یه مقدار کامپوننت های استک پرومتئوس رو بیشتر بررسی کردیم.

• در مسیر Observability، استک ویکتوریا (قسمت ششم) توی این پست استک ویکتوریا رو معرفی کردیم و سعی کردیم با پرومتئوس مقایسه‌اش کنیم.

• در مسیر Observability، می‌می‌ر (قسمت هفتم) توی این پست در مورد ابزار میمیر از ابزارهای گرافانا توضیح دادیم و کاربردش رو بررسی کردیم.

• در مسیر Observability، لوکی (قسمت هشتم) توی این پست در مورد ابزار گرافانا برای مدیریت لاگ یعنی لوکی توضیح دادیم و آخرشم یه معرفی کوتاه رو graylog داشتیم.

• در مسیر Observability، تمپو (قسمت نهم) توی این پست در مورد تریسینگ توضیح دادیم و گرافانا تمپو رو بررسی کردیم و یه معرفی کوتاه روی Jaeger داشتیم

• در مسیر Observability، گرافانا (قسمت دهم) توی این پست در مورد گرافانا و HA کردنش و همچنین یه سری از ابزارهاش مثل alloy , incident, on-call توضیح دادیم.

• آغاز مسیر کوبر (قسمت اول) تو این قدم به معرفی ابزارهای ارکستریشن پرداختیم و مدارک کوبرنتیز رو بررسی کردیم.

• کوبر سینگل ( قسمت دوم ) توی این قدم در مورد kubectl , kubeconfig توضیح دادیم و تعدادی ابزار رو معرفی کردیم که به کمک اونها میتونیم یک کوبرنتیز دمه‌دستی واسه تست‌هامون داشته باشیم.

• کامپوننت‌های کوبر ( قسمت سوم ) توی این پست کامپوننت‌های مختلف کوبرنتیز رو بررسی کردیم و اجزای نودهای مستر و ورکر رو دونه دونه بررسی کردیم و توضیح دادیم.

• پادها و مدیریت اونها در کوبرنتیز (قسمت چهارم) توی این پست در مورد پاد توی کوبرنتیز توضیح دادیم و موارد مربوط به اون رو بررسی کردیم.

• ورک‌لودهای کوبر و مدیریت منابع کوبر (قسمت پنجم) توی این پست در مورد namespaceها توی کوبر توضیح دادیم و انواع ورک‌لود کوبر رو بررسی کردیم.

• اگه لازم شد کوبر خودش گنده میشه‌! ( قسمت ششم ) توی این پست در مورد سه نوع ورک‌لود‌ مرتبط با scaling به صورت خودکار در کوبرنتیز توضیح دادیم.

• نتورک کوبر (قسمت هفتم) توی این قسمت انواع سرویس توی کوبرنتیز رو بررسی کردیم و در مورد مفاهیم اینگرس و نتورک پالیسی توضیح دادیم.

• استورج کوبرنتیز (قسمت هشتم) توی این قسمت در مورد انواع استورج توی کوبرنتیز توضیح دادیم و مفاهیم PV و PVC و Storage Class رو بررسی کردیم.

• پراب، ریکوئست و لیمیت (قسمت نهم) توی این قسمت موارد مربوط به محدود کردن منابع کانتینر توی کوبرنتیز رو بررسی کردیم و در مورد انواع ‌probe ها توی کوبرنتیز توضیح دادیم.

• پاد تو نود (قسمت دهم) توی این قسمت درمورد فرآیند انتقال پاد به نود مناسب مفاهیم پیشرفته‌تری مثل affinity و anti-affinity و taint و toleration رو بررسی کردیم.

• اولویت پاد و امنیت (قسمت یازدهم) توی این قسمت در مورد تعیین اولویت برای پادها و جنبه‌های مختلف امنیت در کوبرنتیز توضیح دادیم.

• کنترل دسترسی به کوبر (قسمت دوازدهم) توی این قسمت در مورد مراحل دسترسی به api کوبرنتیز صحبت کردیم و بعدش مفاهیمی مثل سرویس اکانت رو توضیح دادیم.

• دیزاین کلاستر (قسمت سیزدهم) توی این قسمت در مورد طراحی و دیزاین یک کلاستر و روش‌های مختلفی که داره توضیح دادیم و همچنین تفاوت روش‌های مختلف تقسیم منابع در کلاسترها را بررسی کردیم.

• مالتی تننسی در کوبر (قسمت چهاردهم) توی این قسمت چالش‌های مربوط به داشتن چند مستاجر بر روی کلاستر کوبرنتیز توضیح دادیم.

• هلم (قسمت پانزدهم) توی این قسمت پکیج منیجر معروف کوبرنتیز یعنی Helm رو بررسی کردیم و در موردش ویژگی‌ها و کاربردهاش توضیح دادیم.

• سی آر دی و اُپراتور (قسمت شانزدهم) توی این قسمت در مورد اینکه چطوری یه ریسورس کاستوم شده به کلاستر اضافه کنیم توضیح دادیم و مفهوم اُپراتور رو توی کوبر بررسی کردیم.

• نصب کلاستر با kubeadm (قسمت هفدهم) توی این قسمت قدم به قدم نحوه نصب یک کلاستر کوبرنتیز رو با استفاده از ابزار kubeadm توضیح دادیم.

• نصب کلاستر با kubespray (قسمت هجدهم) توی این قسمت نحوه نصب کلاستر با یه پروژه خیلی خوب به نام کیوب اسپری که یه انسیبل خفن برای ستاپ کلاستر رائه میده رو توضیح دادیم.

• نصب کلاستر با rancher (قسمت نوزدهم) توی این قسمت توضیح دادیم که چطور با استفاده از ابزار RKE یک کلاستر کوبرنتیز راه‌اندازی کنیم.

توصیه می‌کنم که حتما این پست‌ها رو هم مطالعه کنید. بریم که ادامه بدیم.

Namespace:

نیم اسپیس از قابلیت‌های کرنل لینوکس هست که یکی از پایه‌های اصلی کانتینر‌ها رو تشکیل میدن و امکان ایزوله کردن کانتینر رو به ما میدن. این تکنولوژی سال ۲۰۰۸ توسط Redhat ارائه شد. داکر با استفاده از این فیچر کرنل لینوکس، Workspace ایزوله شده رو ایجاد میکنه و زمانی‌ که شما یک کانتینر با داکر بالا میارید داکر یک دسته از نیم اسپیس‌ها رو برای اون ایجاد میکنه و کانتینر فقط به فضای محدود نیم اسپیس خودش دسترسی داره.‌

هسته داکر از این نیم اسپیس های لینوکس استفاده میکنه:

• PID: که برای ایزوله کردن پروسه ها هست

• MNT: که برای مدیریت فایل سیستم و جایی که مانت میشه هست

• IPC: نیم اسپیسی برای ارتباط های بین پروسه ها

• UTS: برای ایزوله کردن کرنل و ورژن آیدنتی‌فایرها و همچنین هاست نیم

• NET: نیم اسپیسی برای مدیریت اینترفیس های شبکه

Control Group:

کنترل گروپ فیچری از کرنل لینوکس هست که به ما امکان میده تا استفاده پروسه ها از منابع سیستم رو کنترل و محدود کنیم. با کنترل گروپ میتونیم CPU و RAM و … که به یه نیم اسپیس داده میشه رو محدود کنیم به شکلی که پروسه‌ها فقط یه مقدار مشخصی از منابع را بتونن استفاده اش کنن. این تکنولوژی رو سال ۲۰۰۶ کمپانی معظم گوگل ارائه کرد و از همون سال داخل اکوسیستم خودش داره ازش استفاده می‌کنه.

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

مواردی که داکر براشون از سی گروپ استفاده میکنه:

• CPU: برای کنترل و محدود کردن دسترسی پروسه های داکر به پردازنده سیستم که سه قسمت زیر رو داره

  • CPU Shares: پردازنده رو به پروسه ها اختصاص میده

  • CPU Quota: سقف لیمیتی که پروسه میتونه از پردازنده استفاده کنه رو مشخص میکنه

  • CPU Set: پروسه رو به دسته مشخصی از هسته های پردازنده محدود میکنه

• Memory: منیج کردن استفاده پروسه های داکر از مموری

  • Memory Limits: سقف لیمیت استفاده از مموری فیزیکی رو مشخص میکنه و اگه کانتینری اون سقف رو رد بکنه ممکنه پروسه اش کیل بشه

  • Swap Space: میزان حافظه سواپ رو برای کانتینر مشخص میکنه

  • OOM Killer:

کانتینر هایی که از لیمیت مجاز عبور میکنن میتونن مورد هدف OOM Killer یا Out of memory killer قرار بگیرن که اون رو داکر توسط سی گروپ کانفیگ میکنه

• Block i/o:

برای کانتینرها لیمیت خواندن و نوشتن دیسک مشخص می‌کنه و علاوه بر اون یه وزن دهی اهمیت بینشون میکنه تا IOPS دیسک رو بهتر مدیریت کنه کاری شبیه این رو برای پردازنده هم انجام میده.

• Devices: سی گروپ کنترل میکنه یه پروسه به چه دیواس هایی میتونه دسترسی داشته باشه

  • Device Whitelisting: مشخص میکنه که دقیقا چه دیوایس‌هایی هستن که کانتینر می‌تونه بهشون دسترسی داشته باشه که این مورد از نظر امنیتی بسیار مهم و ضروری هست

  • Device Limits: همچنین مشخص می‌کنه که لیمیت پروسه برای استفاده از اون دیوایس چقدر هست و میزان مصرفش رو کنترل میکنه

• Network:

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

• Numa(Non-Uniform Memory Access):

زمان دسترسی به مموری خیلی وابسه به جای مموری نسبت به پردازنده هست به همین علت برای بالاتر بردن پرفورمنس در استفاده از مموری کانتینر هارو به Numa node های مشخص بایند میکنه که می‌تونید بیشتر در موردش بخونید.

• Freezer:

این قابلیت میتونه برای مدیریت تسک ها و متوقف کردن پروسه بدون از بین بردنش کمک کنه. فریزر برای pause و unpause کردن پروسه های یک کانتینر استفاده می‌شه.

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

Union FS:

داکر میره سراغ یه فایل سیستمی به اسم Union FS که این فایل سیستم منحصر به لینوکس هم نیست و به ما این امکان رو میده که فایل ها و دایرکتوری های فایل سیستم های دیگه رو که با عنوان branch اینجا شناخته میشن، در کنار هم داشته باشیم و یک فایل سیستم منسجم شامل اونها رو داشته باشیم. به جورایی Union FS مثل یه روکش میاد روی فایل ها و دایرکتوری‌ها، که میتونن از بقیه فایل سیستم ها باشن قرار میگیره و در قالب یک فایل سیستم به ما امکانات جذابی رو میده که در ادامه به بررسی آنها می‌پردازیم:

• Layering:

به ما این امکان رو میده که دیتا رو به صورت لایه لایه ذخیره کنیم.

• Copy-On-Write:

این قابلیت جذاب به ما این امکان رو میده که تا زمانی‌ که داریم از روی یک لایه دیتا رو می‌خونیم، read only هست و نمی‌تونه تغییری کنه. یعنی لایه‌های مشترک که به صورت فقط خواندنی هستند دیگه کپی نمی‌شن و ازشون یکی هست. تنها اون لایه‌ای که تغییر می‌کنه یه کپی ازش ایجاد می‌شه. این قابلیت که به COW معروفه خیلی تو بهتر شدن کارایی داکر موثر است. فکر کن یه ایمیج داری که کلا فقط خواندنی هست و از روی اون یه کانتینر بالا میاریم که قابلیت R/W داره اینجا فقط اون لایه‌ی کانتیر ایجاد می‌شه و لایه‌های ایمیج دیگه کپی نمی‌شه و از همون استفاده می‌شه. حالا هر چند تا کانتینر که ازش بالا اومده باشه.

• Caching:

همین لایه لایه بودن به ما اجازه میده که کلی از دیتا رو توی داکر کَش کنیم.

• Diffing:

با قابلیت دیفینگ ما میتونم متوجه تغییرات در لایه‌ها بشیم. دقت کنید که history نداریم بلکه diff داریم که به ما تغییرات رو نشون می‌ده.

اگر به یه زبان دیگه بخوام بگم با استفاده از قابلیت‌های Union FS من اگه ده تا ایمیج داکر دارم که توشون سیستم عامل اوبونتو هست مثلا (در واقع root fs یا همون base image اوبونتو هست) و مثلا روی اون لایه‌ی دیگه‌ای مثل جاوا هست، تو سیستمم فقط یکبار این لایه ها ذخیره شده و وجود داره و اگه صدتا کانتینر هم بیاد بالا این لایه ها کَش میشه. به همین دلیل هست که شما می‌بینید یه کانتینر که حجم ایمیجش چند گیگ هست بعضا زیر یک ثانیه میاد بالا! دقیقا به این خاطر است که اون دیتای ایمیج کپی نمی‌شه و از همون لایه ای که تو ایمیج هست استفاده میشه تا زمانیکه بخوایم چیزی و بنویسیم که یه کپی از اون لایه برامون ایجاد میکنه.

Container Format:

انجین داکر نیم اسپیس و سی گروپ و یونیون اف‌اس رو داخل یک wrapper ترکیب میکنه که به اون میگیم کانتینر فرمت.

کامپوننت‌های داکر

انجین:

به هسته داکر که رو سرور یا سیستم ما اجرا میشه و از نیم اسپیس و سی گروپ استفاده میکنه میگیم انجین و جایی که انجین داکر روش باشه رو بهش میگیم داکر هاست. تمام کارهایی که با داکر انجام می‌دیم توسط انجین انجام می‌شه و اون برای ما این کارها رو می‌کنه. معمولا به انجین daemon داکر هم می‌گیم.

کلاینت:

داکر کلاینت یه کامندلاین (CLI) بهمون میده که اجازه میده دستورات داکر رو برای بیلد و ران و … اپلیکیشن‌مون اجرا کنیم و به دیمن داکر فرمان بدیم. البته این تنها راه ارتباطی ما نیست بلکه داکر یه api داره که با استفاده از اون می‌تونیم با سرویس داکر صحبت کنیم. گاهی پیش میاد که ما به جای CLI از GUI استفاده می‌کنیم که اینم می‌تونه یه کلاینت برای داکر باشه. البته CLI هر جایی که شما سرویس رو نصب کنید کنار اون نصب می‌شه و امکان کار باهاش رو دارید.

ایمیج:

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

کانتینر:

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

رجیستری و داکر هاب:

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

والیوم:

گفتیم یک کانتینر که بالا میاد یه لایه نوشتنی داره، پس داکر لازم داره که در صورت نیاز دیتایی از کانتینر رو جایی ذخیره کنه که اینجا مفهوم والیوم رو توی داکر داریم. به زبان دیگه ما به کانتیرها به صورت Ephemeral نگاه می‌کنیم و اگر دیتایی داخل اون داشتیم که برامون مهم بود ازش خارج می‌کنیم. والیوم راهی هست که با استفاده از آن می‌تونیم دیتاهای مهم داخل کانتینر رو Persist کنیم. اینجا می‌تونیم که local storage یا remote storage داشته باشیم که هر دو حالتش برامون امکان‌پذیر هست. حالا در پست بعدی بیشتر به والیوم می‌پردازیم.

نتورک:

کانتینرها برای دسترسی به شبکه و یا داشتن شبکه‌های ایزوله شده از داکر میخوان که نتورک در اختیارشون بذاره که در ادامه انواع اون رو بررسی می‌کنیم. این طوری می‌تونیم بگیم که هیچ محدودیتی برای نتورک کانتینرها نداریم و دستمون اینجا خیلی بازه. به صورت کلی می‌تونیم تمام ارتباطات کانتینرها رو مدیریت کنیم.

خوبه که داکرمی رو تو جاهای مختلف فالو کنید تا بیشتر در جریان موضوعات ما باشید.

پذیرای نظرات شما هستیم. 🌹🙏🏻🌹

🫀 Follow DockerMe 🫀

🌐 Website 🌐

🚀 Telegram 🚀

🔔 YouTube 🔔

📣 Instagram 📣

🖇 LinkedIn DockerMe🖇

🔎 Linkedin Ahmad Rafiee 🔎

🕊 Twitter 🕊