فونت بارکد

توضیـحات تصویری برای تولید بارکد با اکسل !

👇مزایای سیستم‌سازی👇
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

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

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

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

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