https://www.linkedin.com/posts/ramtin-safadoust_podman-containers-devops-activity-7295831613400109056-pvga?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAEPHcQBIu5rXaFgo5F_hVlrlaE66EdlQzQ

چرا باید به جای Docker از Podman استفاده کنیم؟
نویسنده : رامتین صفادوست

اگه با کانتینرها کار می‌کنی، احتمالاً Docker برات آشناست. ولی تا حالا Podman رو امتحان کردی؟ یه موتور کانتینر سبک، امن و بدون نیاز به daemon که کلی مزیت داره، مخصوصاً از نظر امنیت و یکپارچگی با سیستم.

چندتا دلیل که چرا Podman داره محبوب‌تر می‌شه:

✅ بدون نیاز به Root – کانتینرها رو بدون دسترسی root اجرا کن و ریسک امنیتی رو کم کن.

✅ بدون Daemon – دیگه نیازی به یه سرویس همیشه در حال اجرا نیست، پس نقاط حمله کمتر می‌شن.

✅ سازگار با Docker CLI – اگه از Docker استفاده می‌کردی، راحت می‌تونی مهاجرت کنی (حتی alias docker=podman هم جواب می‌ده!).

✅ دوست‌داشتنی برای Kubernetes – فقط با یه دستور می‌تونی YAML مورد نیاز برای K8s رو بسازی (podman generate kube).

✅ یکپارچه با systemd – اگه می‌خوای کانتینرها رو مثل یه سرویس مدیریت کنی، Podman بهترین گزینه‌ست.

اگه دنبال یه جایگزین امن‌تر و بهینه‌تر برای Docker هستی، حتماً Podman رو امتحان کن.


#Podman #Containers #DevOps #Kubernetes

پ.ن:
نظرات ذیل پست فوق در لینکدین را هم نگاهی بیندازید ...

چطور تسلا با ClickHouse یک پلتفرم مشاهده‌پذیری در مقیاس نجومی ساخت؟

مشاهده‌پذیری در مقیاس کوادریلیون (هزار بیلیارد) با ClickHouse و پروژه‌ای به نام Comet

داستان تغییر زیرساخت observability تسلا از کجا شروع شد ؟

🔧 چند میلیون خودرو متصل، هزاران زیرسیستم توزیع‌شده، و گیگافکتوری‌هایی که شبانه‌روز داده می‌فرستند. تسلا در چنین مقیاسی نمی‌توانست روی Prometheus حساب باز کند...

👨‍💻 مهندس ارشد تسلا Alon Tal، می‌گوید:

«ما به سیستمی نیاز داشتیم که بتونه ده‌ها میلیون ردیف در ثانیه را ingest کنه، سال‌ها داده رو نگه داره، و همچنان real-time پاسخ بده.»

چرا Prometheus کافی نبود؟

🔸 مقیاس‌پذیری افقی محدود

🔸 وابستگی به یک سرور واحد (ریسک از دست دادن کل متریک‌ها)

🔸 مشکلات نگهداری بلندمدت و زبان کوئری محدود

✅ راه‌حل: ساخت یک سیستم جدید به نام Comet

💡 با استفاده از ClickHouse به عنوان هسته‌ی اصلی، تسلا یک پلتفرم metrics محور ساخت که:

📥 داده‌ها را از طریق OTLP و Kafka ingest می‌کند

⚙️ با ETLهای سفارشی داده‌ها را به شکل ساخت‌یافته وارد ClickHouse می‌کند

🔄 و مهم‌تر از همه:

کوئری‌های PromQL را به SQL معادل در ClickHouse ترجمه می‌کند بدون اینکه مهندسان متوجه تفاوت شوند!

🧠 یعنی داشبوردهای موجود (Grafana، Alertmanager، و...) بدون تغییر کار می‌کنند!

💥 مقیاس واقعی؟

یک میلیارد ردیف در ثانیه! به مدت ۱۱ روز پیاپی!

نتیجه؟

🔹 بدون یک خطا

🔹 مصرف ثابت RAM و CPU

🔹 بیش از ۱ کوادریلیون رکورد با موفقیت ingest شده!

📊 سیستم هنوز هم در حال scale شدن برای تیم‌های داخلی تسلاست!

✨ چرا ClickHouse؟

🔹 سرعت بی‌رقیب در پاسخ به کوئری‌های پیچیده

🔹 UDFهای اجرایی برای کوئری‌های غیر trivial

🔹 پشتیبانی از PromQL و TraceQL

🔹 نگهداری بلندمدت داده‌ها با حجم بالا

🔹 و مهم‌تر از همه: قابلیت اطمینان بالا در مقیاس تسلا!

🔭 آینده‌ی Comet؟

🔧 پشتیبانی از distributed tracing

🌍 احتمال open-source شدن

🎯 گسترش به دیگر واحدهای عملیاتی در تسلا

📎 جمع‌بندی

تسلا با پروژه‌ی Comet ثابت کرد که observability در مقیاس سیاره‌ای ممکن است—اگر ابزار مناسب انتخاب شود!


✅ حالا واقعا پرومتئوس حذف شد؟

تسلا Prometheus رو به‌طور مستقیم حذف نکرد، ولی:

🌟دیگه از خود Prometheus برای ذخیره‌سازی و کوئری استفاده نمی‌کنه.

🌟 به‌جاش، پلتفرمی به نام Comet ساخت که خودش می‌تونه PromQL (زبان کوئری Prometheus) رو اجرا کنه و پشت صحنه با کلیک‌هوس ارتباط بگیره و خروجی بده بدون اینکه واقعاً Prometheus وجود داشته باشه!


🔗 منبع اصلی:

https://clickhouse.com/blog/how-tesla-built-quadrillion-scale-observability-platform-on-clickhouse

#ClickHouse #Observability #Tesla #PromQL #DataEngineering #Scalability #TimeSeries #Kafka #DevOps #OpenTelemetry #Infrastructure

‍ معرفی رسمی ClickStack – استک Observability اپن‌سورس بر پایه ClickHouse

سال‌ها بود که با وجود قدرت بالای ClickHouse در ذخیره و کوئری‌گیری سریع داده‌ها، جای یک راه‌حل Observability واقعی در این اکوسیستم حس می‌شد.

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

اما حالا اوضاع فرق کرده.

با خرید HyperDX در ابتدای سال 2025، کلیک‌هوس قدم بزرگی در این حوزه برداشت و اخیرا از ClickStack رونمایی کرد:

یک استک کامل، اپن‌سورس و بسیار سریع برای Observability – ساخته‌شده بر قلب تپنده‌ی ClickHouse. ❤️‍🔥

آدرس : https://clickhouse.com/use-cases/observability

📦 مجموعه ابزار ClickStack چیست؟

🔹 یک پلتفرم سبک و قدرتمند برای مانیتورینگ و دیباگ

🔹 سازگار با OpenTelemetry

🔹 شامل رابط کاربری HyperDX، کلکتور سفارشی، و ClickHouse

🔹 آماده برای محیط‌های تولیدی، با نصب آسان و تجربه‌ای روان برای تیم‌ها


💡 چرا این اتفاق مهمه؟

تا پیش از این، حتی تیم‌هایی مثل نتفلیکس که سال‌ها از کلیک‌هوس برای تحلیل داده‌های Observability استفاده می‌کردند، مجبور بودند ابزارهای اختصاصی خودشون رو بسازند. حالا با ClickStack، همون قدرت و کارایی در اختیار همه هست آن‌ هم به سادگی و سهولت .


✨ ویژگی‌های جذاب ClickStack:
✅ جستجوی بسیار سریع در لاگ‌ها و تریس‌ها

✅ تجزیه‌وتحلیل داده‌های عظیم بدون نیاز به SQL

✅ مشاهده زنده‌ی لاگ‌ها و بازپخش جلسات

✅ پشتیبانی کامل از JSON و schemaهای پویا

✅ همبستگی خودکار بین لاگ، متریک، تریس و سشن

✅ طراحی‌شده برای کار با داده‌های با کاردینالیتی بالا

✅ هشداردهی، تحلیل روند و شناسایی ناهنجاری


🧱 معماری ClickStack

🎯 ClickHouse: قلب پردازش تحلیلی

🎯 OpenTelemetry Collector: جمع‌آورنده‌ی داده‌ها با ساختار بهینه

🎯HyperDX UI: رابط کاربری مدرن برای مشاهده و کاوش داده‌ها

می‌تونید این اجزا رو مستقل یا به‌صورت یکپارچه استفاده کنید. نسخه مبتنی بر مرورگر HyperDX UI هم در دسترسه که می‌تونه به استقرارهای موجود کلیک‌هوس متصل بشه – بدون نیاز به زیرساخت اضافه.


📚 طراحی ClickStack بر اساس چند اصل ساده شکل گرفته:

📌نصب سریع و بدون پیچیدگی

📌پشتیبانی از SQL و Lucene-style search برای راحتی توسعه‌دهنده‌ها

📌دید کامل از سیستم از سشن کاربر تا کوئری دیتابیس

📌سازگاری کامل با اکوسیستم OpenTelemetry

📌و مهم‌تر از همه: اپن‌سورس، قابل‌توسعه و شفاف

🎯 برای همه‌ی تیم‌هایی که دنبال یک راه‌حل سریع، منعطف و قابل‌اتکا برای Observability هستند، حالا یک گزینه جامع و بسیار سریع و در عین حال سبک و مقیاس پذیر داریم.

اگر از ClickHouse استفاده می‌کنید، می‌توانید به راحتی به ClickStack مهاجرت کنید و یا حداقل آنرا امتحان کنید.

#ClickStack #ClickHouse #Observability #OpenTelemetry #DevOps #SRE #OpenSource #HyperDX #MonitoringTools #DataEngineering

به تازگی کتاب Platform Engineering on Kubernetes نوشته‌ی Mauricio Salatino رو خوندم و واقعاً می‌تونم بگم یکی از منابع تحول‌آفرین در این حوزه‌ست.
پست اخیر Sajad Hamreh در لینکدین
چیزی که برای من خیلی جالب بود، این بود که کتاب فاصله بین دانش تئوری Kubernetes و عملیات واقعی Platform Engineering رو پر می‌کنه. یعنی نه صرفاً توضیح تئوریه و نه صرفاً دستورالعمل خشک، بلکه قدم‌به‌قدم نشون می‌ده چطور پلتفرمی بسازیم که واقعاً در دنیای واقعی کار کنه.
✅ از مباحث پایه Kubernetes شروع می‌کنه و به استراتژی‌های پیچیده‌تر مثل GitOps، progressive delivery، service mesh integration و multi-tenancy می‌رسه.
✅ فصل‌های مربوط به developer portals و self-service capabilities واقعاً برای من ارزشمند بودن؛ چون توی خیلی از منابع دیگه کمتر بهشون پرداخته می‌شه، در حالی که برای پذیرش موفق پلتفرم حیاتی هستن.
✅ نکته مهم دیگه اینه که با ابزارهایی مثل ArgoCD و Crossplane مثال‌های عملی زده که بلافاصله می‌شه در پروژه‌ها به‌کار برد.
✅ تجربه‌ی عمیق نویسنده هم در بخش‌های troubleshooting و هشدار درباره‌ی pitfalls کاملاً مشهوده؛ چیزهایی که به‌معنای واقعی کلمه جلوی سردردهای بعدی رو می‌گیرن.

برای من، پیام اصلی کتاب این بود که Platform Engineering یک تمرین صرفاً فنی نیست، بلکه یک محصوله؛ محصولی برای توسعه‌دهنده‌ها که اگر درست طراحی بشه، می‌تونه بهره‌وری کل سازمان رو متحول کنه.