در تهلاگ ۲۸۰، آیدین طباطبایی درباره‌ی این صحبت کرد که چطور اوپن‌سورس ستون اصلی توسعه‌ی سرویس‌های ابری مدرن است.

او با اشاره به تجربه‌ی کار با OpenStack توضیح داد که پروژه‌های متن‌باز چطور امکان ساخت زیرساخت‌های پایدار، قابل‌اعتماد و مقیاس‌پذیر را فراهم می‌کنند؛ و چرا استانداردهای باز، همکاری و سرعت توسعه را در اکوسیستم ابری بالاتر می‌برند.

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

جزئیات بیشتر را در لینکدین ببینید:
[لینک]

پایداری سرویس‌ها در پیک‌ترافیک با لود بالانسینگ نوبر

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

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

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

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

🔗 برای مطالعه نسخه کامل این مطلب، به لینک زیر مراجعه کنید:

Link

☁️@NobarCloud

💸یکی از مشکلات بزرگ کسب‌وکارها، هزینه‌های ثابت و پیش‌پرداختیه که برای منابع بلااستفاده پرداخت می‌کنند. این مسئله برای استارتاپ‌ها و کسب‌وکارهای در حال رشد که نیاز به انعطاف‌پذیری دارند، خیلی دردسرسازه.

مدل «Pay as you go» این مشکل رو حل می‌کنه! شما فقط برای منابعی که واقعاً استفاده می‌کنید هزینه می‌دید و می‌تونید منابع رو طبق نیاز خودتون تنظیم کنید.

این مدل پرداخت برای هر کسب و کاری بهینه و منطقی تر هستش!

جزئیات بیشتر در لینکدین

زمانی که ورودی کاربرها چند برابر می‌شه و سرویس رو حسابی تحت فشار می‌ذاره اگه زیرساخت آماده نباشه، کندی یا حتی قطعی سرویس اصلاً دور از انتظار نیست.

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

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


جزئیات بیشتر در لینکدین

در IaaS، منابع به‌صورت هوشمند با ترافیک هماهنگ می‌شوند؛ فشار که زیاد شود ظرفیت بالا می‌رود و بعد از پیک دوباره همه‌چیز به حالت بهینه برمی‌گردد. سرویس بدون افت کیفیت ادامه پیدا می‌کند و شما هم فقط هزینه مصرف واقعی را می‌پردازید.

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

جزئیات بیشتر در لینکدین

تو IaaS، زیرساخت فقط یه سرور روشن نیست؛ سیستم طوری طراحی می‌شه که با رفتار ترافیک تطبیق پیدا کنه. وقتی تعداد درخواست‌ها ناگهان ۳ برابر می‌شه، نودهای جدید بالا میان، CPU و RAM بیشتری تخصیص داده می‌شه و سرویس بدون افت کیفیت ادامه می‌ده. وقتی پیک تموم شد، منابع آزاد می‌شن و فقط هزینه مصرف واقعی پرداخت می‌شه.
همین منطق تو اجرای AI هم مهمه. پروژه yzma کمک می‌کنه مدل‌های هوش مصنوعی طوری اجرا شن که شبیه یه سرویس ابری واقعی رفتار کنن، نه یه اسکریپت سنگین روی یه ماشین تنها.
مثلاً مدل روی ۳ نود اجرا شده. اگر یکی به هر دلیلی down بشه، لودبالنسر سریع اون نود رو از چرخه خارج می‌کنه و ترافیک می‌ره سمت نودهای سالم؛ کاربر نه ارور می‌بینه، نه کندی حس می‌کنه.

با yzma:
۱. وابستگی مستقیم به SaaS خارجی نداری
۲. می‌تونی روی VM، Bare Metal یا کلاستر ابری خودت deploy کنی
۳. رفتار سیستم قابل پیش‌بینی و مقیاس‌پذیر می‌شه.
اگه تا دیروز IaaS رو برای وب‌سرورها و دیتابیس‌ها می‌شناختیم، امروز با ابزارهایی مثل yzma همون الگو برای مدل‌های هوش مصنوعی تکرار می‌شه: مقیاس‌پذیر، resilient و تحت کنترل خودمون.




@NobarCloud ☁️

جریان حمله دستکاری توکن GitHub (PAT)
امروز حمله‌ها فقط از «کلاد» شروع نمی‌شن، خیلی وقت‌ها از گیت‌هاب شروع می‌شن و آروم‌آروم می‌رسن به کنترل‌پلین فضای ابری.
سناریو چی بوده؟
اول مهاجم به یه Personal Access Token (PAT) دست پیدا می‌کنه؛ مثلاً از طریق فیشینگ، ریپازیتوری‌های عمومی یا توکن‌هایی که بد اسکوپ شدن می‌تونه ریپازیتوری‌ها رو بگرده، اسم secretها رو پیدا کنه، بفهمه CI/CD چطوری کار می‌کنه
حالا اگه دسترسی نوشتن هم داشته باشه، قضیه جدی‌تر می‌شه.
مهاجم می‌تونه Github Action رو تغییر بده یا workflow جدید بسازه و کد دلخواه رو اجرا کنه.
اینجاست که خیلی از تیم‌ها، کلیدهای AWS / Azure / GCP رو داخل GitHub Secrets نگه می‌دارن. گیتهاب اکشن اجرا می‌شه، secretها داخل محیط runtime در دسترسن و مهاجم می‌تونه اون‌ها رو از طریق لاگ یا خروجی‌ها استخراج کنه.
مهاجم با همون کلیدها وارد Cloud Control Plane می‌شه:
۱. کاربر جدید می‌سازه
۲. دسترسی‌ها رو بالا می‌بره
۳. منابع ابری رو کنترل می‌کنه
نکته اینه که خیلی از این کارها لاگ واضح ندارن یا بین تیم Dev و Cloud گم می‌شه و دیر متوجه بشی که حمله از کجا شروع شده.
منبع

@NobarCloud ☁️

وقتی Docker و SSL دست‌به‌گریبان می‌شن
توی دنیای واقعیِ سرورها و میکروسرویس‌ها، ارتباط امن با HTTPS و TLS حرف اول رو می‌زنه. تو یکی از پروژه‌ها، تیم Luca Baggi با یه خطای عجیب توی محیط Production روبه‌رو شد:
برنامه نمی‌تونست با یه سرویس خارجی از طریق HTTPS و mTLS ارتباط برقرار کنه و خطای TLS Handshake Failure می‌داد. یعنی ارتباط امن از همون اول شکست میخورد.
مشکل چی بود؟
وقتی تیم فنی توی محیط لوکال تست گرفت، با دستور openssl خیلی راحت تونست به سرور وصل بشه.
این یعنی:
کلاینت سالم بود و گواهی‌ها درست بودن اما به محض اینکه برنامه داخل Docker اجرا می‌شد اون هم با Distroless ایمیج، اتصال امن کلاً fail می‌شد.
راه‌حل؟
در عین سادگی، خیلی مهم بود:
۱. اضافه کردن Root CA موردنیاز به لیست ca-certificates
۲. ساختن یه Docker ایمیج جدید تا گواهی به‌عنوان گواهی قابل اعتماد شناخته بشه

به‌طور کلی:
گواهی‌ها از ایمیج Distroless اصلی برداشته شدن
داخل یه Debian Slim ایمیج قرار گرفتن
و اونجا با openssl تست گرفتن تا مطمئن بشن همه‌چیز درسته

گاهی مشکل TLS اصلاً از خود TLS نیست، از یه Root CA جاافتاده توی ایمیجه.

منبع

@NobarCloud ☁️