🔵 عنوان مقاله
Threat Actors leverage Docker Swarm and Kubernetes to mine cryptocurrency at scale (3 minute read)
🟢 خلاصه مقاله:
یک کمپین جدید کریپتوجکینگ به API انجین Docker حمله می‌کند و اجازه حرکت جانبی به Docker Swarm، کوبرنتیس و سرورهای SSH را می‌دهد. عامل تهدید از اورکستراسیون Docker Swarm برای فرمان و کنترل استفاده می‌کند و تصاویر مخرب را بر روی Docker Hub میزبانی می‌کند. همچنین نشانه‌هایی وجود دارد که زیرساخت‌های GitHub Codespaces نیز هدف قرار گرفته‌اند. این حملات می‌توانند به سرقت منابع محاسباتی برای استخراج ارزهای رمزپایه منجر شوند، بنابراین تأمین امنیت واجهه‌های برنامه‌نویسی کاربردی و بررسی مداوم پیکربندی‌ها و اجتناب از استفاده از تصاویر نامعتبر از منابع نامطمئن حیاتی است.
🟣لینک مقاله:
https://securitylabs.datadoghq.com/articles/threat-actors-leveraging-docker-swarm-kubernetes-mine-cryptocurrency?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Threat Actors leverage Docker Swarm and Kubernetes to mine cryptocurrency at scale (3 minute read)
🟢 خلاصه مقاله:
یک کمپین جدید کریپتوجکینگ به API انجین Docker حمله می‌کند و اجازه حرکت جانبی به Docker Swarm، کوبرنتیس و سرورهای SSH را می‌دهد. عامل تهدید از اورکستراسیون Docker Swarm برای فرمان و کنترل استفاده می‌کند و تصاویر مخرب را بر روی Docker Hub میزبانی می‌کند. همچنین نشانه‌هایی وجود دارد که زیرساخت‌های GitHub Codespaces نیز هدف قرار گرفته‌اند. این حملات می‌توانند به سرقت منابع محاسباتی برای استخراج ارزهای رمزپایه منجر شوند، بنابراین تأمین امنیت واجهه‌های برنامه‌نویسی کاربردی و بررسی مداوم پیکربندی‌ها و اجتناب از استفاده از تصاویر نامعتبر از منابع نامطمئن حیاتی است.
🟣لینک مقاله:
https://securitylabs.datadoghq.com/articles/threat-actors-leveraging-docker-swarm-kubernetes-mine-cryptocurrency?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Datadoghq
Threat Actors leverage Docker Swarm and Kubernetes to mine cryptocurrency at scale
Analyzing a campaign where a threat actor leveraged Docker Swam and Kubernetes to mine cryptocurrency
👍1
🔵 عنوان مقاله
Memory Leak Issues Are not always Memory Leak (3 minute read)
🟢 خلاصه مقاله:
مقاله‌ای که بررسی شده است به مسائل مربوط به مقیاس‌پذیری در زمینه حافظه‌ی خوشه‌ای جاوا پرداخته است، که به دلیل عدم بازگشت حافظه به سیستم‌عامل، توسعه‌دهندگان مجبور به تغییراتی شده‌اند. در ابتدا، آنها به استفاده از Garbage Collector (GC) شناخته شده به نام ShenandoahGC روی آوردند. با این حال، با ارتقا به نسخه 17 از JDK، امکان بازگشت به G1 GC فراهم شد که این تغییر، به بهبود عملکرد و مدیریت حافظه کمک کرد. این ارتقاء به طور موثری به حل مشکلات مقیاس‌پذیری کمک کرد و بهبودهایی در مدیریت حافظه‌ی جاوا را به همراه داشت، که این نشان‌دهنده‌ی اهمیت انتخاب گاربج کالکتور مناسب و به‌روزرسانی‌های متعاقب در بهینه‌سازی عملکرد سیستم‌ها است.
🟣لینک مقاله:
https://medium.com/@ankgupta067/memory-leak-issues-are-not-always-memory-leak-f60aa2e4ebde?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Memory Leak Issues Are not always Memory Leak (3 minute read)
🟢 خلاصه مقاله:
مقاله‌ای که بررسی شده است به مسائل مربوط به مقیاس‌پذیری در زمینه حافظه‌ی خوشه‌ای جاوا پرداخته است، که به دلیل عدم بازگشت حافظه به سیستم‌عامل، توسعه‌دهندگان مجبور به تغییراتی شده‌اند. در ابتدا، آنها به استفاده از Garbage Collector (GC) شناخته شده به نام ShenandoahGC روی آوردند. با این حال، با ارتقا به نسخه 17 از JDK، امکان بازگشت به G1 GC فراهم شد که این تغییر، به بهبود عملکرد و مدیریت حافظه کمک کرد. این ارتقاء به طور موثری به حل مشکلات مقیاس‌پذیری کمک کرد و بهبودهایی در مدیریت حافظه‌ی جاوا را به همراه داشت، که این نشان‌دهنده‌ی اهمیت انتخاب گاربج کالکتور مناسب و به‌روزرسانی‌های متعاقب در بهینه‌سازی عملکرد سیستم‌ها است.
🟣لینک مقاله:
https://medium.com/@ankgupta067/memory-leak-issues-are-not-always-memory-leak-f60aa2e4ebde?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Medium
Memory Leak Issues, Are not always Memory Leak
One of the most challenging problems developers encounter in their careers is resolving memory issues. These problems are particularly…
👍1
🔵 عنوان مقاله
Mitmproxy 11: Full HTTP/3 Support (3 minute read)
🟢 خلاصه مقاله:
Mitmproxy نسخه 11، که توسط گورو جین در طی برنامه Google Summer of Code توسعه یافته است، پشتیبانی کامل از HTTP/3 و پیشرفت‌های قابل توجهی در DNS را معرفی می‌کند. این نسخه شامل انواع پرس و جوی گسترده و بهبود پشتیبانی از DNS-over-TCP است. همچنین، در پاسخ به پیشرفت‌های حفظ حریم خصوصی مانند Encrypted Client Hello، این نسخه با حذف کلیدهای ECH، به حفظ عملکرد مناسب کمک می‌کند. این تغییرات به منظور تسهیل در ادامه کارکرد مناسب با وجود تغییرات امنیتی انجام شده است. این به روزرسانی‌ها باعث بهبود قابل توجهی در قابلیت‌ها و امنیت کاربران Mitmproxy شده است.
🟣لینک مقاله:
https://mitmproxy.org/posts/releases/mitmproxy-11/?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Mitmproxy 11: Full HTTP/3 Support (3 minute read)
🟢 خلاصه مقاله:
Mitmproxy نسخه 11، که توسط گورو جین در طی برنامه Google Summer of Code توسعه یافته است، پشتیبانی کامل از HTTP/3 و پیشرفت‌های قابل توجهی در DNS را معرفی می‌کند. این نسخه شامل انواع پرس و جوی گسترده و بهبود پشتیبانی از DNS-over-TCP است. همچنین، در پاسخ به پیشرفت‌های حفظ حریم خصوصی مانند Encrypted Client Hello، این نسخه با حذف کلیدهای ECH، به حفظ عملکرد مناسب کمک می‌کند. این تغییرات به منظور تسهیل در ادامه کارکرد مناسب با وجود تغییرات امنیتی انجام شده است. این به روزرسانی‌ها باعث بهبود قابل توجهی در قابلیت‌ها و امنیت کاربران Mitmproxy شده است.
🟣لینک مقاله:
https://mitmproxy.org/posts/releases/mitmproxy-11/?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
👍1
🔵 Kubernetes StatefulSet - Examples & Best Practices
🎯 https://loft.sh/blog/kubernetes-statefulset-examples-and-best-practices/
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
🎯 https://loft.sh/blog/kubernetes-statefulset-examples-and-best-practices/
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
🥰1
خط زیر در یک Dockerfile به معنای فشرده‌سازی یک فایل اجرایی با استفاده از ابزار
### مفهوم این خط:
1. **
2.
3. **
4. **
5. **
### به طور خلاصه:
این خط کد، فایل اجرایی
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
upx است:RUN upx --best --lzma -o main_compressed main
### مفهوم این خط:
1. **
upx: این دستور فراخوانی ابزار UPX است که برای فشرده‌سازی فایل‌های اجرایی استفاده می‌شود.2.
--best:** این گزینه به upx می‌گوید که از بهترین روش فشرده‌سازی ممکن استفاده کند. این حالت فشرده‌سازی بیشتری را ایجاد می‌کند، اما ممکن است زمان بیشتری طول بکشد.3. **
--lzma:** این گزینه از الگوریتم فشرده‌سازی LZMA استفاده می‌کند، که یک الگوریتم فشرده‌سازی با راندمان بالا است. LZMA معمولاً نسبت به الگوریتم‌های دیگر فشرده‌سازی بهتری ارائه می‌دهد، اما ممکن است پردازش بیشتری نیاز داشته باشد.4. **
-o main_compressed:** این قسمت نشان می‌دهد که خروجی فشرده‌شده به جای اینکه به همان نام اصلی باشد، در فایلی به نام main_compressedmain:د.5. **
main:** این بخش نام فایل اجرایی اصلی است که قرار است فشرده شود.### به طور خلاصه:
این خط کد، فایل اجرایی
main را با استفاده از UPX فشرده کرده و خروجی فشرده‌شده را به عنوان یک فایل جدید به نام main_compressed ذخیره می‌کند. این فشرده‌سازی با بالاترین سطح بهینه‌سازی (--best) و الگوریتم LZMA انجام می‌شود.➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
🔥1
This GitHub Action creates a GitHub contribution calendar on a 3D profile image.
به کمک این github action میتونید بصورت روزانه از فعالیت‌هاتون توی گیت‌هاب نقشه سه بعدی بسازید و حال کنید :)
#github #profile #portfolio #readme #svg #action #image #calendar #contribution
https://github.com/yoshi389111/github-profile-3d-contrib
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
به کمک این github action میتونید بصورت روزانه از فعالیت‌هاتون توی گیت‌هاب نقشه سه بعدی بسازید و حال کنید :)
#github #profile #portfolio #readme #svg #action #image #calendar #contribution
https://github.com/yoshi389111/github-profile-3d-contrib
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
🍓1
🔵 عنوان مقاله
How to Build an Internal Developer Platform Like a Product (4 minute read)
🟢 خلاصه مقاله:
مهندسی پلتفرم نیازمند تغییر ذهنیتی است برای درک پلتفرم‌های توسعه‌دهنده داخلی به‌عنوان محصولاتی که باید بر نیازها و تجربیات توسعه‌دهندگان تمرکز کنند. این رویکرد به معنای تبدیل سیاست‌ها و ابزارهای موجود در سازمان‌ها است تا به گونه‌ای عمل کنند که بهره‌وری توسعه‌دهندگان را به حداکثر برسانند و موانع موجود در فرآیندهای توسعه را کاهش دهند. این مقاله بیان می‌کند که پلتفرم‌ها باید به‌صورتی طراحی شوند که انعطاف‌پذیری برای پاسخگویی به تغییرات فناوری و نیازهای کاربران را داشته باشند. همچنین، تاکید می‌کند که پلتفرم‌ها باید به طور مداوم توسط تیم‌های مهندسی بازبینی و به‌روزرسانی شوند تا توسعه‌دهندگان بتوانند به صورت مؤثرتر و کارآمدتر کار کنند. در نهایت، مقاله پیشنهاد می‌کند که فرهنگ سازمانی باید هماهنگ با این تغییر ذهنیت باشد و از توسعه‌دهندگان به‌منظور خلق پلتفرم‌هایی که واقعاً پاسخگوی نیازهای آنان است حمایت کند.
🟣لینک مقاله:
https://thenewstack.io/how-to-build-an-internal-developer-platform-like-a-product/?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
How to Build an Internal Developer Platform Like a Product (4 minute read)
🟢 خلاصه مقاله:
مهندسی پلتفرم نیازمند تغییر ذهنیتی است برای درک پلتفرم‌های توسعه‌دهنده داخلی به‌عنوان محصولاتی که باید بر نیازها و تجربیات توسعه‌دهندگان تمرکز کنند. این رویکرد به معنای تبدیل سیاست‌ها و ابزارهای موجود در سازمان‌ها است تا به گونه‌ای عمل کنند که بهره‌وری توسعه‌دهندگان را به حداکثر برسانند و موانع موجود در فرآیندهای توسعه را کاهش دهند. این مقاله بیان می‌کند که پلتفرم‌ها باید به‌صورتی طراحی شوند که انعطاف‌پذیری برای پاسخگویی به تغییرات فناوری و نیازهای کاربران را داشته باشند. همچنین، تاکید می‌کند که پلتفرم‌ها باید به طور مداوم توسط تیم‌های مهندسی بازبینی و به‌روزرسانی شوند تا توسعه‌دهندگان بتوانند به صورت مؤثرتر و کارآمدتر کار کنند. در نهایت، مقاله پیشنهاد می‌کند که فرهنگ سازمانی باید هماهنگ با این تغییر ذهنیت باشد و از توسعه‌دهندگان به‌منظور خلق پلتفرم‌هایی که واقعاً پاسخگوی نیازهای آنان است حمایت کند.
🟣لینک مقاله:
https://thenewstack.io/how-to-build-an-internal-developer-platform-like-a-product/?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
The New Stack
How to Build an Internal Developer Platform Like a Product
Learn from four platform advocates about how to apply a Platform as a Product mindset to your platform engineering strategy.
🔵 عنوان مقاله
Exploiting Visual Studio via dump files - CVE-2024-30052 (12 minute read)
🟢 خلاصه مقاله:
مقاله مورد بحث CVE-2024-30052، آسیب‌پذیری را در Visual Studio بررسی می‌کند که اجازه اجرای کد دلخواه از طریق فایل‌های dump طراحی شده‌ی خاص را می‌دهد و به امنیت سیستم‌ها خطر جدی وارد می‌کند. در این مقاله، چگونگی کشف این آسیب‌پذیری و مراحل اقدام برای گزارش دادن و کاهش اثرات آن توسط نویسنده به شرکت مایکروسافت تشریح شده است. این فرایند شامل شناسایی نقطه ضعف، توسعه‌ی راهکارهای اولیه برای جلوگیری از حملات و همکاری با تیم امنیتی مایکروسافت برای ارائه‌ی یک بروزرسانی امنیتی مؤثر است. خطرات جدی ناشی از این آسیب‌پذیری و اهمیت پاسخ سریع و همکاری در فرایند گزارش‌دهی برای تضمین امنیت کاربران نهایی تأکید می‌یابد. در نهایت، نتیجه‌گیری می‌شود که شفافیت و اقدام به موقع کلید تضمین حفاظت از داده‌ها و سیستم‌های متأثر است.
🟣لینک مقاله:
https://ynwarcs.github.io/exploiting-vs-dump-files?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Exploiting Visual Studio via dump files - CVE-2024-30052 (12 minute read)
🟢 خلاصه مقاله:
مقاله مورد بحث CVE-2024-30052، آسیب‌پذیری را در Visual Studio بررسی می‌کند که اجازه اجرای کد دلخواه از طریق فایل‌های dump طراحی شده‌ی خاص را می‌دهد و به امنیت سیستم‌ها خطر جدی وارد می‌کند. در این مقاله، چگونگی کشف این آسیب‌پذیری و مراحل اقدام برای گزارش دادن و کاهش اثرات آن توسط نویسنده به شرکت مایکروسافت تشریح شده است. این فرایند شامل شناسایی نقطه ضعف، توسعه‌ی راهکارهای اولیه برای جلوگیری از حملات و همکاری با تیم امنیتی مایکروسافت برای ارائه‌ی یک بروزرسانی امنیتی مؤثر است. خطرات جدی ناشی از این آسیب‌پذیری و اهمیت پاسخ سریع و همکاری در فرایند گزارش‌دهی برای تضمین امنیت کاربران نهایی تأکید می‌یابد. در نهایت، نتیجه‌گیری می‌شود که شفافیت و اقدام به موقع کلید تضمین حفاظت از داده‌ها و سیستم‌های متأثر است.
🟣لینک مقاله:
https://ynwarcs.github.io/exploiting-vs-dump-files?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
###
Exploiting Visual Studio via dump files - CVE-2024-30052
🔵 عنوان مقاله
The coldest Monday with a $1 million cloud bill: Terraform to the rescue (2 minute read)
🟢 خلاصه مقاله:
خلاصه مقاله:
یک کلید سرویس مختل شده منجر به حمله کریپتوماینینگ در یک استارتاپ شد که نتیجتاً باعث ایجاد هزینه‌های غیرمنتظره بیش از 1 میلیون دلار در هزینه‌های ابری شد. در این مورد، از یک کلید دسترسی که به طور نادرست مدیریت شده بود استفاده شد تا به منابع ابری دسترسی یابند و توان محاسباتی آنها برای استخراج ارزهای دیجیتال به راه انداخته شود. این موضوع تأکید می‌کند بر اهمیت امنیت سایبری و ضرورت دقیق مدیریت و نگهداری از دسترسی‌های اعتباری برای جلوگیری از دسترسی‌های غیرمجاز و اعمال فعالیت‌های مخرب. پیامدهای این حادثه برای استارتاپ مذکور شامل هزینه‌های مالی سنگین، آسیب به شهرت و اعتماد سرمایه‌گذاران بود، که نیاز به بازبینی و تقویت اقدامات امنیتی را یادآوری می‌کند.
🟣لینک مقاله:
https://www.hashicorp.com/resources/the-coldest-monday-with-a-1-million-cloud-bill-terraform-to-the-rescue?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
The coldest Monday with a $1 million cloud bill: Terraform to the rescue (2 minute read)
🟢 خلاصه مقاله:
خلاصه مقاله:
یک کلید سرویس مختل شده منجر به حمله کریپتوماینینگ در یک استارتاپ شد که نتیجتاً باعث ایجاد هزینه‌های غیرمنتظره بیش از 1 میلیون دلار در هزینه‌های ابری شد. در این مورد، از یک کلید دسترسی که به طور نادرست مدیریت شده بود استفاده شد تا به منابع ابری دسترسی یابند و توان محاسباتی آنها برای استخراج ارزهای دیجیتال به راه انداخته شود. این موضوع تأکید می‌کند بر اهمیت امنیت سایبری و ضرورت دقیق مدیریت و نگهداری از دسترسی‌های اعتباری برای جلوگیری از دسترسی‌های غیرمجاز و اعمال فعالیت‌های مخرب. پیامدهای این حادثه برای استارتاپ مذکور شامل هزینه‌های مالی سنگین، آسیب به شهرت و اعتماد سرمایه‌گذاران بود، که نیاز به بازبینی و تقویت اقدامات امنیتی را یادآوری می‌کند.
🟣لینک مقاله:
https://www.hashicorp.com/resources/the-coldest-monday-with-a-1-million-cloud-bill-terraform-to-the-rescue?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
HashiCorp
The coldest Monday with a $1 million cloud bill: Terraform to the rescue
How a cryptomining attack led to one startup's overhaul of its cost management systems with the help of Terraform.
بین آمازون وب سرویس (AWS) و گوگل کلاد (GCP)، هر دو سرویس پلن‌های رایگان دارند، اما تفاوت‌هایی در این طرح‌ها وجود دارد که می‌تواند بسته به نیازهای شما، یکی از این دو را مناسب‌تر کند.
### 1. AWS Free Tier:
AWS سه نوع پلن رایگان ارائه می‌دهد:
- 12 ماه رایگان: بسیاری از خدمات AWS مانند EC2 (750 ساعت استفاده از یک سرور کوچک در هر ماه)، S3 (تا 5 گیگابایت فضای ذخیره‌سازی) و RDS (دیتابیس مدیریت شده) برای 12 ماه اول رایگان هستند.
- پلن همیشه رایگان: خدماتی مثل AWS Lambda (1 میلیون درخواست در هر ماه) و S3 Glacier (10 گیگابایت ذخیره‌سازی) همیشه رایگان هستند.
- Free Trials: برخی از خدمات AWS برای مدت زمان محدودی (30 تا 60 روز) به صورت رایگان ارائه می‌شوند.
### 2. Google Cloud Free Tier:
Google Cloud هم دو نوع طرح رایگان دارد:
- 300 دلار اعتبار رایگان برای 90 روز: در این مدت می‌توانید از هر سرویس گوگل کلاد استفاده کنید.
- پلن همیشه رایگان: شامل سرویس‌هایی مثل Compute Engine (سرور مجازی کوچک با 1 گیگابایت رم و 30 گیگابایت هارد)، Google Cloud Functions (2 میلیون درخواست در هر ماه)، و Cloud Storage (تا 5 گیگابایت) است. این پلن تا زمانی که از محدودیت‌ها عبور نکنید، دائمی است.
### مقایسه کلی:
- AWS برای استفاده‌های مختلف طی 12 ماه، مقدار بیشتری منابع رایگان ارائه می‌دهد، به‌خصوص اگر به سرور مجازی مثل EC2 نیاز دارید.
- Google Cloud اعتبار 300 دلاری رایگان را ارائه می‌دهد که به شما اجازه می‌دهد از هر سرویسی استفاده کنید. اما پلن رایگان همیشگی آن دارای محدودیت‌های بیشتری است.
- اگر به یک سرور مجازی نیاز دارید و بودجه کمتری دارید، Google Cloud با Compute Engine رایگان برای استفاده‌های کوچک می‌تواند بهتر باشد.
- از سوی دیگر، AWS تنوع بیشتری از خدمات رایگان برای 12 ماه اول ارائه می‌دهد که برای پروژه‌های گسترده‌تر مناسب است.
بنابراین، بسته به نیاز شما به منابع و نوع پروژه، یکی از این دو می‌تواند مناسب‌تر باشد.
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
### 1. AWS Free Tier:
AWS سه نوع پلن رایگان ارائه می‌دهد:
- 12 ماه رایگان: بسیاری از خدمات AWS مانند EC2 (750 ساعت استفاده از یک سرور کوچک در هر ماه)، S3 (تا 5 گیگابایت فضای ذخیره‌سازی) و RDS (دیتابیس مدیریت شده) برای 12 ماه اول رایگان هستند.
- پلن همیشه رایگان: خدماتی مثل AWS Lambda (1 میلیون درخواست در هر ماه) و S3 Glacier (10 گیگابایت ذخیره‌سازی) همیشه رایگان هستند.
- Free Trials: برخی از خدمات AWS برای مدت زمان محدودی (30 تا 60 روز) به صورت رایگان ارائه می‌شوند.
### 2. Google Cloud Free Tier:
Google Cloud هم دو نوع طرح رایگان دارد:
- 300 دلار اعتبار رایگان برای 90 روز: در این مدت می‌توانید از هر سرویس گوگل کلاد استفاده کنید.
- پلن همیشه رایگان: شامل سرویس‌هایی مثل Compute Engine (سرور مجازی کوچک با 1 گیگابایت رم و 30 گیگابایت هارد)، Google Cloud Functions (2 میلیون درخواست در هر ماه)، و Cloud Storage (تا 5 گیگابایت) است. این پلن تا زمانی که از محدودیت‌ها عبور نکنید، دائمی است.
### مقایسه کلی:
- AWS برای استفاده‌های مختلف طی 12 ماه، مقدار بیشتری منابع رایگان ارائه می‌دهد، به‌خصوص اگر به سرور مجازی مثل EC2 نیاز دارید.
- Google Cloud اعتبار 300 دلاری رایگان را ارائه می‌دهد که به شما اجازه می‌دهد از هر سرویسی استفاده کنید. اما پلن رایگان همیشگی آن دارای محدودیت‌های بیشتری است.
- اگر به یک سرور مجازی نیاز دارید و بودجه کمتری دارید، Google Cloud با Compute Engine رایگان برای استفاده‌های کوچک می‌تواند بهتر باشد.
- از سوی دیگر، AWS تنوع بیشتری از خدمات رایگان برای 12 ماه اول ارائه می‌دهد که برای پروژه‌های گسترده‌تر مناسب است.
بنابراین، بسته به نیاز شما به منابع و نوع پروژه، یکی از این دو می‌تواند مناسب‌تر باشد.
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
در Kubernetes، کلاستر (Cluster) و نیم‌اسپیس (Namespace) دو مفهوم اصلی هستند که هر کدام نقش متفاوتی در مدیریت و سازماندهی منابع دارند:
### 1. کلاستر (Cluster):
کلاستر در Kubernetes به مجموعه‌ای از نودها (nodes) گفته می‌شود که با هم کار می‌کنند تا منابع محاسباتی را فراهم کنند و اپلیکیشن‌ها را اجرا کنند. هر کلاستر Kubernetes شامل یک یا چند نود است که می‌تواند شامل نودهای اصلی (master node) و نودهای کارگر (worker node) باشد.
در کلاستر:
- نودهای کارگر پادها و سرویس‌های اپلیکیشن‌ها را اجرا می‌کنند.
- نود اصلی وظیفه مدیریت و هماهنگی منابع، مدیریت وضعیت پادها و سرویس‌ها، و فراهم کردن API Kubernetes را برعهده دارد.
کلاستر معمولاً به عنوان یک محیط جداگانه استفاده می‌شود و شامل تمام منابع محاسباتی و شبکه‌ای مورد نیاز برای اجرای برنامه‌های کانتینری است.
### 2. نیم‌اسپیس (Namespace):
نیم‌اسپیس‌ها به عنوان یک مکانیزم برای تقسیم منطقی یک کلاستر عمل می‌کنند. نیم‌اسپیس‌ها به شما اجازه می‌دهند که منابع و اپلیکیشن‌های مختلف را در یک کلاستر مدیریت و جداسازی کنید.
ویژگی‌های کلیدی نیم‌اسپیس:
- جداسازی منابع: هر نیم‌اسپیس یک محدوده جداگانه برای منابع مثل پادها، سرویس‌ها، و سایر آبجکت‌ها فراهم می‌کند. این کمک می‌کند که از برخورد منابع در یک کلاستر جلوگیری شود.
- مدیریت دسترسی‌ها: نیم‌اسپیس‌ها به شما امکان می‌دهند که با استفاده از RBAC (Role-Based Access Control) دسترسی‌ها را برای تیم‌ها و کاربران مختلف تعریف کنید.
- مدیریت بهتر در محیط‌های اشتراکی: در یک کلاستر بزرگ که چند تیم مختلف ممکن است در حال استفاده از منابع باشند، نیم‌اسپیس‌ها کمک می‌کنند که هر تیم منابع خود را به‌صورت مستقل مدیریت کند.
### تفاوت‌های کلیدی:
- کلاستر: یک کلاستر مجموعه‌ای از نودها است که زیرساخت محاسباتی را فراهم می‌کند و محیطی را برای اجرای پادها در Kubernetes مهیا می‌سازد. هر کلاستر می‌تواند شامل چندین نیم‌اسپیس باشد.
- نیم‌اسپیس: نیم‌اسپیس یک واحد سازمانی داخلی در کلاستر است که به جداسازی منابع و مدیریت آنها کمک می‌کند. نیم‌اسپیس‌ها منابع یک کلاستر را تقسیم‌بندی می‌کنند، اما خود کلاستر را تقسیم نمی‌کنند.
### مثال:
فرض کنید یک سازمان از یک کلاستر برای اجرای چندین اپلیکیشن استفاده می‌کند. برای جداسازی تیم‌های مختلف یا اپلیکیشن‌های مختلف در همان کلاستر، می‌توان از **نیم‌اسپیس**ها استفاده کرد تا هر تیم بتواند منابع خود را جدا از دیگران مدیریت کند. این باعث می‌شود که مدیریت اپلیکیشن‌ها ساده‌تر و مؤثرتر باشد.
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
### 1. کلاستر (Cluster):
کلاستر در Kubernetes به مجموعه‌ای از نودها (nodes) گفته می‌شود که با هم کار می‌کنند تا منابع محاسباتی را فراهم کنند و اپلیکیشن‌ها را اجرا کنند. هر کلاستر Kubernetes شامل یک یا چند نود است که می‌تواند شامل نودهای اصلی (master node) و نودهای کارگر (worker node) باشد.
در کلاستر:
- نودهای کارگر پادها و سرویس‌های اپلیکیشن‌ها را اجرا می‌کنند.
- نود اصلی وظیفه مدیریت و هماهنگی منابع، مدیریت وضعیت پادها و سرویس‌ها، و فراهم کردن API Kubernetes را برعهده دارد.
کلاستر معمولاً به عنوان یک محیط جداگانه استفاده می‌شود و شامل تمام منابع محاسباتی و شبکه‌ای مورد نیاز برای اجرای برنامه‌های کانتینری است.
### 2. نیم‌اسپیس (Namespace):
نیم‌اسپیس‌ها به عنوان یک مکانیزم برای تقسیم منطقی یک کلاستر عمل می‌کنند. نیم‌اسپیس‌ها به شما اجازه می‌دهند که منابع و اپلیکیشن‌های مختلف را در یک کلاستر مدیریت و جداسازی کنید.
ویژگی‌های کلیدی نیم‌اسپیس:
- جداسازی منابع: هر نیم‌اسپیس یک محدوده جداگانه برای منابع مثل پادها، سرویس‌ها، و سایر آبجکت‌ها فراهم می‌کند. این کمک می‌کند که از برخورد منابع در یک کلاستر جلوگیری شود.
- مدیریت دسترسی‌ها: نیم‌اسپیس‌ها به شما امکان می‌دهند که با استفاده از RBAC (Role-Based Access Control) دسترسی‌ها را برای تیم‌ها و کاربران مختلف تعریف کنید.
- مدیریت بهتر در محیط‌های اشتراکی: در یک کلاستر بزرگ که چند تیم مختلف ممکن است در حال استفاده از منابع باشند، نیم‌اسپیس‌ها کمک می‌کنند که هر تیم منابع خود را به‌صورت مستقل مدیریت کند.
### تفاوت‌های کلیدی:
- کلاستر: یک کلاستر مجموعه‌ای از نودها است که زیرساخت محاسباتی را فراهم می‌کند و محیطی را برای اجرای پادها در Kubernetes مهیا می‌سازد. هر کلاستر می‌تواند شامل چندین نیم‌اسپیس باشد.
- نیم‌اسپیس: نیم‌اسپیس یک واحد سازمانی داخلی در کلاستر است که به جداسازی منابع و مدیریت آنها کمک می‌کند. نیم‌اسپیس‌ها منابع یک کلاستر را تقسیم‌بندی می‌کنند، اما خود کلاستر را تقسیم نمی‌کنند.
### مثال:
فرض کنید یک سازمان از یک کلاستر برای اجرای چندین اپلیکیشن استفاده می‌کند. برای جداسازی تیم‌های مختلف یا اپلیکیشن‌های مختلف در همان کلاستر، می‌توان از **نیم‌اسپیس**ها استفاده کرد تا هر تیم بتواند منابع خود را جدا از دیگران مدیریت کند. این باعث می‌شود که مدیریت اپلیکیشن‌ها ساده‌تر و مؤثرتر باشد.
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
🔥2
✍️shahriyar bayatshahriyar bayat
معرفی buildkit در داکر
BuildKit یه سیستم ساخت (build system) جدید برای Docker هست که بهبودهای قابل توجهی رو نسبت به سیستم ساخت قبلی ارائه میده. این سیستم به‌طور پیش‌فرض از Docker 18.09 به بعد در دسترسه و میتونه به صورت اختیاری فعال بشه.
چرا باید از buildkit استفاده کنیم و بهش اهمیت بیشتری بدیم؟
BuildKit از کش‌های لایه‌ای پیشرفته و build های موازی پشتیبانی میکنه که زمان ساخت رو به‌طور قابل توجهی کاهش میده.
با استفاده از BuildKit میتونین image برای چندین پلتفرم مختلف به صورت همزمان بسازین.
BuildKit امکانات امنیتی بیشتری مثل مخفی کردن فایل‌های حساس در حین ساخت رو فراهم میکنه.
BuildKit میتونه بهینه‌سازی‌هایی رو انجام بده که اندازه image رو کاهش میده.
با استفاده از BuildKit میتونین از ویژگی‌های پیشرفته‌تر Dockerfile مثل RUN --mount=type=cache استفاده کنین.
مهمترین تفاوت های buildkit با سیستم سنتی docker build این موارد میتونه باشه:
BuildKit میتونه مراحل ساخت رو به صورت موازی اجرا کنه، در حالی که سیستم سنتی docker build مراحل رو به صورت متوالی اجرا میکنه. این ویژگی باعث میشه که زمان ساخت به طور قابل توجهی کاهش پیدا کنه.
برای مثال فرض کنید ۲ دستور apt update و npm install و پشت سرهم توی داکرفایل نوشتیم این دستورات به ترتیب بعد از کامل شدن دستور قبلی اجرا میشن که پروسه نصب و ساخت و خیلی طولانی میکنه و برای ما که تو ایران مشکل اینترنت و تحریم هم داریم مشکل بزرگتر هم هست. buildkit بصورت همزمان هر دو دستور و اجرا میکنه و سرعت ساخت image و بشدت کاهش میده (مثالش توی عکس هست)
BuildKit از کش‌های لایه‌ای هوشمندتری استفاده میکنه که باعث میشه تنها بخش‌هایی از ساخت که تغییر کرده‌اند دوباره ساخته بشن. این بهبود در مدیریت کش میتونه سرعت ساخت رو بیشتر کنه.
buildkit قابلیت های بیشتر دیگه ای هم داره که میتونین در موردش مطالعه کنید
امیدوارم این مطلب کاربردی باشه براتون
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
معرفی buildkit در داکر
BuildKit یه سیستم ساخت (build system) جدید برای Docker هست که بهبودهای قابل توجهی رو نسبت به سیستم ساخت قبلی ارائه میده. این سیستم به‌طور پیش‌فرض از Docker 18.09 به بعد در دسترسه و میتونه به صورت اختیاری فعال بشه.
چرا باید از buildkit استفاده کنیم و بهش اهمیت بیشتری بدیم؟
BuildKit از کش‌های لایه‌ای پیشرفته و build های موازی پشتیبانی میکنه که زمان ساخت رو به‌طور قابل توجهی کاهش میده.
با استفاده از BuildKit میتونین image برای چندین پلتفرم مختلف به صورت همزمان بسازین.
BuildKit امکانات امنیتی بیشتری مثل مخفی کردن فایل‌های حساس در حین ساخت رو فراهم میکنه.
BuildKit میتونه بهینه‌سازی‌هایی رو انجام بده که اندازه image رو کاهش میده.
با استفاده از BuildKit میتونین از ویژگی‌های پیشرفته‌تر Dockerfile مثل RUN --mount=type=cache استفاده کنین.
مهمترین تفاوت های buildkit با سیستم سنتی docker build این موارد میتونه باشه:
BuildKit میتونه مراحل ساخت رو به صورت موازی اجرا کنه، در حالی که سیستم سنتی docker build مراحل رو به صورت متوالی اجرا میکنه. این ویژگی باعث میشه که زمان ساخت به طور قابل توجهی کاهش پیدا کنه.
برای مثال فرض کنید ۲ دستور apt update و npm install و پشت سرهم توی داکرفایل نوشتیم این دستورات به ترتیب بعد از کامل شدن دستور قبلی اجرا میشن که پروسه نصب و ساخت و خیلی طولانی میکنه و برای ما که تو ایران مشکل اینترنت و تحریم هم داریم مشکل بزرگتر هم هست. buildkit بصورت همزمان هر دو دستور و اجرا میکنه و سرعت ساخت image و بشدت کاهش میده (مثالش توی عکس هست)
BuildKit از کش‌های لایه‌ای هوشمندتری استفاده میکنه که باعث میشه تنها بخش‌هایی از ساخت که تغییر کرده‌اند دوباره ساخته بشن. این بهبود در مدیریت کش میتونه سرعت ساخت رو بیشتر کنه.
buildkit قابلیت های بیشتر دیگه ای هم داره که میتونین در موردش مطالعه کنید
امیدوارم این مطلب کاربردی باشه براتون
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
👍1
🔵 عنوان مقاله
Docker Best Practices: Using Tags and Labels to Manage Docker Image Sprawl (4 minute read)
🟢 خلاصه مقاله:
متکی بودن صرفاً به تگ "آخرین" (latest) می‌تواند گمراه‌کننده باشد زیرا هیچ تضمینی وجود ندارد که نسخه‌ی جدیدترین به شمار رود. یک رویکرد بهتر برای مدیریت گسترش تصاویر داکر، استفاده از نسخه‌بندی معنایی (semantic versioning) با تگ‌ها و استفاده از برچسب‌ها (labels) برای ردیابی متادیتا تصویر است. این کار شفافیت و ثبات در شناسایی تصاویر داکر را تضمین می‌کند. بنابراین، به‌جای اعتماد کورکورانه به تگ "آخرین"، باید تگ‌هایی با نسخه‌های دقیق و برچسب‌ها را برای داده‌های توصیفی و وضعیت فعلی نرم‌افزار استفاده کنیم، تا درک دقیق‌تر و مدیریت بهتری بر تصاویر داکر خود داشته باشیم. این امر به ویژه در محیط‌های تولید که نیاز به پایداری و قابلیت اطمینان بالا دارد، حیاتی است.
🟣لینک مقاله:
https://www.docker.com/blog/docker-best-practices-using-tags-and-labels-to-manage-docker-image-sprawl/?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Docker Best Practices: Using Tags and Labels to Manage Docker Image Sprawl (4 minute read)
🟢 خلاصه مقاله:
متکی بودن صرفاً به تگ "آخرین" (latest) می‌تواند گمراه‌کننده باشد زیرا هیچ تضمینی وجود ندارد که نسخه‌ی جدیدترین به شمار رود. یک رویکرد بهتر برای مدیریت گسترش تصاویر داکر، استفاده از نسخه‌بندی معنایی (semantic versioning) با تگ‌ها و استفاده از برچسب‌ها (labels) برای ردیابی متادیتا تصویر است. این کار شفافیت و ثبات در شناسایی تصاویر داکر را تضمین می‌کند. بنابراین، به‌جای اعتماد کورکورانه به تگ "آخرین"، باید تگ‌هایی با نسخه‌های دقیق و برچسب‌ها را برای داده‌های توصیفی و وضعیت فعلی نرم‌افزار استفاده کنیم، تا درک دقیق‌تر و مدیریت بهتری بر تصاویر داکر خود داشته باشیم. این امر به ویژه در محیط‌های تولید که نیاز به پایداری و قابلیت اطمینان بالا دارد، حیاتی است.
🟣لینک مقاله:
https://www.docker.com/blog/docker-best-practices-using-tags-and-labels-to-manage-docker-image-sprawl/?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Docker
Docker Best Practices: Using Tags and Labels to Manage Docker Image Sprawl | Docker
Learn best practices for using tags and labels to manage image sprawl in Docker container workflows.
🔵 عنوان مقاله
What's New In Python 3.13 (1 minute read)
🟢 خلاصه مقاله:
مقاله‌ای که مورد بررسی قرار گرفته، به نقد و بررسی ویژگی‌های جدید ارائه شده در نسخه 3.13 زبان برنامه‌نویسی پایتون می‌پردازد. از جمله این ویژگی‌ها، معرفی یک مفسر تعاملی جدید، حالت آزمایشی رایگان بدون نیاز به thread (PEP 703)، و یک کامپایلر Just-In-Time (PEP 744) می‌باشد. همچنین، پیام‌های خطا با استفاده از رنگ در tracebacks بهبود یافته‌اند و تغییراتی در تابع locals() اعمال شده است. به‌روزرسانی همچنین شامل حذف APIهای منسوخ و بهبود پارامترهای نوع با مقادیر پیش‌فرض می‌باشد. برای اطلاعات جزئی‌تر و راهنمایی‌های مهاجرت، به مستندات رسمی پایتون و PEPهای مرتبط مراجعه شود.
🟣لینک مقاله:
https://docs.python.org/3.13/whatsnew/3.13.html?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
What's New In Python 3.13 (1 minute read)
🟢 خلاصه مقاله:
مقاله‌ای که مورد بررسی قرار گرفته، به نقد و بررسی ویژگی‌های جدید ارائه شده در نسخه 3.13 زبان برنامه‌نویسی پایتون می‌پردازد. از جمله این ویژگی‌ها، معرفی یک مفسر تعاملی جدید، حالت آزمایشی رایگان بدون نیاز به thread (PEP 703)، و یک کامپایلر Just-In-Time (PEP 744) می‌باشد. همچنین، پیام‌های خطا با استفاده از رنگ در tracebacks بهبود یافته‌اند و تغییراتی در تابع locals() اعمال شده است. به‌روزرسانی همچنین شامل حذف APIهای منسوخ و بهبود پارامترهای نوع با مقادیر پیش‌فرض می‌باشد. برای اطلاعات جزئی‌تر و راهنمایی‌های مهاجرت، به مستندات رسمی پایتون و PEPهای مرتبط مراجعه شود.
🟣لینک مقاله:
https://docs.python.org/3.13/whatsnew/3.13.html?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Python documentation
What’s New In Python 3.13
Editors, Adam Turner and Thomas Wouters,. This article explains the new features in Python 3.13, compared to 3.12. Python 3.13 was released on October 7, 2024. For full details, see the changelog. ...
✍️shahriyar bayatshahriyar bayat
آشنایی عمیق تر با دستور user تو داکر و best practice استفاده ازش
دستور USER. به شما اجازه میده مشخص کنید که یک کانتینر تحت چه کاربری اجرا بشه. این فیچر تو نسخه‌های اخیر داکر بیشتر مورد توجه قرار گرفته و میتونه تأثیر زیادی روی امنیت و عملکرد اپلیکیشن‌هاتون داشته باشه.
چرا دستور USER مهمه؟
1. امنیت بیشتر:
اجرای کانتینرها به عنوان کاربر root میتونه خطرناک باشه. اگر یه کانتینر آسیب ببینه، مهاجم میتونه به سیستم اصلی دسترسی پیدا کنه. با استفاده از دستور USER، میتونید تعیین کنید که کانتینر به عنوان یک کاربر غیر ریشه‌ای (non-root) اجرا بشه و این باعث میشه سطح دسترسی هکر محدود بشه.
2. جداسازی بهتر:
وقتی هر کانتینر به عنوان یه کاربر جداگانه اجرا بشه، میتونید به راحتی کنترل کنید که هر کانتینر به چه منابعی دسترسی داره. این باعث میشه جداسازی بهتری بین سرویس‌ها و اپلیکیشن‌ها داشته باشید.
نکات مهم
همیشه بهتره برای هر اپلیکیشن یا سرویس، کاربر جداگانه‌ای بسازید تا بتونید سطح دسترسی‌ها رو بهتر مدیریت کنید.
مطمئن بشید که کاربر جدید به فایل‌ها و دایرکتوری‌های مورد نیاز دسترسی داره. میتونید از دستورهای مثل chown برای تنظیم مالکیت استفاده کنید.
استفاده از Namespace و Group
حتما میدونید که Namespace ها تو داکر باعث میشن که فضای نام‌ها از هم جدا بشن و هر کانتینر نتونه به فضای نام کانتینرهای دیگه دسترسی داشته باشه. این قابلیت باعث افزایش امنیت و جداسازی بهتر سرویس‌ها میشه.
گروه‌ها هم کمک می‌کنن که چند کاربر به یک سری منابع مشترک دسترسی داشته باشن. مثلاً میتونید یه گروه بسازید و چند کاربر رو عضو اون گروه بکنید تا همه به یه سری دایرکتوری یا فایل دسترسی داشته باشن.
بریم ببینیم Best Practices برای استفاده از دستور USER چیه؟
هرگز کانتینرها رو به عنوان root اجرا نکنید مگر در موارد ضروری.
برای هر سرویس یا اپلیکیشن، یه کاربر و گروه جداگانه بسازید تا بتونید سطح دسترسی‌ها رو بهتر مدیریت کنید.
از Namespaceها برای جداسازی فضای نام‌ها استفاده کنید تا امنیت سیستم افزایش پیدا کنه.
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
آشنایی عمیق تر با دستور user تو داکر و best practice استفاده ازش
دستور USER. به شما اجازه میده مشخص کنید که یک کانتینر تحت چه کاربری اجرا بشه. این فیچر تو نسخه‌های اخیر داکر بیشتر مورد توجه قرار گرفته و میتونه تأثیر زیادی روی امنیت و عملکرد اپلیکیشن‌هاتون داشته باشه.
چرا دستور USER مهمه؟
1. امنیت بیشتر:
اجرای کانتینرها به عنوان کاربر root میتونه خطرناک باشه. اگر یه کانتینر آسیب ببینه، مهاجم میتونه به سیستم اصلی دسترسی پیدا کنه. با استفاده از دستور USER، میتونید تعیین کنید که کانتینر به عنوان یک کاربر غیر ریشه‌ای (non-root) اجرا بشه و این باعث میشه سطح دسترسی هکر محدود بشه.
2. جداسازی بهتر:
وقتی هر کانتینر به عنوان یه کاربر جداگانه اجرا بشه، میتونید به راحتی کنترل کنید که هر کانتینر به چه منابعی دسترسی داره. این باعث میشه جداسازی بهتری بین سرویس‌ها و اپلیکیشن‌ها داشته باشید.
نکات مهم
همیشه بهتره برای هر اپلیکیشن یا سرویس، کاربر جداگانه‌ای بسازید تا بتونید سطح دسترسی‌ها رو بهتر مدیریت کنید.
مطمئن بشید که کاربر جدید به فایل‌ها و دایرکتوری‌های مورد نیاز دسترسی داره. میتونید از دستورهای مثل chown برای تنظیم مالکیت استفاده کنید.
استفاده از Namespace و Group
حتما میدونید که Namespace ها تو داکر باعث میشن که فضای نام‌ها از هم جدا بشن و هر کانتینر نتونه به فضای نام کانتینرهای دیگه دسترسی داشته باشه. این قابلیت باعث افزایش امنیت و جداسازی بهتر سرویس‌ها میشه.
گروه‌ها هم کمک می‌کنن که چند کاربر به یک سری منابع مشترک دسترسی داشته باشن. مثلاً میتونید یه گروه بسازید و چند کاربر رو عضو اون گروه بکنید تا همه به یه سری دایرکتوری یا فایل دسترسی داشته باشن.
بریم ببینیم Best Practices برای استفاده از دستور USER چیه؟
هرگز کانتینرها رو به عنوان root اجرا نکنید مگر در موارد ضروری.
برای هر سرویس یا اپلیکیشن، یه کاربر و گروه جداگانه بسازید تا بتونید سطح دسترسی‌ها رو بهتر مدیریت کنید.
از Namespaceها برای جداسازی فضای نام‌ها استفاده کنید تا امنیت سیستم افزایش پیدا کنه.
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
👍1
Forwarded from Bardia & Erfan
🔵 عنوان مقاله
This Post Is Not About Python (5 minute read)
🟢 خلاصه مقاله:
مقاله بیان می‌کند که زبان برنامه‌نویسی پایتون نسبت به زبان‌هایی مانند سی، به ویژه در استفاده از قابلیت‌های پیچیده، کندتر است و در استفاده مؤثر از چند پردازنده مشکل دارد. با این حال، با توجه به سهولت استفاده از پایتون و سرعت سخت‌افزارهای مدرن، این زبان همچنان می‌تواند برای بسیاری از پروژه‌ها مفید باشد. مهندسان باید در انتخاب ابزار مناسب برای نیازهای خاص خود دقت کنند و بدون تعصب این انتخاب را انجام دهند تا از تصمیم‌گیری‌های نامناسب و شکست‌های پروژه اجتناب شود. این نوشته تاکید می‌کند که انتخاب هوشمندانه و بی‌طرف ابزارهای تکنولوڈیکی برای دستیابی به بهترین نتایج در پروژه‌ها ضروری است.
🟣لینک مقاله:
https://jerf.org/iri/post/2024/not_about_python/?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
This Post Is Not About Python (5 minute read)
🟢 خلاصه مقاله:
مقاله بیان می‌کند که زبان برنامه‌نویسی پایتون نسبت به زبان‌هایی مانند سی، به ویژه در استفاده از قابلیت‌های پیچیده، کندتر است و در استفاده مؤثر از چند پردازنده مشکل دارد. با این حال، با توجه به سهولت استفاده از پایتون و سرعت سخت‌افزارهای مدرن، این زبان همچنان می‌تواند برای بسیاری از پروژه‌ها مفید باشد. مهندسان باید در انتخاب ابزار مناسب برای نیازهای خاص خود دقت کنند و بدون تعصب این انتخاب را انجام دهند تا از تصمیم‌گیری‌های نامناسب و شکست‌های پروژه اجتناب شود. این نوشته تاکید می‌کند که انتخاب هوشمندانه و بی‌طرف ابزارهای تکنولوڈیکی برای دستیابی به بهترین نتایج در پروژه‌ها ضروری است.
🟣لینک مقاله:
https://jerf.org/iri/post/2024/not_about_python/?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
👍3
🔵 عنوان مقاله
Pulumi ESC and External Secrets Operator: The Perfect Solution for Today's Cloud-Native Secret Management (9 minute read)
🟢 خلاصه مقاله:
مقاله مورد بحث به بررسی و تحلیل Pulumi ESC و External Secrets Operator می‌پردازد که دو ابزار مهم در مدیریت امن داده‌های حساس در محیط‌های کلود نیتیو هستند. این ابزارها به‌طور خاص برای مدیریت و همگام‌سازی داده‌های حساس در سراسر خوشه‌های Kubernetes طراحی شده‌اند. پولومی ESC یک راهکار مدیریت رمز است که به کاربران امکان می‌دهد تا به آسانی رمزها و داده‌های حساس را به صورت امن در خوشه‌های مختلف مدیریت و پیکربندی کنند. از سوی دیگر، External Secrets Operator قابلیت‌های مدیریتی را فراهم می‌آورد که به واسطه آن امکان دسترسی و همگام‌سازی اطلاعات حساس بین محیط‌های مختلف به شکل امن و مطمئن تضمین می‌شود. استفاده از این دو ابزار در کنار هم به تیم‌های فناوری اطلاعات کمک می‌کند تا بتوانند به طور موثری از داده‌های حساس محافظت کرده و در عین حال انعطاف‌پذیری لازم را در محیط‌های کلود نیتیو حفظ کنند.
🟣لینک مقاله:
https://www.pulumi.com/blog/cloud-native-secret-management-with-pulumi-esc-and-external-secrets-operator/?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Pulumi ESC and External Secrets Operator: The Perfect Solution for Today's Cloud-Native Secret Management (9 minute read)
🟢 خلاصه مقاله:
مقاله مورد بحث به بررسی و تحلیل Pulumi ESC و External Secrets Operator می‌پردازد که دو ابزار مهم در مدیریت امن داده‌های حساس در محیط‌های کلود نیتیو هستند. این ابزارها به‌طور خاص برای مدیریت و همگام‌سازی داده‌های حساس در سراسر خوشه‌های Kubernetes طراحی شده‌اند. پولومی ESC یک راهکار مدیریت رمز است که به کاربران امکان می‌دهد تا به آسانی رمزها و داده‌های حساس را به صورت امن در خوشه‌های مختلف مدیریت و پیکربندی کنند. از سوی دیگر، External Secrets Operator قابلیت‌های مدیریتی را فراهم می‌آورد که به واسطه آن امکان دسترسی و همگام‌سازی اطلاعات حساس بین محیط‌های مختلف به شکل امن و مطمئن تضمین می‌شود. استفاده از این دو ابزار در کنار هم به تیم‌های فناوری اطلاعات کمک می‌کند تا بتوانند به طور موثری از داده‌های حساس محافظت کرده و در عین حال انعطاف‌پذیری لازم را در محیط‌های کلود نیتیو حفظ کنند.
🟣لینک مقاله:
https://www.pulumi.com/blog/cloud-native-secret-management-with-pulumi-esc-and-external-secrets-operator/?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
pulumi
Pulumi ESC and External Secrets Operator: The Perfect Solution for Today's Cloud-Native Secret Management
Learn how to manage Kubernetes secrets with Pulumi ESC and External Secrets Operator
🔵 عنوان مقاله
Unprotected container registries (4 minute read)
🟢 خلاصه مقاله:
مخازن کانتینر غیرمحافظت‌شده خطر قابل‌توجهی برای امنیت سایبری به‌شمار می‌روند و بیش از 10,000 مخزن هنوز امن نشده‌اند که این امر داده‌های حساس را در معرض دسترسی حمله‌کنندگان قرار می‌دهد. برای مقابله با این مسئله، سازمان‌ها باید اقدامات امنیتی دقیقی را اجرا کنند که شامل احراز هویت و بازرسی‌های منظم می‌باشد. همچنین، جامعه باید بر آگاهی و به‌کارگیری بهترین شیوه‌ها برای حفاظت از این منابع ضروری تمرکز کند. این اقدامات می‌توانند به کاهش خطر نقض داده‌ها و حملات سایبری کمک کنند و اطمینان از امنیت داده‌ها و فعالیت‌های مرتبط با مخازن کانتینر را بهبود بخشند.
🟣لینک مقاله:
https://dreher.in/blog/unprotected-container-registries?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Unprotected container registries (4 minute read)
🟢 خلاصه مقاله:
مخازن کانتینر غیرمحافظت‌شده خطر قابل‌توجهی برای امنیت سایبری به‌شمار می‌روند و بیش از 10,000 مخزن هنوز امن نشده‌اند که این امر داده‌های حساس را در معرض دسترسی حمله‌کنندگان قرار می‌دهد. برای مقابله با این مسئله، سازمان‌ها باید اقدامات امنیتی دقیقی را اجرا کنند که شامل احراز هویت و بازرسی‌های منظم می‌باشد. همچنین، جامعه باید بر آگاهی و به‌کارگیری بهترین شیوه‌ها برای حفاظت از این منابع ضروری تمرکز کند. این اقدامات می‌توانند به کاهش خطر نقض داده‌ها و حملات سایبری کمک کنند و اطمینان از امنیت داده‌ها و فعالیت‌های مرتبط با مخازن کانتینر را بهبود بخشند.
🟣لینک مقاله:
https://dreher.in/blog/unprotected-container-registries?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
dreher.in
dreher.in - eXperte digitaler Sicherheit / Unprotected container registries
Get the best in IT security with advanced penetration testing and attack surface management from our team of experts. Our solutions protect your business from cyber threats and data breaches, ensuring your customers' data is safe and secure.
🔵 عنوان مقاله
Migrating in-place from PostgreSQL to MySQL (8 minute read)
🟢 خلاصه مقاله:
در یک پروژه مهاجرت پیچیده، Yelp با موفقیت خدمات رزرو خود را از یک پایگاه داده PostgreSQL به یک پایگاه داده استاندارد MySQL متعلق به Yelp منتقل کرد. این فرآیند با چالش‌های فنی فراوانی همراه بود، اما Yelp توانست بدون وقفه در خدمات به مشتریان رستوران‌ها، این انتقال را انجام دهد. این انتقال نه تنها به بهبود عملکرد خدمات کمک کرد، بلکه پشتیبانی بهینه‌تری را نیز به ارمغان آورد. این تغییر پایگاه داده به Yelp اجازه داد تا از مزایای متعددی برخوردار شود و در نتیجه، خدمات با کیفیت‌تری را به کاربران نهایی ارائه دهد.
🟣لینک مقاله:
https://engineeringblog.yelp.com/2024/10/migrating-from-postgres-to-mysql.html?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Migrating in-place from PostgreSQL to MySQL (8 minute read)
🟢 خلاصه مقاله:
در یک پروژه مهاجرت پیچیده، Yelp با موفقیت خدمات رزرو خود را از یک پایگاه داده PostgreSQL به یک پایگاه داده استاندارد MySQL متعلق به Yelp منتقل کرد. این فرآیند با چالش‌های فنی فراوانی همراه بود، اما Yelp توانست بدون وقفه در خدمات به مشتریان رستوران‌ها، این انتقال را انجام دهد. این انتقال نه تنها به بهبود عملکرد خدمات کمک کرد، بلکه پشتیبانی بهینه‌تری را نیز به ارمغان آورد. این تغییر پایگاه داده به Yelp اجازه داد تا از مزایای متعددی برخوردار شود و در نتیجه، خدمات با کیفیت‌تری را به کاربران نهایی ارائه دهد.
🟣لینک مقاله:
https://engineeringblog.yelp.com/2024/10/migrating-from-postgres-to-mysql.html?utm_source=tldrdevops
➖➖➖➖➖➖➖➖
👑 @DevOps_Labdon
Yelp
Migrating in-place from PostgreSQL to MySQL
Migrating in-place from PostgreSQL to MySQL Alex Toumazis, Software Engineer Oct 7, 2024 The Yelp Reservations service (yelp_res) is the service that powers reservations on Yelp. It was acquired along...
🔥1