سلام
در باره بعضی دیتابیس هایی که تو Distributed Systems مطرح هستن تحقیق میکردم، که به این سایت برخوردم:
https://jepsen.io/analyses
اینا یه فریموورکی ساختن (با 7 هزار ستاره!!) کلا کارشونم این هست که یه سری محصولات رو بررسی میکنن و میگن که آیا با مستنداتشون و ادعاهاشون مطابقت داره یا نه.
دیتابیس های زیادی رو پوشش دادن، بنظرم اگر با هرکدوم از اینا در مقیاس بالا کار میکنید ارزش داره مقاله مرتبطشو یه بررسی جزئی بکنید.
#Databases

چرا کوبرنتیز از Etcd استفاده میکنه؟
✍️ تازگیا برام این سوال ایجاد شد و راجع به این موضوع یک سری تحقیقات انجام دادم، نتایج رو در قالب چند پست تو کانال قراره بگذارم:
1. تا چه حد این جمله درسته؟ آیا واقعا فقط از Etcd استفاده میشه؟
2. (دقیقا) چرا از دیتابیس های SQL استفاده نکردن؟
3. (دقیقا) چرا از دیتابیس های KV دیگه استفاده نکردن؟
#Kubernetes #Etcd

چرا کوبرنتیز از Etcd استفاده میکنه:
آیا واقعا فقط از Etcd استفاده میشه؟ (بخش اول: Kubernetes Distributions)
✍️ نصب و بالا آوردن یک کلاستر کوبر چندتا مشکل داره:
1. منابع مورد نیاز
2. پیچیدگی نصب
برای همین تعداد زیادی سولوشن برای حل این دو مشکل به وجود اومدن، دسته ای از این سولوشنا فرایند نصب رو ساده تر میکنن (مثل KubeADM KinD Kubespray) ولی بعضیاشون کلا باینری هایی که مدیریت کلاستر رو به عهده دارن رو تغییر دادن و برای نصبش هم یک اسکریپت گذاشتن (مثل K3S و K0S).

دسته دوم تحت واژه توزیع های کوبرنتیز (Kubernetes Distributions) شناخته شدن و هر کدوم کاربرد خاصی دارن (مثلا سبک هستن و برای IoT و HomeLab میشه ازشون استفاده کرد یا ابزار خاصی کنارشون نصب میشه و داشبورد مدیریتی آماده دارن و ...).
#K3S #K0S #KubeADM #Kubespray #KinD

سلام.
با سید مهدی (@seyedmahdidiary) میخوایم پادکست بزاریم، بخش آخر پادکست سوالاتی که کامنت میکنید رو (تا حد توان و سوادمون) جواب میدیم.
بصورت کلی هر سوالی که مربوط به Devops SRE Linux و یا Python میشه رو میتونید بپرسید.

میدونستید اگه دیسک یه کامپیوتر/سرور رو ازش جدا کنید، بازم میتونید دیتاشو بخونید؟
بطور کلی سیستم عامل برای نشون دادن هر فایل، باید اول اون رو توی رم بریزه.
حالا هر فایلی که خونده میشه با توجه به یه سری پارامتر قابل کنترل، میتونه بعد از اینکه خونده شد توی رم بمونه تا سری بعد مجددا از دیسک فراخوانی نشه، چون 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 #Filesystem

اگه براتون سواله که از چه دیتابیسی استفاده کنید، میتونید به لینک زیر مراجعه کنید😁.
https://choosedb.com/

شاید تو خیلی از بازرسی ها امنیتی دیده باشید به ورژن اپلیکیشن گیر میدن، و عموما هم بدون توجه به این خطا ها رد میشیم. ولی چرا از نظر امنیتی مشکل داره که ورژن پکیج/سرویس/اپلیکیشن ها قدیمی باشه؟

1. آشنایی با CVEsها: اول با مبحث CVE آشناتون میکنم، هر باگ امنیتی ای که توسط Community یا صاحب اپلیکیشن پیدا میشه، به اون اپلیکیشن/سرویس گزارش میشه و طی بازه زمانی کوتاهی Patch میشه (اگر دلشون بخواد!) و نسخه جدیدی رو بیرون میدن. بعد یا قبل از اینکه پچ رو بدن براش یک CVE ثبت میکنن تا همه درجریان این مشکل قرار بگیرن و آپگرید کنن.

2. همیشه Scanner ها مشغول به کارن: تعداد آی پی های اینترنت خیلی کمه ( تقریبا 4 میلیارد)، به همین دلیل یک نفر میتونه یک پورت خاصی رو تو بازه زمانی خیلی کوتاه (مثلا چند ساعت) در بستر کل اینترنت Scan کنه. بعد از اینکه اسکن کرد نتایج رو فیلتر میکنه و ورژن مدنظرشو طبق لیست CVE ها پیدا میکنه و یه اپلیکیشن/سازمان رو میاره پایین.

3. پسوورد امن سرور و سرویس: بعضی از این اسکنر ها هم همیشه مشغول Brute Force کردن سرور ها هستن، اگر به لاگ SSHD سرورتون مراجعه کنید:

journalctl -u ssh -f

احتمالا چندین لاگین ناموفق میبینید. معمولا هم از لیست پسوورد های معروف استفاده میکنن پس قبل از اینکه پسوورد بزارید چک کنید تو این لیست نباشه. (مثال از Password List)

4. حمله های Zero-Day: وقتی یک آسیب پذیری (CVE) جدید میاد، همه شروع میکنن به اسکن کردن اینترنت برای پیدا کردن اون نسخه خاص از سرویس مدنظر. این باعث میشه اگر تو 1-2 روز اول آپگرید نکنید قطعا مورد حمله قرار بگیرید.

5. سرور شما همیشه مورد حمله قرار داره: با توجه به راحتی اسکن کردن و تعداد بالای افرادی که از این کار لذت میبرن، میتونید فرض رو بر این بزارید که در هر لحظه سرور های Edge شما مورد حمله قرار دارن و هر آسیب پذیری داشته باشن بلافاصله پیدا و سو استفاده میشه.
با یک مثال این پست رو تموم میکنم، فرض کنید همین امروز یک آسیب پذیری بیاد که بشه به هر سروری که ورژن SSH Serverش OpenSSH_9.7p1 هست بدون نیاز به پسوورد لاگین کنیم. و از قضا ماهم رو همین ورژنیم، چیزی حدود 1 ساعت بعد از گزارش باگ اگر هنوز از اون ورژن استفاده میکنید میتونید با سرور خدافظی کنید 😁.
#Security #OS

مدیریت لاگ در 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"
}
}

لیست پارامتر ها و کاربردشون رو میتونید تو مستندات داکر مطالعه کنید.
#Docker

این سایت کار با Git بصورت Interactive یاد میده و نقطه شروع خیلی خوبیه:
https://learngitbranching.js.org/
#Git

سلام
(احتمالا) همه اسم 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

#Redis

یه ایرادی که خیلی بین تازه کار ها رایجه، متمایز نبودن کلمات 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 خیلی پرکاربرده و دوست دارم یه پست از کاربرداش هم بزارم.

#Cryptography

گاهی اوقات بیشتر از یک پروسه بکند داریم که ممکنه روی سرور های مختلفی باشن و میخوایم درخواست ها به همه اینا برسه. تو اینطور شرایط از چیزی به اسم 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 هست).

#LoadBalancing

bind: Address already in use
این ارور یه دروغه
میدونستین 2 تا Process میتونن همزمان روی یک پورت Listen کنن؟
توی TCP یه فلگی هست که اجازه میده پروسه بعدی که میخواد روی یه پورت لیسن کنه بتونه همزمان اینکارو انجام بده و این فلگ SO_REUSEPORT هست.
وقتی از این فلگ استفاده میکنیم کرنل خودش بین این 2 تا پروسه فرایند LoadBalancing انجام میده.

اینکه با چه الگوریتمی لودبلنس میکنه
و یا از چه ورژن کرنل به بعد قابل دسترس هست رو میتونین از ChatGPT پیدا کنین.

#OS #Network #Funfact