👇مزایای سیستم‌سازی👇
1. زمان بیشتر برای مدیر
وقتی کارها طبق سیستم پیش بره، مدیر کسب و کار زمان بیشتری برای خودش و کارهای مهم‌تر داره.
2. بهره‌وری بیشتر
با داشتن یک روش مشخص، کارها سریع‌تر و بهتر انجام میشه.
3. کاهش اشتباه‌ها
وقتی همه چیز رو به صورت منظم انجام بدی، اشتباه‌ها کمتر میشه.

کپی شده از صفحه ی اینستاگرامی :
@tav.university

در واقع Container Runtime نرم‌افزاریه که کار اجرای کانتینرها رو انجام می‌ده. کانتینرها همون بسته‌های جمع‌وجوری هستن که شامل همه‌چیز (مثل کد برنامه، کتابخونه‌ها و تنظیمات) برای اجرای یک برنامه هستن.

حالا این نرم‌افزار Container Runtime میاد و این کانتینرها رو مدیریت و اجرا می‌کنه. مثل اینه که شما یه ظرف غذا (کانتینر) داشته باشید، ولی نیاز دارید یه دستگاه گرم‌کن (Container Runtime) داشته باشید که این غذا رو برای استفاده آماده کنه.

کانتینر چیه؟
یه کانتینر یه نوع "جعبه" یا محیط ایزوله‌شده‌اس که برنامه، فایل‌های لازم برای اجراش، و تنظیماتش رو داخل خودش داره. این جعبه طوری طراحی شده که بتونه روی هر سیستمی که Container Runtime نصب باشه، اجرا بشه.

حالا Container Runtime دقیقاً چیکار می‌کنه؟

درواقع Container Runtime نرم‌افزاریه که این وظایف رو بر عهده داره:

ساخت کانتینر: وقتی شما می‌گید "این برنامه رو اجرا کن"، Container Runtime میاد و یه کانتینر جدید از اون برنامه ایجاد می‌کنه.
اجرای کانتینر: Runtime میاد کانتینر رو داخل یه محیط ایزوله روی سیستم عامل اجرا می‌کنه، طوری که انگار اون کانتینر یه سیستم عامل مجزا داره.
مدیریت منابع: مطمئن میشه که کانتینرها بیش از حد از منابع سیستم (مثل CPU، RAM یا دیسک) استفاده نکنن.
شبکه‌سازی: به کانتینرها اجازه می‌ده که به اینترنت یا به همدیگه وصل بشن.
حذف کانتینر: وقتی کار کانتینر تموم شد، Runtime می‌تونه کانتینر رو پاک کنه و منابع سیستم رو آزاد کنه.

مثال ملموس
فرض کن یه فیلم دانلود کردی و نیاز به یه پلیر خاص برای پخش اون فیلم داری. این پلیر مثل همون Container Runtime می‌مونه که وظیفه‌اش پخش فایل (کانتینر) شماست.

چه مدل‌هایی داریم؟
دو نوع کلی Container Runtime داریم:

دسته ی اول Low-level runtimes (پایه‌ای): مثل runc، که کارهای خیلی اولیه مثل ایجاد محیط ایزوله و اجرای برنامه‌ها رو انجام می‌ده.
دسته ی دوم High-level runtimes (سطح بالاتر): مثل Docker یا Podman، که علاوه بر اجرای کانتینرها، ابزارهای جانبی مثل مدیریت، شبکه‌سازی، و ذخیره‌سازی هم ارائه می‌دن.

چرا Container Runtime مهمه؟
چون این نرم‌افزار یه واسطه بین برنامه‌ها (کانتینرها) و سیستم‌عامل اصلی هست. بدون اون ، اجرای کانتینرها امکان‌پذیر نیست. در واقع، Container Runtime تمام اون چیزایی که برای اجرای یه برنامه در یک محیط ایزوله لازم داری رو برات فراهم می‌کنه.

مثال‌های معروف Container Runtime:

اول Docker: معروف‌ترینه که همه اسمش رو شنیدن.
دوم containerd: یه لایه پایین‌تر از Docker کار می‌کنه.
سوم CRI-O: مخصوص Kubernetes طراحی شده.

به زبان ساده، Container Runtime مثل یه آشپزیه که می‌دونه چطوری مواد خام رو (کانتینر) به یه غذای آماده و قابل‌مصرف (برنامه در حال اجرا) تبدیل کنه!

Installing❌ in Stalin ✅

🚫عجیب اما واقعی...

با افتخار اعلام میکنیم که در طرح "اول آورد 2" توانستیم 100 میلیون تومان اعتبار حمایتی از Avalai.ir عزیز کسب کنیم.
این طرح برای کسب و کارهای بزرگ است که اولین کسب و کار اسنپ فود بود که در این طرح قرار گرفت، اما با حمایت و لطف تیم خوب avalai ، رفهاب هم شامل این طرح شد، این برای ما تجربه ی شگفت آور و با ارزشی ست که گام بزرگی برای رشد Refhub.ir خواهد بود.

𝗧𝗼𝗽 𝟲 𝗚𝗮𝗺𝗲 𝗖𝗵𝗮𝗻𝗴𝗶𝗻𝗴 𝗞𝘂𝗯𝗲𝗿𝗻𝗲𝘁𝗲𝘀 𝗗𝗲𝗽𝗹𝗼𝘆𝗺𝗲𝗻𝘁 𝗦𝘁𝗿𝗮𝘁𝗲𝗴𝗶𝗲𝘀 🚀

𝟭. 𝗥𝗲𝗰𝗿𝗲𝗮𝘁𝗲:
All existing instances are terminated at once, and new instances with the updated version are created

𝘋𝘰𝘸𝘯𝘵𝘪𝘮𝘦: Yes
𝘜𝘴𝘦 𝘤𝘢𝘴𝘦: Non-critical applications or during initial development stages

𝟮. 𝗥𝗼𝗹𝗹𝗶𝗻𝗴 𝗨𝗽𝗱𝗮𝘁𝗲:
Application instances are updated one by one, ensuring high availability during the process

𝘋𝘰𝘸𝘯𝘵𝘪𝘮𝘦: No
𝘜𝘴𝘦 𝘤𝘢𝘴𝘦: Periodic releases

𝟯. 𝗦𝗵𝗮𝗱𝗼𝘄:
A copy of the live traffic is redirected to the new version for testing without affecting production users

This is the most complex deployment strategy and involves establishing mock services to interact with the new version of the deployment

𝘋𝘰𝘸𝘯𝘵𝘪𝘮𝘦: No
𝘜𝘴𝘦 𝘤𝘢𝘴𝘦: Validating new version performance and behavior in a real environment

𝟰. 𝗖𝗮𝗻𝗮𝗿𝘆:
The new version is released to a subset of users or servers for testing before broader deployment

𝘋𝘰𝘸𝘯𝘵𝘪𝘮𝘦: No
𝘜𝘴𝘦 𝘤𝘢𝘴𝘦: Impact validation on a subset of users

𝟱. 𝗕𝗹𝘂𝗲-𝗚𝗿𝗲𝗲𝗻:
- Two identical environments are maintained: one with the current version (blue) and the other with the updated version (green)
- Traffic starts with blue, then switches to the prepared green environment for the updated version

𝘋𝘰𝘸𝘯𝘵𝘪𝘮𝘦: No
𝘜𝘴𝘦 𝘤𝘢𝘴𝘦: High-stake updates

𝟲. 𝗔/𝗕 𝗧𝗲𝘀𝘁𝗶𝗻𝗴:
Multiple versions are concurrently tested on different users to compare performance or user experience

𝘋𝘰𝘸𝘯𝘵𝘪𝘮𝘦: Not directly applicable
𝘜𝘴𝘦 𝘤𝘢𝘴𝘦: Optimizing user experience

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

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

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

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

برنامه نویس های مبتدی معمولا درکی از شبکه و سخت افزارو نحوه اجرای کد ندارن یا اگر هم دارن خیلی سطحی هست ! برنامه نویس های حرفه ای معمولا هر ریکوست شبکه هر سویچ کانتکس روی سی پی رو حساب میکنن زمانی که دارن یه پروژه ای رو طراحی میکنن تا بتونن حداکثر توان پردازشی و شبکه رو از سخت افزار بگیرن و هزینه و منابع استفاده شده رو در سطح مناسب نگه دارن مثلا به زبون ساده بگم روی یه معماری درست مونولیتی که محاسبات فنی دقیق داشته باشه شما میتونید روی یه سرور با چهار هسته سی پی یو و دو گیگ رم تا حدود 500 هزار ریکوست همزمان رو ریسپانس بدین بدون لتنسی ! ولی وقتی از میکرو سرویس ها استفاده کنید و تمامی موارد بهینه سازی رو در نظر بگیرید حداکثر میتونید روی همون ماشین تا 1500 ریکوست همزمان رو پاسخ بدید و عملا منابع سیستم رو کامل مصرف کردید!

به طور مثال وقتی از پورت مپینگ استفاده میکنین اون پشت چه اتفاقی میوفته ؟ :
داکر مجبور میشه از NAT برای ترجمه آدرس ها و پورتهای بین شبکه هاست و کانتینر استفاده کنه که باعث سربار اضافی روی سی پی یو میشه
این باعث بوجود اومدن لتنسی میشه چون بسته ها باید از لایه نت عبور کنن
درخواست ها اول به پورت هاست میرسن و بعد به پورت کانتینر فوروارد میشن که این باعث فلود استک شبکه در سطح کرنل میشه و همچنین مسیر طولانی تری به نسبت ارتباط مستقیم هست
هر بسته داده از طریق بریدج شبکه داخلی داکر باید عبور کنه که باز سربار پردازشی اضافی وفلود استک شبکه میشه که باعث بروز لتنسی میشه
وقتی از پورت مپینگ استفاده کنین باز مجبورین از رول های iptables استفاده کنید که باز هم سربار پردازشی اضافی ایجاد میشه

برای درک موضوع :

هر کور سی پی یو در اصل یه حلقه است که با سرعت ثابت ( فرکانس سی پی یو ) داره اجرا میشه و هی کد های نرم افزار رو اجرا میکنه
وقتی شما مثلا 4 تا کور سی پی یو دارین یعنی در اصل چهار تا حلقه برای اجرای کد های نرم افزار دارین
حالا وقتی از ترد استفاده میکنید یا تعداد پروسس ها بیشتر از تعداد کور های سی پی یو هست تسک اسکجولر با استفاده از کانتکس سویچینگ بین اینها هی سویچ میکنه که بتونه همه رو همزمان اجرا کنه ! که خب این سویچ کردن خودش یک زمانی رو مصرف میکنه ! و بقیه باید توی صف منتظر بمونن تا سویچ روشون اتفاق بوفته!
اینکه میگیم سربار پردازشی یعنی این کار اضافه میره توی صف پردازش و تسک های قابل اجرا برای سی پی یو هی اضافه میشه ! و اینجوریه که سی پی یو مصرف میشه و شما توی مانیتورینگ میبینید مصرف سی پیو بالا رفته ! و اون لتنسی که اتفاق میوفته اینه یعنی تسک ها باید منتظر اجرا بمونن ! البته خیلی پیچیده تره و من سعی کردم به زبان ساده و مختصر توضیح بدم!

"We are like books"