Byteforge / بایــت فورج 🛸 – Telegram
Byteforge / بایــت فورج 🛸
1.72K subscribers
374 photos
119 videos
81 files
354 links
DevOps & DevSecOps
Clouds

🐧🔥 Unique content

Admin: @heman_sadeghii
Download Telegram
Byteforge / بایــت فورج 🛸
یه پست خفن در مورد argocd داریم که به ساده ترین شکل توضیح دادم این ابزار چیکار میکنه
«چطور ArgoCD تضمین میکنه Kubernetes همیشه با Git هماهنگ بمونه»

فرض کن یه رستوران بزرگ داری تو به عنوان مدیر، یه دفتر داری که توش دقیق نوشتی هر غذا چطوری باید درست بشه
چه مواد اولیه‌ای داره، چند تا آشپز لازمه، دمای فر چقدره، و حتی چند تا غذا هم‌زمان باید آماده بشن.
اون دفتر در دنیای نرم‌افزار، همون مخزن Gitه. یعنی جایی که «دستور اصلی کار» نوشته شده.

حالا توی آشپزخونه (که در دنیای ما همون Kubernetesه) چند تا آشپز مشغول کارن.
قراره همه طبق دستور دفتر کار کنن، ولی خب، معمولاً یکی یه تغییری میده!
یکی میگه «بیاین یه کم فلفل بیشتر بریزیم»،
یکی تصمیم میگیره دمای فر رو زیاد کنه که کار زودتر تموم شه،
یا یکی برای تست یه دستور جدید، خودش دستی یه چیز رو عوض میکنه.

اینجا دقیقاً همون اتفاقیه که توی سرورهای واقعی می‌افته:

کسی ممکنه بره یه Deployment رو مستقیم ادیت کنه،
تعداد replicaها رو زیاد کنه،
یا نسخه‌ی برنامه رو دستی عوض کنه.
در نتیجه، چیزی که واقعاً روی سرور در حال اجراست با اون چیزی که در Git نوشته شده فرق داره.


اینجاست که ArgoCD وارد ماجرا میشه.
‏ArgoCD توی این مثال نقش سرآشپز ارشد و منظم رستوران رو داره.
اون دفتر دستور پخت (Git) رو همیشه دستشه و مدام بین آشپزها می‌چرخه تا مطمئن بشه همه دقیق طبق دستور عمل میکنن.

هر چند دقیقه یه بار میره سر میز کار آشپزها (یعنی سراغ Kubernetes) و نگاه میکنه ببینه همه‌چیز با دفتر یکی هست یا نه.
اگه ببینه دستور پخت تغییر کرده، دو حالت داره:

یا فقط خبر میده که «این غذا با دفتر یکی نیست» (که بهش می‌گن manual sync)

یا خودش بدون حرف اضافه، دستور درست رو دوباره اعمال میکنه (این میشه auto-sync)

از دید فنی، ArgoCD یه GitOps Controllerـه.

یعنی چی؟ یعنی اون دائم داره وضعیت فعلی کلاستر Kubernetes رو با وضعیت تعریف‌شده در Git مقایسه میکنه.
به Git میگه “تو منبع حقیقتی (source of truth)”،
و هر چی اونجا تغییر کنه (مثلاً فایل YAML جدید یا یه commit تازه)، ArgoCD اون تغییر رو میفهمه، تفاوتش رو حساب میکنه و بعد تغییرات رو روی کلاستر اعمال میکنه.


پس دیگه کسی نباید مستقیم بره چیزی رو روی سرور تغییر بده.
هر کاری بخوای بکنی، باید از Git انجامش بدی.
‏ArgoCD خودش بقیه مسیر رو میره، Deploymentها رو update میکنه، نسخه‌ها رو sync میکنه، و حتی اگه کسی چیزی رو اشتباه عوض کنه، خودش برش میگردونه به حالت درست.

خلاصه‌اش:
‏Git شده دفتر دستور پخت رسمی.
‏Kubernetes شده آشپزخونه‌ای که غذاها اونجا درست میشن.
و ‏ArgoCD شده سرآشپز وسواسی که نمی‌ذاره هیچ‌کس از دستور تخطی کنه.


به زبان خودمونی، ArgoCD تضمین میکنه اون چیزی که واقعاً روی سرور در حال اجراست، دقیقاً همون چیزیه که تو Git گفتی باید باشه.
نه کمتر، نه بیشتر.



#DevOps
#argocd
#cluster
#kubernetes
#byteforge
@byteforge_chan 🛸
👌3🏆1
اگه چشمه آب و ‏کپسول اکسیژن و موتور برق و پدافند هوایی و کار و پول و ماشین داشته باشی، ایران بهترین جا برای زندگیه
🤷🏻‍♂️🤷🏻‍♂️
استارلینک فراموش نشه
🫡6😁1
پیشنهاد دوستانه


حدود یه ساله تقریبا روی یه پروداکت( sass) داریم کار میکنیم که تمام زیر ساختش رو توسعه دادیم از صفر
بعضی جاها انقدر توی جزییات و فلوی فیچر ریز میشدیم و به نوعی کمالگرایی میکردیم که بعضی جاها بدهی فنی میساخت
و بعضی جاها درک عجیب و غریبی از ساخت فیچر میداد عملا بعضی فیچر هارو انقد کمالگرایی کردیم که هیچکدوم از پلتفرم های همکار و رقیب حتی توی مواردی به خودشون جرعت ندادن که نزدیک ساخت همچین فیچری بشن
ما این فیچر رو پیاده کردیم که هیچ اومدیم انقد ریز شدیم داخلش و انقد سناریو ساختیم که هرنیازی رو پاسخ میده که هیچ
اضافه بر سازمانم پاسخگو هست طبق معماری و الگوریتیمی که نوشتیم
این از جهاتی خوبه و از جهاتی بد
میپرسید چرا ؟
به دو دلیل
دلیل اول اینکه شما باید ب روند توسعه و تایم پروژه دقت بکنی که انقد کمالگرایی میکنی برای توسعه و ساخت واقعا لازمه ؟
دوم اینکه مخاظب هدفت اصلا میتونه از این فیچر استفاده بکنه بخاطر اینکه انقدر داخل جزیییات ورود کردی و مقداری پیچیده شده
از یه طرفی هم خوبه چرا ؟
چون انقد سناریو ها مختلف بر میخورید که دید خیلی خوبی برای توسعه و نگهداری کد بیس پروژه بهتون میده هم اینکه بسیار تجربه های ارزشمندی توی ساخت و توسعه پروژه های با پیچیدگی فنیه
🫡5👍1🔥1🏆1
GIVE ME A REASON
NF
جمعه رو با nf سر کنید ❤️
❤‍🔥3
Forwarded from Linuxor ?
امنیتی ها همیشه برای امن کردن می‌آن و تک تک سوراخ هارو می‌بندن بعد یه مدت که می‌گذره تازه میفهمن این سوراخ ها تمومی نداره و در نتیجه همیشه قضیه به این ختم می‌شه که یه دیوار دور اون چیز بکشن که بهش می‌گن isolation، همه حتی شرکت های بزرگ هم به این نتیجه رسیدن که isolation خیلی بهتر از درگیری جز به جز با مشکلاته، دقیقا مثل زندگی گاهی اوقات فقط isolation می‌تونه کمکمون کنه، درواقع با محیط نمیشه جنگید باید خودمون رو امن کنیم.


@Linuxor
🔥3😐1💊1
🚨 خبر فوری: اختلال سراسری اینترنت شروع شد

طبق گزارش‌های رسمی، از چند دقیقه پیش شبکه اینترنت بین‌الملل در ایران دچار مشکل شده و در بخش‌هایی از کشور عملاً قطع شده.

منبع خبر: اختلال درحال گسترش هست و احتمال ادامه‌دار بودن این وضعیت بسیار زیاده.
👍3😐1
کلادفلر
کلادفولر
🗿6
Forwarded from مگاهرتز (Mohammad Zarchi)
چشم یک دنیا به دستان بچه‌های کلودفلره
🤝9
داشتم ریپو های trend رو میدیدم
احتمالا خیلی زیاد میشنوید که ورکفلو های n8n
بازارش داغه و بحث زیاد میشه در موردش
این ریپو اومده و تعداد زیادی ورکفلو آماده رو جمع آوری کرده و اینجا گذاشته که بسته به نوع نیازتون میتونید استفاده کنید


https://github.com/Zie619/n8n-workflows



#n8n
#DevOps
#byteforge
@byteforge_chan 🛸
1🔥1
شبکه در Kubernetes پیچیده اما قابل فهم! یه خلاصه‌ی ساده

مقاله در کل داره درباره یه مشکل اصلی در Kubernetes حرف میزنه: پیچیدگی شبکه‌.

به‌طور دقیق مشکل اینه :
وقتی کلی پاد روی چند نود داری اینکه اینا چطور همدیگه رو پیدا کنن و حرف بزنن کار ساده‌ای نیست.


هر پاد باید IP داشته باشه، مسیرها درست باشه، سرویس‌ها ترافیک رو درست هدایت کنن، و DNS همیشه بروز باشه.

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

شبکه Kubernetes برخلاف Docker ساده نیست و برای همین نیاز به CNI، kube-proxy، Service Discovery و NetworkPolicy هست.

پس خلاصه بگم🤷
مقاله مشکل پیچیدگی ارتباطات داخل کلاستر Kubernetes رو توضیح میده و نشون میده این سیستم چطور شبکه‌سازی رو مدیریت میکنه تا پادها بتونن درست با هم و با بیرون ارتباط بگیرن.

لینک مقاله
https://www.freecodecamp.org/news/kubernetes-networking-tutorial-for-developers


#DevOps
#kubernetes
#byteforge
@byteforge_chan 🛸
🔥411
تعدادی سرور مجازی موجود دارم برای فروش
خودم استفاده نمیکنم
لوکیشن های
france
usa
uk
germany
poland
canada
2gb ram
3core
ترافیک نامحدود

دیتاسنتر ovh
قیمت پایه :300
❤‍🔥3👍2
🔰 18 Common Ports Worth Knowing



#DevOps
#network
#byteforge
@byteforge_chan 🛸
👌31
رفقا سلام روزتون بخیر باشه
چن مدت پیش ترجمه ی کتابی رو استارت زدیم
ترجمه ش رو ب لطف یکی از دوستان که مشارکت خوبی داشتن تموم کردیم و ریپو رو داخل گیتهاب گذاشتیم میتونید استفاده کنید

ترجمه کتاب :
the linux command line
اثر ویلیام شاتس William Shotts
بعد خوندنش درک خوبی از کامند های لینوکسی دارید به نسبت و یجورایی bash رو هم یاد میگیرید .

یه استار ساده و نشر دادنش کمک میکنه انگیزه بیشتری داشته باشیم برای انجام پروژه های رایگان و اوپن سورس


https://github.com/hemansadeghi/TLCL-Persian.git
1❤‍🔥121🔥1
Byteforge / بایــت فورج 🛸 pinned «رفقا سلام روزتون بخیر باشه چن مدت پیش ترجمه ی کتابی رو استارت زدیم ترجمه ش رو ب لطف یکی از دوستان که مشارکت خوبی داشتن تموم کردیم و ریپو رو داخل گیتهاب گذاشتیم میتونید استفاده کنید ترجمه کتاب : the linux command line اثر ویلیام شاتس William Shotts بعد…»
در اغلب پروژه‌های مبتنی بر PostgreSQL، ضعف اصلی نه در خود دیتابیس، بلکه در بکاپ‌گیری نامنظم، دستی و بدون مانیتورینگ دیده میشه.

یک خطای انسانی، یک اسکریپت ناقص یا یک اختلال دیسک برای نابودی داده کافیه

اینجا Postgresus به‌عنوان یک راهکار بکاپ خودکار و self-hosted وارد میشه
Postgresus داخل زیرساخت پروژه اجرا خواهد شد و بدون وابستگی به SaaS، وظیفه زمان‌بندی، اجرا، نگهداری و گزارش بکاپ را برعهده خواهد گرفت.

قابلیت‌های فنی مهم:

اجرای بکاپ بر پایه pg_dump با امکان تعریف چندین Job مستقل
زمان‌بندی دقیق از سطح دقیقه تا هفتگی
تعریف چند مقصد ذخیره‌سازی به‌صورت هم‌زمان


شامل:

local filesystem
‏S3-compatible storage
مسیرهای network storage
نگهداری نسخه‌های قدیمی بر اساس سیاست Retention
داشبورد تحت وب برای مشاهده وضعیت Jobها
ارسال نوتیفیکیشن پس از هر Job موفق یا ناموفق
امکان تعریف چند PostgreSQL instance داخل یک پنل واحد

در سناریوی عملیاتی، معماری به این شکل پیاده‌سازی خواهد شد:
یک Container مرکزی Postgresus
اتصال امن به دیتابیس‌های Production یا Staging
ذخیره بکاپ روی Volume مجزا یا Object Storage
مانیتورینگ خروجی Jobها از طریق اعلان
راه‌اندازی پایه بر اساس Docker انجام خواهد شد و نیاز به نصب مستقیم ابزار روی هاست دیتابیس وجود نخواهد داشت.
این موضوع ریسک دسترسی مستقیم به سرور اصلی دیتابیس را نیز کاهش خواهد داد.


مزیت جدی نسبت به سرویس‌های ابری:


داده از زیرساخت پروژه خارج نخواهد شد
وابستگی به سرویس ثالث ایجاد نخواهد شد
هزینه اشتراک ماهانه صفر باقی خواهد ماند
امکان کنترل کامل سطح دسترسی و امنیت وجود خواهد داشت
سورس پروژه روی GitHub به‌صورت عمومی منتشر شده:
https://github.com/RostislavDugin/postgresus

نکته فنی واقع‌بینانه :
برای دیتابیس‌های بسیار سنگین با نیاز به WAL Archiving، Point-in-Time Recovery و بکاپ تفاضلی، ابزارهایی مانند pgBackRest انتخاب منطقی‌تری خواهند بود.
اما در اغلب پروژه‌های واقعی، Postgresus پوشش کامل نیاز بکاپ اتومات را فراهم خواهد کرد.



#DevOps
#database
#tools
#postgres
#byteforge
@byteforge_chan 🛸
👏6