403

описание

No man should escape our universities without knowing how little he knows. - Robert Oppenheimer Contact: @AmirMohGh

← к каналу @DevopsNotFound

172

подписчиков

Охват к подписчикам

529,7%

ERR

Реакции к просмотрам

0,56%

97 на 19 постов

Пересылки к просмотрам

1,17%

202

Постов в день

0,0

всего 20

Где отзываются чаще

доля реакций к просмотрам

18 нояб.bind: Address already in use این ارور یه دروغه میدونستین 2 تا Process میتونن همزمان روی یک پورت Listen کنن؟ توی TCP یه فلگی هست که اجازه میده پروسه بعدی که میخواد روی یه پورت لیسن کنه بتونه همزمان اینکارو انجام بده و این فلگ SO_REUSEPORT هست. وقتی از این فلگ استفاده میکنیم کرنل خودش بین این 2 تا پروسه فرایند LoadBalancing انجام میده. اینکه با چه الگوریتمی لودبلنس میکنه و یا از چه ورژن کرنل به بعد قابل دسترس هست رو میتونین از ChatGPT پیدا کنین. #OS #Network #Funfact2,52%
5 нояб.یه ایرادی که خیلی بین تازه کار ها رایجه، متمایز نبودن کلمات Encoding ،Encryption و Hashing تو ذهنشونه. حتی تو افراد باتجربه هم دیدم که بصورت فعال اینارو متمایز نمیبینن. سعی میکنم خیلی ساده توضیح بدم چون در پست های بعد حتما ازشون استفاده میشه. 1️⃣ ‏Encoding: در واقع یک رشته (مجموعه ای از کاراکتر ها) تبدیل به رشته جدیدی کنیم، بصورتی که صرفا با دونستن الگوریتم Encoding استفاده شده بشه بازگردانیش کرد. یکی از Encodingهای معروف Base64 هست که نحوه کارکردشو میتونید تو GPT ببینید. ‏2️⃣ Encryption: وقتی یه متن رو Encrypt میکنیم، که با استفاده از یک کلید انجام میشه حتما باید اون کلید رو (تو رمزنگاری متقارن) داشته باشیم تا بتونیم به عبارت اولیه برسیم. (مثل AES) پس وقتی میگیم Encoding، فقط با دونستن الگوریتم میتونیم عبارت اولیه رو پیدا کنیم (و اصطلاحا Decode کنیم). ولی وقتی میگیم Encryption یعنی هم باید الگوریتم رو بدونیم، هم کلیدو داشته باشیم. 3️⃣ ‏Hashing: وقتی یه عبارت Hash میشه، دیگه به هیچ عنوان بازگردانی نمیشه. (مثل SHA256) 2 تا دلیل برای اینکه بازگردانی نمیشه هست: 1. توابع Hashing یک به یک نیستن. 2. معکوس ناپذیر هستن. این 2 تا باهم این معنی رو میدن که اولا برگشتن مسیر الگوریتم یه تابع Hash اینقدری پیچیده هست که پیش بینی نمیشه هیچ پردازنده ای بتونه مسیر رو برگرده. دوما اگر هم برگرده، یک عبارت Hashشده بیشتر از 1 جواب برمیگردونه یعنی اگر مسیر تابع رو برگردیم، به بی نهایت عبارت اولیه میرسیم. کلا Hashing خیلی پرکاربرده و دوست دارم یه پست از کاربرداش هم بزارم. #Cryptography2,17%
11 нояб.گاهی اوقات بیشتر از یک پروسه بکند داریم که ممکنه روی سرور های مختلفی باشن و میخوایم درخواست ها به همه اینا برسه. تو اینطور شرایط از چیزی به اسم LoadBalancer استفاده میکنیم. کارش اینه که روی یک پورت لیسن میکنه و هرچی درخواست میاد رو میفرسته به آدرس یا آدرس هایی که بهش میگیم. نمونه: Haproxy و Nginx (چند ده محصول معروف دیگه هستن که اسمشون رو نمیگم) سوالی که پیش میاد اینه که چطور میفهمه به کدوم بکند بفرسته؟ الگوریتم های LoadBalancing: 1️⃣ ‏Round Robin: الگوریتم خیلی معروف در Scheduling هست که بصورت ترتیبی درخواست هارو به ترتیب به بکند های مختلف ارسال میکنه. 2️⃣ ‏Least Connections: بررسی میکنه که درحال حاضر چند کانکشن به هر سرور بازه، و درخواستو میفرسته به اونی که درحال حاضر کمترین تعداد کانکشن رو داره. 3️⃣ ‏Source IP Hash: هر درخواستی که میاد رو بررسی میکنه، آدرس IP و Port مبدا و مقصد رو تو یه جدول نگهداری میکنه و همیشه درخواست های یک Source IP خاص رو به یک بکند خاص میفرسته. اینا پرکاربردترین الگوریتم ها هستن و هرکدوم تو شرایط خاص خودشون کاربرد دارن. اگر علاقه مند هستین میتونید از ChatGPT الگوریتمای بیشتری رو پیدا کنید. وارد جزئیات نمیشم ولی مثلا وقتی Websocket استفاده میکنیم بطور معمول نیاز میشه که از Source IP Hash استفاده کنیم (اگر میخواید تو ChatGPT سرچ کنید، به این برمیگرده که وبسوکت از نوع Stateful Connection هست). #LoadBalancing1,32%
27 июл. 2025 г.سلام (احتمالا) همه اسم Redis رو شنیدیم. دیتابیس از نوع Key-Value هست که کاری ندارم و میتونید جزئیاتش رو مطالعه کنید. یه نکته ای که هست، ردیس بطور کلی دیتارو تو رم نگهداری میکنه و این یعنی وقتی ریستارت بشه تمامی دیتا از بین میره چون همش روی مموری ذخیره شده. خیلی وقتا (به طرز عجیبی) نیازه که دیتایی که ذخیره میکنیم پاک نشه و بمونه، اون موقع ردیس 2 تا راهکار ارائه میکنه: 1. AOF: تو این حالت ردیس بصورت مستقیم تمامی دستورات Write رو (همینطور که تو رم داره) روی دیسک ذخیره میکنه که اگر به هر دلیلی پروسه ردیس متوقف شد و مجددا شروع به کار کرد میتونه اون فایل رو از بالا به پایین بخونه و دیتارو دوباره بریزه تو رم. اینکه بلافاصله بعد از هر عملیات بریزه تو فایل یا هر n ثانیه بریزه تو فایل، بستگی به کانفیگ Redisتون داره. مناسب برای وقتی که داده حساسه و حتی 1 کلید هم ارزشمنده، مثلا وقتی پیام کاربرا (تو یه پیامرسان) رو موقتا تو ردیس ذخیره میکنید. 2. RDB: این مکانیزم در بازه های زمانی قابل تغییری، از کل دیتا Snapshot میگیره و در صورت بروز خطا براتون دیتارو از آخرین اسنپشات برمیگردونه. فایل Snapshot از فایل هایی که توسط AOF ایجاد میشن حجم کمتری دارن و نگهداریشون راحت تره، همچنین شروع دوباره ردیس با اسنپشات سریعتره از حالتی که باید AOF رو لود کنه. مناسب برای وقتی که داده حساسیت کمتری داره و تا چند دقیقه Data Loss قابل قبوله. مثلا نگهداری سشن کاربرا. نتیجه: اگر دنبال Persistence بصورت قطعی هستید، که مطمئن باشید درصورت ریستارت شدن ردیس دیتا برمیگرده، باید از AOF استفاده کنید. در غیر این صورت RDB Snapshot گزینه کم مصرف تریه. اینکه دقیقا کدوم بدرد کارتون میخوره تو این لینک میتونید مطالعه کنید. نکته: میشه از هردو گزینه بصورت همزمان استفاده کرد، که هم دیتا با اطمینان بالا نگهداری بشه، هم موقع بالا اومدن (با استفاده از RDB) ردیس سریعتر روشن بشه. خیلی دوست دارم تو پست های بعد راجع به گزینه های رسیدن به High Availability تو ردیس بگم. سایر رفرنس ها: 1. How Redis Stores Data: Exploring RDB, AOF, Hybrid, and No Persistence 2. Understanding Persistence in Redis — AOF & RDB + on Docker 3. BGREWRITEAOF #Redis1,20%
3 мар. 2025 г.اگه براتون سواله که از چه دیتابیسی استفاده کنید، میتونید به لینک زیر مراجعه کنید😁. https://choosedb.com/1,18%
3 янв. 2023 г.سلام دوباره ۲ تا تغییر سیاست کوتاه بگم بعد میریم سر اصل مطلب: ۱. میخوام تعداد پستارو بیشتر کنم (۲-۳ روز یبار) ولی کوتاه تر ۲. پست ها انسجامی ندارن ولی طولانی مدت (۱-۲ ماه) یدفعه میبینید مجموعه ای از اطلاعات کم ارزش بهم ربط پیدا میکنن و ارزشمند میشن. خب‌ مقدار کمی از Replication میگم. یکی از اهداف در سیستم های توزیع شده High Availability (HA) هست. یعنی من سرویسم طوری باشه که وقتی تعدادی از نود ها یا بخشی از سرورهام پایین میرن سرویسم ادامه بده. برای سرویس هایی که دیتا نگه میدارن لازمه این اتفاق این هست که دیتا بین همشون Replicate بشه. یعنی به اصطلاح یه کپی از دیتا رو هر نودی داشته باشه که بتونه به ملت نمایش بده (تعریف بسیار سطحی). اگر تلاش کنیم رپلیکیشن رو تصور کنیم به ۲ ساختار کلی میرسیم (به فرض وجود ۳ نود): ۱. بعد از گرفتن دستور Write، اول روی نودی که دستور رو دریافت کرده Write انجام بشه، سپس به یوزری که درخواست داده پیام تایید داده بشه. بعد به همه نود های دیگه فرستاده بشه. ۲. بعد از گرفتن دستور Write، نودی که دستور رو دریافت کرده به بقیه نودها تغییرات رو ارسال میکنه و بعد از اینکه همه تایید کردن که تغییرات انجام شد به یوزر پیام تایید فرستاده بشه. فرق این دوتا چیه؟ توی حالت اول فرض کنید درخواست Write اومد و دیتا تغییر پیدا کرد (و به یوزر Success ارسال شد) ولی بلافاصله سرور کرش کرد و خاموش شد. حالا درخواست های بعدی به سرور های دیگه میره درحالی که سرور اولی فرصت نکرده تغییرات رو به اینا بفرسته و دیتای سرورای دیگه قدیمی هست. پس عملا ما در این حالت دیتای اشتباه نشون دادیم. در حالت دوم اگر همین اتفاق بیفته (بعد از گرفتن درخواست از یوزر شروع به اعمال تغییرات در همه سرور ها کنیم) و سرور خاموش بشه میدونیم که همه سرور ها دقیقا و دقیقا دیتا مشابه دارن و اصطلاحا Consistency داریم. حالت اول رو Asynchronous و حالت دوم رو Synchronous میگن. در Asynchronous Replication یوزر با سرعت بیشتری نتیجه رو میگیره (چون لازم نیست منتظر رپلیکیت شدن دیتا بین همه سرورها باشه) ولی Consistency کمتری داره‌ (یعنی ممکنه بعد از کرش شدن یک سرور و رفتن درخواست ها روی سرور جدید (Fail-Over) دیتا عقب جلو بشه). حالت دوم کند تره و نتیجه رکوئست دیرتر میرسه منتهی میدونیم همه سرور ها دیتای کاملا مشابه دارن، درصورت داشتن دیتا حساس بلا استثنا از این نوع رپلیکیشن استفاده میشه. منبع هم لازم نیست چون بسیار مطلب این سری سبک بود. احتمالا خیلیا اینارو میدونستن. ولی بیانش لازم بود.1,04%
1 мар. 2025 г.میدونستید اگه دیسک یه کامپیوتر/سرور رو ازش جدا کنید، بازم میتونید دیتاشو بخونید؟ بطور کلی سیستم عامل برای نشون دادن هر فایل، باید اول اون رو توی رم بریزه. حالا هر فایلی که خونده میشه با توجه به یه سری پارامتر قابل کنترل، میتونه بعد از اینکه خونده شد توی رم بمونه تا سری بعد مجددا از دیسک فراخوانی نشه، چون IO بصورت کلی خیلی هزینه و زمان بره. اگر میخواید تاثیر این cache رو ببینید میتونید از کامند زیر یک بار با کش و یک بار بی کش استفاده کنید: Without caching: dd if=/dev/zero of=/tmp/file bs=1M count=1000 oflag=direct With caching: dd if=/dev/zero of=/tmp/file bs=1M count=1000 و چون این دیتا تو رم وجود داره، حتی اگر دیسک هم جدا بشه سیستم عامل اون درایو رو به حالت Read-only تغییر میده و به شما اجازه میده هرچی تو کش سیستم عامل هست رو بخونید. روش تست کردن این موضوع هم به این شیوه هست کامند زیر رو بزنید: free -h Sample output: total used free shared buff/cache available 3.8Gi 485Mi 937Mi 24Mi 2.4Gi 3.0Gi که میزان کش فعلی رو در قسمت buff/cache نشون میده ولی وقتی کامند زیر رو بزنید کش ها پاک میشن و دیسکی که از سیستم جدا شده دیگه قابل Read هم نیست: echo 3 | sudo tee /proc/sys/vm/drop_caches #Tips #Funfact #Linux #OS #Filesystem0,68%
17 мар. 2025 г.این سایت کار با Git بصورت Interactive یاد میده و نقطه شروع خیلی خوبیه: https://learngitbranching.js.org/ #Git0,68%
14 янв. 2025 г.سلام در باره بعضی دیتابیس هایی که تو Distributed Systems مطرح هستن تحقیق میکردم، که به این سایت برخوردم: https://jepsen.io/analyses اینا یه فریموورکی ساختن (با 7 هزار ستاره!!) کلا کارشونم این هست که یه سری محصولات رو بررسی میکنن و میگن که آیا با مستنداتشون و ادعاهاشون مطابقت داره یا نه. دیتابیس های زیادی رو پوشش دادن، بنظرم اگر با هرکدوم از اینا در مقیاس بالا کار میکنید ارزش داره مقاله مرتبطشو یه بررسی جزئی بکنید. #Databases0,55%
26 февр. 2025 г.سلام. با سید مهدی (@seyedmahdidiary) میخوایم پادکست بزاریم، بخش آخر پادکست سوالاتی که کامنت میکنید رو (تا حد توان و سوادمون) جواب میدیم. بصورت کلی هر سوالی که مربوط به Devops SRE Linux و یا Python میشه رو میتونید بپرسید.0,52%
11 мар. 2025 г.مدیریت لاگ در Docker: تاحالا مسیر زیر رو دیدید؟ /var/lib/docker/containers توی این مسیر به ازای هر کانتینر یک دیرکتوری وجود داره که توش یه سری فایل هست ولی تمرکز من تو این پست روی فایل زیر هست: container-id-json.log *اسم فایل به آی دی کانتینر بستگی داره اگر کانتینرتون لاگ زیادی تولید میکنه، ممکنه باعث پر شدن دیسک و در نتیجه خطا گرفتن از سرویسا بشه. راه محدود کردن این لاگ به 3 شیوه زیره: موقع ساخت کانتینر: docker run -d --log-driver json-file --log-opt max-size=10m --log-opt max-file=3 nginx:alpine داکرکامپوز: version: "3.8" services: nginx: image: nginx:alpine logging: driver: json-file options: max-size: "10m" max-file: "3" تغییر تنظیمات Docker Daemon در مسیر etc/docker/daemon.json/: { "log-driver": "json-file", "log-opts": { "max-size": "10m", "max-file": "3" } } لیست پارامتر ها و کاربردشون رو میتونید تو مستندات داکر مطالعه کنید. #Docker0,43%
2 янв. 2023 г.کامنت اضافه شد.0,42%