خب خب خب، Volume توی داکر🐳
‏Volume ها توی داکر یه راه استاندارد برای ذخیره ی داده ها به شکل پایدار(persistent data) هستن. یعنی وقتی که یه کانتینر خاموش یا پاک میشه، داده هایی که داخل Volume ذخیره شده باشن از بین نمیرن و دوباره قابل استفاده هستن. که این یعنی Volume ها جدا از لایه ی فایل سیستم کانتینر عمل میکنن و توی /var/lib/docker/volumes/ نگهداری میشن. کاربردشون معمولا برای دیتابیس ها، فایل های کاربر، یا هر داده ای که نباید با حذف کانتینر از دست بره هست.

چطور ازشون استفاده کنیم؟🤔
میتونید با استفاده از دستور زیر Volumeها رو مدیریت کنید.

docker volume ls            
# List all existing volumes
docker volume create NAME   
# Create a new volume
docker volume inspect NAME  
# View detailed information about a volume
docker volume rm NAME       
# Remove a specific volume
docker volume prune         
# Remove all unused volumes

نکته⚠️: اگه یه Volume هنوز به یه کانتینر متصل باشه، نمیشه مستقیم با rm حذفش کرد.

بعد از ساختن Volume های مورد نظرتون میتونید به این شکل وصلشون کنید به کانتینر هاتون:

docker run -v my_volume:/app/data my_image

یا توی فایل compose:

services:
  app:
    image: my_image
    container_name: my_container
    volumes:
      - my_volume:/app/data

volumes:
  my_volume:

خب همونطور که دیدین، اسم Volume رو سمت چپ دو نقطه و مسیری که میخوایم توی کانتینر بهش وصل بشیم رو سمت راست میذاریم.
با اینکار هر تغییری که توی مسیر /app/data/ توی فایل سیستم کانتینر رخ بده توی Volume هم ذخیره میشه و حتی با خاموش شدن کانتینر هم در دسترس و قابل استفاده هست.

یه نکته ی مهم⚠️
احتمالا توی بعضی جاها دیده باشین که از سینتکس زیر استفاده میشه:

services:
  app:
    image: my_image
    container_name: my_container
    volumes:
      - .:/app/data

توی این روش سمت راست دونقطه به جای اسم Volume، مسیر فعلی توی سیستم قرار داده شده. توی این روش اصلا از Volume استفاده نمیشه و اسمش Bind Mount هست. درواقع اگه سمت راست دو نقطه به جای اسم Volume یه مسیر توی فایل سیستمتون رو بنویسید، Bind Mount اتفاق میوفته.
اینجا به جای اینکه یه Volume رو به فایل سیستم کانتینر وصل کرده باشیم، پوشه فعلی از فایل سیستم اصلی خودمون رو به فایل سیستم کانتینر وصل کردیم. این کار باعث بروز یه سری مشکلات میشه:

1️⃣ اگه اطلاعات توی کانتینر از دست برن توی فایل سیستم اصلی هم از دست میرن

یعنی اگه شما پروژه رو توی کانتینر حذف کنید، از روی سیستم خودتون هم حذف میشه. درواقع هر تغییری که توی کانتینر ایجاد کنید توی فایل سیستم اصلیتون هم ایجاد میشه.

2️⃣ عدم تطابق نسخه ی فایل ها

وقتی چند تا کانتینر همزمان یه مسیر رو Bind کردن، ممکنه فایل ها تصادفی توسط یکی از کانتینر ها تغییر کنه و هماهنگی بین فایل های پروژه به هم بریزه و باعث خرابی بشه.

3️⃣ ریسک های امنیتی

اگه داخل کانتینر دسترسی root باشه و به پوشه های حساسی Bind Mount شده باشه، کانتینر میتونه مستقیما به فایل های سیستمی آسیب بزنه.

4️⃣ انتقال ناخواسته ی فایل های حساس

اگه اشتباهی کل home/ یا / رو mount کنید داخل کانتینر، ممکنه فایل های حساس(مثل SSH Keyها، توکن ها، رمزها و...) هم توی محیط کانتینر قابل دسترس باشه.

جمع بندی✍️
‏Volume ها بشدت کاربردی هستن و میتونن برنامه نویس و کد رو نجات بدن. فقط باید دقت کنید که مسیر درستی رو به Volume بدین.
همچنین Bind Mount هم میتونه توی فاز توسعه کاربردی باشه. چون خیلی راحت میشه تغییرات توی کد رو روی کانتینر مشاهده و بررسی کرد ولی برای محیط پروداکشن خیلی خطرناک هستن و میتونن کلا محصول شمارو خراب کنن.

#️⃣ #programming #devops

➖➖➖➖➖➖➖➖➖➖

🥷🏻 CHANNEL | GROUP

جهت فان:
مصاحبه با یک DevOps engineer سنیور!

https://youtu.be/rXPpkzdS-q4?si=yB9totHR9pDmOk27

💠آلرت برای ترمینال💠

با استفاده از Telert می‌تونین برای دستورهای ترمینالی (لوکال یا سرور) آلرت‌ بذارین.

تلرت می‌تونه از راه‌های زیر به شما نوتیفیکیشن بده و شما رو از وضعیت دستور یا جاب آگاه کنه.

Telegram, Microsoft Teams, Slack, Discord
SMTP email notifications
Local Notifications: Desktop notifications, Audio alerts
Custom Integrations: HTTP endpoints for any service

برای مثال:
telert run npm build

خروجی دستور به‌عنوان آلرت:

find . -name "*.log" | telert "Log files found!"

مانیتورینگ یک فایل:

telert monitor log --name "postgres" --file "/var/log/postgresql/postgresql-15-main.log" --pattern "ERROR|FATAL"

مانیتورینگ مصرف رم بالا
telert monitor process --command-pattern "ps aux | grep postgres" --memory-threshold 2G

راه‌اندازی:

python3 -m venv telert
source telert/bin/activate
telert init

از اینجا به بعد برنامه یا پروتوکل آلرت رو انتخاب کنید و توکن‌های مورد نیاز رو بهش بدین. برای نمونه گزینه اول که تلگرامه یک توکن از botfather و یک chatid می‌خواد.

ابزار کاربردی و راحتیه و به‌سادگی روی سرور یا سیستم لوکالتون نصب می‌شه.

👉🔗 Telert

#devops
#معرفی #دواپس

🔵 عنوان مقاله
explains more, including why this matters.

🟢 خلاصه مقاله:
آخرین شماره Golang Weekly مقاله‌ای دارد که یک موضوع به‌روز در اکوسیستم Go را با زمینه‌سازی روشن و کاربردی شرح می‌دهد: چرا اکنون مهم است، چه مزایا و ملاحظاتی دارد و چه بده‌بستان‌هایی پیشِ‌روست. با توضیح‌های فشرده و مثال‌های قابل اتکا، الگوهای مناسب تولید، خطاهای رایج و مسیرهای مهاجرت برای سرویس‌ها و کتابخانه‌ها را نشان می‌دهد. همچنین به پیامدهای معمول چنین تغییراتی بر modules، مدیریت وابستگی، CI، راهبرد تست، بنچ‌مارک و پروفایلینگ می‌پردازد و راهکارهایی برای کاهش ریسک و سازگاری پیشنهاد می‌کند. در پایان، اثر آن بر جامعه و تیم‌ها را جمع‌بندی کرده و منابع تکمیلی برای مطالعه بیش‌تر معرفی می‌کند؛ نکاتی عملی، چه برای بک‌اند‌های پُرترافیک و چه برای CLIهای کوچک.

#Go #Golang #GolangWeekly #SoftwareEngineering #Backend #DevOps #Performance #Concurrency

🟣لینک مقاله:
https://golangweekly.com/link/174442/web

➖➖➖➖➖➖➖➖
👑 @gopher_academy

🔵 عنوان مقاله
koanf 2.3: Read Configuration with Multiple Sources and Formats

🟢 خلاصه مقاله:
اkoanf 2.3 ابزاری برای خواندن و ترکیب پیکربندی از چند منبع و چند فرمت است؛ از JSON، TOML و YAML تا متغیرهای محیطی، command line، فایل‌های محلی و سرویس‌های ابری مانند S3. شما می‌توانید این منابع را لایه‌بندی کنید، قواعد تقدم و ادغام تعیین کنید و بدین‌ترتیب رفتار پیکربندی را در محیط‌های مختلف کنترل کنید. این نسخه به‌عنوان جایگزینی «سبک‌تر» برای Viper معرفی می‌شود و با تکیه بر سادگی، وابستگی‌های کمتر و API جمع‌وجور، ادغام و نگه‌داری را آسان‌تر می‌کند.

#koanf #Configuration #Viper #JSON #YAML #TOML #S3 #DevOps

🟣لینک مقاله:
https://golangweekly.com/link/174428/web

➖➖➖➖➖➖➖➖
👑 @gopher_academy

🔵 عنوان مقاله
Why I Ditched Docker for Podman (And You Should Too)

🟢 خلاصه مقاله:
مهاجرت از Docker به Podman برای من بیشتر یک انتخاب عملی بود تا بحث سلیقه؛ به‌ویژه در جریان‌های کاری مرتبط با Go که در Golang Weekly هم زیاد دیده می‌شود. دلیل اصلی، معماری ساده‌تر و امن‌تر Podman است: بدون daemon و با اجرای rootless به‌صورت پیش‌فرض، پس سطح حمله و دردسرهای دسترسی کاهش می‌یابد و سرویس پرامتیازِ دائمی لازم نیست. مهاجرت هم کم‌اصطکاک است؛ چون Podman با CLI و فرمت OCI سازگار است و دستورات رایج مثل podman build/run عملاً جایگزین مستقیم می‌شوند. برای Compose، ابزار Podman Compose و برای رابط گرافیکی، Podman Desktop وجود دارد؛ روی macOS و Windows هم podman machine تجربه‌ای سبک و قابل‌اتکا می‌دهد. ادغام بومی با systemd، مدیریت لاگ‌ها و قابلیت‌هایی مثل pods و podman generate kube، راه را برای استفاده در CI/CD و حتی انتقال به Kubernetes هموار می‌کند. در پروژه‌های Go، ساخت چندمرحله‌ای، ایمیج‌های کم‌حجم، و mountهای rootless بدون مشکل دسترسی، چرخه توسعه و تست را سریع و قابل‌اعتماد می‌کند. هرچند تفاوت‌هایی مثل مسیر socket و جزئیات volumes نسبت به Docker وجود دارد، اما راهکارهای روشن و مستندی برایشان هست. نتیجه: اگر Docker جواب‌گو است، خوب؛ اما Podman در اکثر سناریوهای روزمره توسعه و CI تجربه‌ای امن‌تر، ساده‌تر و سازگار ارائه می‌دهد.

#Podman #Docker #Containers #DevOps #Go #GolangWeekly #Kubernetes #Security

🟣لینک مقاله:
https://golangweekly.com/link/174075/web

➖➖➖➖➖➖➖➖
👑 @gopher_academy

🔵 عنوان مقاله
Kubernetes CPU Limits and Go

🟢 خلاصه مقاله:
به‌روزرسانی این مقاله توضیح می‌دهد که چرا runtime زبان Go به‌طور پیش‌فرض از محدودیت‌های CPU در Kubernetes خبر ندارد و چگونه همین موضوع می‌تواند به oversubscription و در نتیجه throttling و جهش‌های تاخیری منجر شود. راه‌حل عملی، هم‌راستاکردن GOMAXPROCS با سهم واقعی CPU کانتینر (براساس cgroups) است؛ یا با تنظیم متغیر محیطی GOMAXPROCS یا با استفاده از کتابخانه go.uber.org/automaxprocs تا runtime با ظرفیت واقعی زمان‌بندی کند. از نظر عملیاتی، برای سرویس‌های حساس به تاخیر بهتر است از limit سخت CPU پرهیز کرده و به request به‌همراه HPA اتکا کنید؛ در صورت اجبار به limit، سقف را طوری بگذارید که throttling حداقلی باشد و در صورت نیاز از CPU pinning و QoS مناسب بهره بگیرید. ارزیابی این تنظیمات با سنجه‌هایی مانند container_cpu_cfs_throttled_seconds_total و توزیع تاخیر و نیز متریک‌های runtime در Go، تصویر دقیقی از تاثیر بهینه‌سازی‌ها ارائه می‌کند.

#Kubernetes #Go #GOMAXPROCS #cgroups #CPUThrottling #ContainerPerformance #DevOps #SRE

🟣لینک مقاله:
https://golangweekly.com/link/174644/web

➖➖➖➖➖➖➖➖
👑 @gopher_academy

Kube-Copilot

یک دستیار هوش مصنوعی برای Kubernetes , که مدیریت و نگهداری خوشه‌ها رو هوشمندتر و ساده‌تر میکنه. این ابزار با اتصال مستقیم به API سرور، پروسه های  پیچیده رو خودکار میکنه و پیشنهادهای عملی برای بهبود پایداری و امنیت ارائه میکنه.

قابلیت‌های اصلی Kube-Copilot :

تولید و بهینه‌سازی مانفیست‌های YAML برای منابعی مثله Deployment، Service، Ingress و ConfigMap

بررسی وضعیت Pod ها و Nodeها و ارائه راهکار برای خطاها یا CrashLoopBackOff

تحلیل لاگ‌ها و پیشنهاد اقدامات اصلاحی در سطح workload

پشتیبانی از استراتژی‌های دیپلویمنت مثل Rolling Update و Canary Rollout

اتوماسیون وظایف تکراری مانند scale کردن، به‌روزرسانی ایمیج‌ها و مانیتورینگ سلامت سرویس‌ها

ارائه توصیه‌های امنیتی برای جلوگیری از misconfiguration و آسیب‌پذیری‌ها


با استفاده از Kube-Copilot، تیم‌ها یجورایی میتونن،  زمان دیباگ و عملیات روزمره رو  به حداقل برسونن ، در عین حال از پایداری، امنیت و کارایی بیشتر در خوشه‌های Kubernetes برخوردار بشن.

github.com/feiskyer/kube-copilot

#DevOps
#kubernetes
#byteforge
@byteforge_chan 🛸

از ایده تا انتشار بدون ریسک؛ Flagr چه کمکی به تیم‌های فنی می‌کند؟

انتشار یه قابلیت جدید همیشه ریسک داره. خیلی وقتا لازمه تغییرات اول فقط برای بخشی از کاربرا فعال بشه تا عملکردش بررسی بشه و بعد برای همه ارائه بشه.

‏Flagr یه سرویس متن‌بازه که با زبان Go نوشته شده و دقیقاً برای همین طراحی شده. این ابزار امکان مدیریت Feature Flag، اجرای A/B تست و همینطور پیکربندی پویا رو به تیم‌های فنی میده.

قابلیت‌های اصلی Flagr:

روشن یا خاموش کردن فیچرها برای گروه‌های مشخص از کاربرا

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

تغییر پیکربندی سرویس‌ها در لحظه، بدون نیاز به دیپلوی مجدد

ارائه API استاندارد (Swagger REST) برای یکپارچگی ساده با سرویس‌ها

نصب روی سرور داخلی (Self-hosted) و کنترل کامل روی داده‌ها

با Flagr، تیم توسعه میتونه تغییراتش رو مطمئن، مرحله‌ای و بدون اختلال منتشر کنه.

سورس‌کد و مستندات:
github.com/openflagr/flagr

#DevOps
#flagr
#byteforge
@byteforge_chan 🛸

🔵 عنوان مقاله
celebrates its tenth anniversary with a look

🟢 خلاصه مقاله:
این مقاله دهمین سالگرد یک ابزار زیرساختی متن‌باز مبتنی بر Go را جشن می‌گیرد و نشان می‌دهد چگونه از یک ابزار کوچک به مولفه‌ای بالغ و شناخته‌شده در تیم‌های DevOps و SRE تبدیل شده است؛ با بهبودهای کارایی و پایداری، معماری افزونه‌پذیر، API/CLI پایدار و تمرکز جدی بر امنیت و زنجیره تأمین. اکوسیستم آن با جامعه‌ای پویا، مستندات بهتر، نسخه‌بندی معنادار، سازگاری عقب‌رو و یکپارچگی گسترده با فضای ابری، CI/CD و ابزارهای مشاهده‌پذیری رشد کرده است. در ادامه، نقشه‌راه بر بهبود تجربه کاربری، غنی‌تر شدن API/SDK، تقویت policy-as-code، مدیریت بهتر وضعیت و دریفت، و اتوماسیون ایمن‌تر در مقیاس تأکید می‌کند.

#Go #Infrastructure #DevOps #OpenSource #Cloud #Automation #Security #Observability

🟣لینک مقاله:
https://golangweekly.com/link/175053/web

➖➖➖➖➖➖➖➖
👑 @gopher_academy