🐳 دیسک سرور با Docker پر شده؟ اینو بزن 👇
1️⃣ مصرف Docker:
docker system df
---
2️⃣ کانتینرهای اضافی:
docker ps -a
---
3️⃣ پاکسازی سریع:
docker system prune
---
4️⃣ پاکسازی کاملتر:
docker system prune -a
⚠️ imageهای بدون استفاده هم پاک میشن
---
5️⃣ بررسی حجم دقیق:
docker system df -v
---
6️⃣ volumeهای بلااستفاده:
docker volume prune
---
💡 نکته مهم:
build cache خیلی وقتا عامل اصلیه:
docker builder prune
---
🎯 مسیر:
df → بررسی → prune
⚠️ اول بررسی کن، بعد پاک کن!
#Docker #DevOps
1️⃣ مصرف Docker:
docker system df
---
2️⃣ کانتینرهای اضافی:
docker ps -a
---
3️⃣ پاکسازی سریع:
docker system prune
---
4️⃣ پاکسازی کاملتر:
docker system prune -a
⚠️ imageهای بدون استفاده هم پاک میشن
---
5️⃣ بررسی حجم دقیق:
docker system df -v
---
6️⃣ volumeهای بلااستفاده:
docker volume prune
---
💡 نکته مهم:
build cache خیلی وقتا عامل اصلیه:
docker builder prune
---
🎯 مسیر:
df → بررسی → prune
⚠️ اول بررسی کن، بعد پاک کن!
#Docker #DevOps
🚨 سرور ارور داد: No space left on device ؟
این ۵ دستور رو سریع بزن 👇
---
1️⃣ وضعیت دیسک:
df -h
---
2️⃣ مشکل پنهان:
df -i
⚠️ ممکنه فضا باشه ولی inode پر شده
---
3️⃣ پیدا کردن عامل:
du -h --max-depth=1 / | sort -hr
---
4️⃣ مسیرهای مشکوک:
du -sh /var /var/log /home
💡 ۸۰٪ مواقع لاگها مقصرن
---
5️⃣ فایلهای سنگین:
find / -type f -size +500M 2>/dev/null
---
🎯 مسیر حرفهای:
df → du → find
⚠️ مستقیم پاک نکن = ریسک از دست رفتن دیتا
#DevOps #Linux
این ۵ دستور رو سریع بزن 👇
---
1️⃣ وضعیت دیسک:
df -h
---
2️⃣ مشکل پنهان:
df -i
⚠️ ممکنه فضا باشه ولی inode پر شده
---
3️⃣ پیدا کردن عامل:
du -h --max-depth=1 / | sort -hr
---
4️⃣ مسیرهای مشکوک:
du -sh /var /var/log /home
💡 ۸۰٪ مواقع لاگها مقصرن
---
5️⃣ فایلهای سنگین:
find / -type f -size +500M 2>/dev/null
---
🎯 مسیر حرفهای:
df → du → find
⚠️ مستقیم پاک نکن = ریسک از دست رفتن دیتا
#DevOps #Linux
❤1
🔐 CA Server چیست و چرا مهمه؟
CA (Certificate Authority) سیستمیه که گواهیهای دیجیتال رو:
✔️ صادر میکنه
✔️ امضا میکنه
✔️ مدیریت و تمدید میکنه
📌 هرجا SSL/TLS و ارتباط امن هست → CA نقش داره
---
⚙️ چطور کار میکنه؟
1️⃣ سرویس یه درخواست (CSR) میسازه
2️⃣ CA بررسیش میکنه
3️⃣ با کلید خودش امضا میکنه
✅ بعدش بقیه سیستمها بهش اعتماد میکنن (Chain of Trust)
---
🏷 انواع CA:
🌍 Public CA → برای اینترنت (مثل سایتها)
🏢 Private CA → داخل سازمان و DevOps
---
🧱 ساختار CA:
👑 Root CA → ریشه اعتماد
🔗 Intermediate → لایه امنتر
🛠 Issuing CA → صادرکننده نهایی
---
⭐ کاربردها:
HTTPS 🌐
VPN 🔒
Email 📧
Auth 👤
Infra داخلی 🏗
---
🎯 خلاصه:
بدون CA → امنیت معنی نداره
Public برای سرویس عمومی
Private برای زیرساخت داخلی
#DevOps #Security #SSL
CA (Certificate Authority) سیستمیه که گواهیهای دیجیتال رو:
✔️ صادر میکنه
✔️ امضا میکنه
✔️ مدیریت و تمدید میکنه
📌 هرجا SSL/TLS و ارتباط امن هست → CA نقش داره
---
⚙️ چطور کار میکنه؟
1️⃣ سرویس یه درخواست (CSR) میسازه
2️⃣ CA بررسیش میکنه
3️⃣ با کلید خودش امضا میکنه
✅ بعدش بقیه سیستمها بهش اعتماد میکنن (Chain of Trust)
---
🏷 انواع CA:
🌍 Public CA → برای اینترنت (مثل سایتها)
🏢 Private CA → داخل سازمان و DevOps
---
🧱 ساختار CA:
👑 Root CA → ریشه اعتماد
🔗 Intermediate → لایه امنتر
🛠 Issuing CA → صادرکننده نهایی
---
⭐ کاربردها:
HTTPS 🌐
VPN 🔒
Email 📧
Auth 👤
Infra داخلی 🏗
---
🎯 خلاصه:
بدون CA → امنیت معنی نداره
Public برای سرویس عمومی
Private برای زیرساخت داخلی
#DevOps #Security #SSL
🐳 Docker و Podman چه فرقی دارن؟
هر دو برای ساخت و اجرای کانتینر استفاده میشن، اما چند تفاوت مهم دارن:
🔹 Docker معمولاً به یک سرویس همیشهفعال به اسم
🔹 Podman بدون daemon کار میکنه؛ یعنی سبکتر و مستقلتر اجرا میشه.
🔹 Docker معمولاً با دسترسی root شناخته میشه.
🔹 Podman از اول روی اجرای rootless تمرکز داشته؛ یعنی اجرای کانتینر با user معمولی.
🔹 دستورهاشون خیلی شبیه همه:
برای همین مهاجرت از Docker به Podman معمولاً سخت نیست.
📌 جمعبندی:
Docker رایجتره و اکوسیستم بزرگتری داره.
Podman برای سناریوهای امنتر، rootless و بدون daemon انتخاب جذابیه.
کانتینر همونه؛ تفاوت توی روش مدیریته ⚙️
هر دو برای ساخت و اجرای کانتینر استفاده میشن، اما چند تفاوت مهم دارن:
🔹 Docker معمولاً به یک سرویس همیشهفعال به اسم
daemon نیاز داره.🔹 Podman بدون daemon کار میکنه؛ یعنی سبکتر و مستقلتر اجرا میشه.
🔹 Docker معمولاً با دسترسی root شناخته میشه.
🔹 Podman از اول روی اجرای rootless تمرکز داشته؛ یعنی اجرای کانتینر با user معمولی.
🔹 دستورهاشون خیلی شبیه همه:
docker run nginx
podman run nginx
برای همین مهاجرت از Docker به Podman معمولاً سخت نیست.
📌 جمعبندی:
Docker رایجتره و اکوسیستم بزرگتری داره.
Podman برای سناریوهای امنتر، rootless و بدون daemon انتخاب جذابیه.
کانتینر همونه؛ تفاوت توی روش مدیریته ⚙️
❤2
🚨 اجرای کانتینر با کاربر root چه ریسکی داره؟
خیلی از کانتینرها بهصورت پیشفرض با
اما root بودن داخل کانتینر همیشه بیخطر نیست.
اگر کانتینر اشتباه تنظیم شده باشه، مثلاً volume حساس از هاست mount شده باشه یا کانتینر privilege بالا داشته باشه، دسترسی root میتونه ریسک امنیتی رو زیاد کنه.
✅ راه بهتر:
تا جای ممکن کانتینر رو با user غیر root اجرا کنیم:
یا موقع اجرا:
📌 جمعبندی:
root بودن کانتینر همیشه فاجعه نیست، ولی در production بهتره اصل حداقل دسترسی رو رعایت کنیم.
امنیت از همین جزئیات شروع میشه 👌
خیلی از کانتینرها بهصورت پیشفرض با
root اجرا میشن.اما root بودن داخل کانتینر همیشه بیخطر نیست.
اگر کانتینر اشتباه تنظیم شده باشه، مثلاً volume حساس از هاست mount شده باشه یا کانتینر privilege بالا داشته باشه، دسترسی root میتونه ریسک امنیتی رو زیاد کنه.
✅ راه بهتر:
تا جای ممکن کانتینر رو با user غیر root اجرا کنیم:
RUN adduser --disabled-password appuser
USER appuser
یا موقع اجرا:
docker run --user 1000:1000 image-name
📌 جمعبندی:
root بودن کانتینر همیشه فاجعه نیست، ولی در production بهتره اصل حداقل دسترسی رو رعایت کنیم.
امنیت از همین جزئیات شروع میشه 👌
❤1
☸️ خبر جدید DevOps: انتشار Kubernetes 1.36
نسخهی جدید Kubernetes با اسم Haru منتشر شد.
این نسخه شامل ۷۰ بهبود جدیده:
🔹 ۱۸ قابلیت Stable
🔹 ۲۵ قابلیت Beta
🔹 ۲۵ قابلیت Alpha
چند نکته مهم:
🔸 کنترل دسترسی دقیقتر برای Kubelet API
🔸 Stable شدن User Namespaces برای امنیت بیشتر Podها
🔸 امکان استفاده از OCI artifactها بهعنوان volume
🔸 مشاهده بهتر وضعیت resourceهایی مثل GPU
📌 نکته مهم:
قبل از آپگرید، حتماً release note رو بررسی کنید؛ چون بعضی قابلیتهای قدیمی deprecated یا حذف شدن.
🔗 لینک خبر رسمی:
https://kubernetes.io/blog/2026/04/22/kubernetes-v1-36-release/
DevOps یعنی همیشه آمادهی تغییر بودن ⚙️
نسخهی جدید Kubernetes با اسم Haru منتشر شد.
این نسخه شامل ۷۰ بهبود جدیده:
🔹 ۱۸ قابلیت Stable
🔹 ۲۵ قابلیت Beta
🔹 ۲۵ قابلیت Alpha
چند نکته مهم:
🔸 کنترل دسترسی دقیقتر برای Kubelet API
🔸 Stable شدن User Namespaces برای امنیت بیشتر Podها
🔸 امکان استفاده از OCI artifactها بهعنوان volume
🔸 مشاهده بهتر وضعیت resourceهایی مثل GPU
📌 نکته مهم:
قبل از آپگرید، حتماً release note رو بررسی کنید؛ چون بعضی قابلیتهای قدیمی deprecated یا حذف شدن.
🔗 لینک خبر رسمی:
https://kubernetes.io/blog/2026/04/22/kubernetes-v1-36-release/
DevOps یعنی همیشه آمادهی تغییر بودن ⚙️
❤2
📢 خبر DevOps: انتشار Grafana 13
Grafana نسخهی 13.0 رو معرفی کرد و تمرکز اصلی این نسخه روی داشبوردها، GitOps، AI و بهبود تجربهی Observability هست.
چند تغییر مهم:
🔹 Git Sync
مدیریت داشبوردها مثل کد؛ یعنی اتصال به Git و کنترل نسخه برای dashboardها.
🔹 Dynamic Dashboards
داشبوردها ساختار جدید و منعطفتری دارن و نسخههای قدیمی خودکار migrate میشن.
🔹 Grafana Assistant
دستیار هوشمند برای ساخت داشبورد، تحلیل telemetry و کار با دادهها.
🔹 Restore Deleted Dashboards
اگر داشبوردی اشتباهی حذف بشه، امکان برگردوندنش وجود داره.
🔹 بهبود Visualizationها
Gauge جدید، Annotation بهتر، Panel Styles و Legend Limits برای داشبوردهای تمیزتر و سریعتر.
⚠️ نکته مهم:
قبل از آپگرید، Breaking Changeها رو بررسی کنید؛ مخصوصاً تغییرات API، حذف Image Renderer plugin و تغییر دستورهای قدیمی CLI.
🔗 لینک رسمی:
https://grafana.com/docs/grafana/latest/whatsnew/whats-new-in-v13-0/
Grafana 13 یعنی یک قدم جدیتر به سمت Observability هوشمندتر ⚙️
Grafana نسخهی 13.0 رو معرفی کرد و تمرکز اصلی این نسخه روی داشبوردها، GitOps، AI و بهبود تجربهی Observability هست.
چند تغییر مهم:
🔹 Git Sync
مدیریت داشبوردها مثل کد؛ یعنی اتصال به Git و کنترل نسخه برای dashboardها.
🔹 Dynamic Dashboards
داشبوردها ساختار جدید و منعطفتری دارن و نسخههای قدیمی خودکار migrate میشن.
🔹 Grafana Assistant
دستیار هوشمند برای ساخت داشبورد، تحلیل telemetry و کار با دادهها.
🔹 Restore Deleted Dashboards
اگر داشبوردی اشتباهی حذف بشه، امکان برگردوندنش وجود داره.
🔹 بهبود Visualizationها
Gauge جدید، Annotation بهتر، Panel Styles و Legend Limits برای داشبوردهای تمیزتر و سریعتر.
⚠️ نکته مهم:
قبل از آپگرید، Breaking Changeها رو بررسی کنید؛ مخصوصاً تغییرات API، حذف Image Renderer plugin و تغییر دستورهای قدیمی CLI.
🔗 لینک رسمی:
https://grafana.com/docs/grafana/latest/whatsnew/whats-new-in-v13-0/
Grafana 13 یعنی یک قدم جدیتر به سمت Observability هوشمندتر ⚙️
👍2
🔹 Image Registry چیه و چرا باید داشته باشیم؟
Image Registry یه سیستم برای ذخیره و مدیریت Docker Images است که امکان بهروزرسانی، اشتراکگذاری و کنترل دسترسی به ایمیجها رو فراهم میکنه.
🔸 چرا باید Image Registry داشته باشیم؟
مدیریت نسخهها: نسخهبندی و دسترسی آسان به ایمیجها.
امنیت: کنترل دسترسی با مخازن خصوصی.
پشتیبانی از CI/CD: تسهیل فرآیندهای استقرار خودکار.
🔸 انواع:
Public: مثل Docker Hub.
Private: مخازن خصوصی برای سازمانها.
Image Registry یه سیستم برای ذخیره و مدیریت Docker Images است که امکان بهروزرسانی، اشتراکگذاری و کنترل دسترسی به ایمیجها رو فراهم میکنه.
🔸 چرا باید Image Registry داشته باشیم؟
مدیریت نسخهها: نسخهبندی و دسترسی آسان به ایمیجها.
امنیت: کنترل دسترسی با مخازن خصوصی.
پشتیبانی از CI/CD: تسهیل فرآیندهای استقرار خودکار.
🔸 انواع:
Public: مثل Docker Hub.
Private: مخازن خصوصی برای سازمانها.
ساختار Image Registry معمولاً این شکلیه:
فرض کنیم ۳ تا اپلیکیشن داریم:
هر اپلیکیشن داخل Registry یک Repository جدا دارد و نسخههای مختلف آن با Tag مشخص میشوند.
مثلاً:
در این آدرس:
برای مدیریت بهتر این ساختار، معمولاً از Repository Manager ها مثل Harbor، Nexus یا GitLab Container Registry استفاده میشود.
این ابزارها کمک میکنند ایمیجها، نسخهها، دسترسیها و سیاستهای نگهداری بهتر مدیریت شوند.
Registry → Repository → Tag
فرض کنیم ۳ تا اپلیکیشن داریم:
registry.company.local
├── auth-service
│ ├── 1.0.0
│ └── 1.1.0
├── payment-service
│ ├── 2.0.0
│ └── 2.1.0
└── frontend-app
├── 1.0.0
└── production
هر اپلیکیشن داخل Registry یک Repository جدا دارد و نسخههای مختلف آن با Tag مشخص میشوند.
مثلاً:
registry.company.local/auth-service:1.1.0
در این آدرس:
registry.company.local آدرس Registry استauth-service نام Repository است1.1.0 نسخه یا Tag ایمیج استبرای مدیریت بهتر این ساختار، معمولاً از Repository Manager ها مثل Harbor، Nexus یا GitLab Container Registry استفاده میشود.
این ابزارها کمک میکنند ایمیجها، نسخهها، دسترسیها و سیاستهای نگهداری بهتر مدیریت شوند.
Nexus چیست؟
Nexus Repository Manager ابزاری برای مدیریت و نگهداری Artifact ها و Image هاست.
در پروژههای DevOps خروجی Build فقط Docker Image نیست؛ ممکنه با پکیجها و فایلهای مختلفی کار کنیم:
Nexus این خروجیها رو در یک محل مرکزی ذخیره و مدیریت میکنه.
سه نوع Repository مهم در Nexus:
مثلاً برای Docker Registry خصوصی:
کاربردهای Nexus:
* ساخت Private Registry
* مدیریت نسخهها
* کنترل دسترسی
* کش کردن Dependency ها
* استفاده در CI/CD Pipeline
Nexus کمک میکنه Artifact ها و Image ها ساختارمند، قابل کنترل و قابل استفاده در محیطهای مختلف نگهداری بشن.
Nexus Repository Manager ابزاری برای مدیریت و نگهداری Artifact ها و Image هاست.
در پروژههای DevOps خروجی Build فقط Docker Image نیست؛ ممکنه با پکیجها و فایلهای مختلفی کار کنیم:
Docker Image
Maven Package
npm Package
Python Package
Helm Chart
Nexus این خروجیها رو در یک محل مرکزی ذخیره و مدیریت میکنه.
سه نوع Repository مهم در Nexus:
Hosted → نگهداری Artifact های داخلی
Proxy → کش کردن منابع خارجی
Group → ترکیب چند Repository در یک آدرس
مثلاً برای Docker Registry خصوصی:
nexus.company.local:8082/auth-service:1.0.0
کاربردهای Nexus:
* ساخت Private Registry
* مدیریت نسخهها
* کنترل دسترسی
* کش کردن Dependency ها
* استفاده در CI/CD Pipeline
Nexus کمک میکنه Artifact ها و Image ها ساختارمند، قابل کنترل و قابل استفاده در محیطهای مختلف نگهداری بشن.
❤2
terraform-sananetco.pdf
2.2 MB
توی این فایل آموزشی با مفاهیم Infrastructure as Code (IaC) آشنا میشیم و یاد میگیریم چطور با Terraform زیرساختها رو به صورت کد مدیریت کنیم.
موضوعات اصلی این آموزش:
مفهوم IaC و اهمیتش تو مدیریت زیرساخت
معرفی Terraform و مزایای استفاده از اون
نصب و راهاندازی Terraform
چرخه عمر (Cycle) ایجاد، تغییر و مدیریت زیرساختها با Terraform
موضوعات اصلی این آموزش:
مفهوم IaC و اهمیتش تو مدیریت زیرساخت
معرفی Terraform و مزایای استفاده از اون
نصب و راهاندازی Terraform
چرخه عمر (Cycle) ایجاد، تغییر و مدیریت زیرساختها با Terraform
👍2
🔐 Let’s Encrypt چیست؟
Let’s Encrypt یک Certificate Authority رایگان و معتبر است که برای سایتها SSL/TLS Certificate صادر میکند و باعث میشود ارتباط کاربران از HTTP به HTTPS تبدیل شود.
اما قبل از صدور Certificate، باید مطمئن شود که domain واقعاً تحت کنترل ماست.
به این مرحله میگویند:
✅ Domain Validation
رایجترین روشهای احراز هویت:
🌐 HTTP Challenge
بررسی فایل یا token از طریق وبسرور
🧾 DNS Challenge
بررسی TXT Record داخل DNS
(مناسب wildcard certificate)
🔒 TLS-ALPN Challenge
اعتبارسنجی از طریق TLS روی پورت 443
📌 یعنی Let’s Encrypt اول مالکیت domain را تأیید میکند، بعد SSL صادر میکند.
در پست بعدی میرویم سراغ گرفتن SSL برای Nginx با Certbot و bind کردن آن روی Nginx.
Let’s Encrypt یک Certificate Authority رایگان و معتبر است که برای سایتها SSL/TLS Certificate صادر میکند و باعث میشود ارتباط کاربران از HTTP به HTTPS تبدیل شود.
اما قبل از صدور Certificate، باید مطمئن شود که domain واقعاً تحت کنترل ماست.
به این مرحله میگویند:
✅ Domain Validation
رایجترین روشهای احراز هویت:
🌐 HTTP Challenge
بررسی فایل یا token از طریق وبسرور
🧾 DNS Challenge
بررسی TXT Record داخل DNS
(مناسب wildcard certificate)
🔒 TLS-ALPN Challenge
اعتبارسنجی از طریق TLS روی پورت 443
📌 یعنی Let’s Encrypt اول مالکیت domain را تأیید میکند، بعد SSL صادر میکند.
در پست بعدی میرویم سراغ گرفتن SSL برای Nginx با Certbot و bind کردن آن روی Nginx.
👍1
nginx-and-letsencrypt-certbot.pdf
2.5 MB
🔐 گرفتن SSL برای Nginx با Let’s Encrypt
اگر با Nginx کار میکنی، دیر یا زود به SSL و HTTPS میرسی.
توی فایل آموزشی جدید، قدمبهقدم توضیح دادم که چطور با Let’s Encrypt و Certbot برای Nginx SSL Certificate بگیریم و آن را روی Nginx bind کنیم.
داخل این فایل یاد میگیری:
✅ Let’s Encrypt چیست
✅ Certbot چه کاری انجام میدهد
✅ روشهای احراز هویت مثل HTTP Challenge و DNS Challenge چه تفاوتی دارند
✅ چطور SSL Certificate برای domain بگیریم
✅ چطور Certificate را روی Nginx config کنیم
✅ چطور HTTPS را تست کنیم
✅ چطور renewal را بررسی و مدیریت کنیم
✅ اگر خطا گرفتیم، از کجا troubleshooting را شروع کنیم
📌 این فایل فقط توضیح تئوری نیست.
داخلش commandها، configurationها، تستها و نکات عملی آورده شده تا بتوانی واقعاً روی سرور اجرا کنی و نتیجه بگیری.
اگر میخواهی Nginx را برای HTTPS آماده کنی و دقیق بفهمی پشت SSL گرفتن چه اتفاقی میافتد، این فایل میتواند یک راهنمای کاربردی و مرحلهبهمرحله برایت باشد.
📥 فایل را دانلود کن و کنار تمرینهای Nginx نگه دار.
اگر با Nginx کار میکنی، دیر یا زود به SSL و HTTPS میرسی.
توی فایل آموزشی جدید، قدمبهقدم توضیح دادم که چطور با Let’s Encrypt و Certbot برای Nginx SSL Certificate بگیریم و آن را روی Nginx bind کنیم.
داخل این فایل یاد میگیری:
✅ Let’s Encrypt چیست
✅ Certbot چه کاری انجام میدهد
✅ روشهای احراز هویت مثل HTTP Challenge و DNS Challenge چه تفاوتی دارند
✅ چطور SSL Certificate برای domain بگیریم
✅ چطور Certificate را روی Nginx config کنیم
✅ چطور HTTPS را تست کنیم
✅ چطور renewal را بررسی و مدیریت کنیم
✅ اگر خطا گرفتیم، از کجا troubleshooting را شروع کنیم
📌 این فایل فقط توضیح تئوری نیست.
داخلش commandها، configurationها، تستها و نکات عملی آورده شده تا بتوانی واقعاً روی سرور اجرا کنی و نتیجه بگیری.
اگر میخواهی Nginx را برای HTTPS آماده کنی و دقیق بفهمی پشت SSL گرفتن چه اتفاقی میافتد، این فایل میتواند یک راهنمای کاربردی و مرحلهبهمرحله برایت باشد.
📥 فایل را دانلود کن و کنار تمرینهای Nginx نگه دار.
❤3👍2
🔐 SSH Key-Based Authentication یعنی چی؟
معمولاً برای ورود به سرور با SSH از password استفاده میکنیم:
اما روش حرفهایتر این است که به جای password از SSH key استفاده کنیم.
در این روش دو کلید داریم:
ساخت key:
کپی کردن public key روی سرور:
بعد از آن میتوانیم بدون وارد کردن password وارد شویم:
مزیتها:
✅ امنتر از password
✅ مناسب برای server و DevOps
✅ کاربردی برای GitHub/GitLab
✅ مناسب برای automation و CI/CD
نکته مهم:
معمولاً برای ورود به سرور با SSH از password استفاده میکنیم:
ssh user@server-ip
اما روش حرفهایتر این است که به جای password از SSH key استفاده کنیم.
در این روش دو کلید داریم:
Private Key → روی سیستم خودمان میماند و نباید share شود.Public Key → روی سرور قرار میگیرد.ساخت key:
ssh-keygen -t ed25519 -C "your-email@example.com"
کپی کردن public key روی سرور:
ssh-copy-id user@server-ip
بعد از آن میتوانیم بدون وارد کردن password وارد شویم:
ssh user@server-ip
مزیتها:
✅ امنتر از password
✅ مناسب برای server و DevOps
✅ کاربردی برای GitHub/GitLab
✅ مناسب برای automation و CI/CD
نکته مهم:
Private Key مثل کلید اصلی خانه شماست؛ هیچوقت آن را برای کسی نفرستید.👍3❤1
🔐 چند نکته مهم برای SSH Hardening
اگر سرور Linux دارید، فقط راهاندازی SSH کافی نیست؛ باید آن را امنتر هم کنید.
چند کار مهم:
✅ استفاده از SSH Key به جای password
✅ غیرفعال کردن login مستقیم با root
✅ تغییر default port در صورت نیاز
✅ محدود کردن userهایی که اجازه SSH دارند
✅ فعال کردن firewall
✅ نصب ابزارهایی مثل Fail2Ban برای جلوگیری از brute-force
✅ بستن password authentication بعد از تست key login
مثلاً در فایل:
میتوانیم تنظیماتی مثل این داشته باشیم:
بعد هم SSH را restart میکنیم:
⚠️ نکته مهم: قبل از تغییر تنظیمات SSH، همیشه یک session باز نگه دارید تا اگر اشتباهی رخ داد، دسترسیتان به سرور قطع نشود.
📌 فایل آموزشی کامل SSH Hardening فردا داخل کانال قرار میگیرد.
اگر سرور Linux دارید، فقط راهاندازی SSH کافی نیست؛ باید آن را امنتر هم کنید.
چند کار مهم:
✅ استفاده از SSH Key به جای password
✅ غیرفعال کردن login مستقیم با root
✅ تغییر default port در صورت نیاز
✅ محدود کردن userهایی که اجازه SSH دارند
✅ فعال کردن firewall
✅ نصب ابزارهایی مثل Fail2Ban برای جلوگیری از brute-force
✅ بستن password authentication بعد از تست key login
مثلاً در فایل:
/etc/ssh/sshd_config
میتوانیم تنظیماتی مثل این داشته باشیم:
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
بعد هم SSH را restart میکنیم:
sudo systemctl restart ssh
⚠️ نکته مهم: قبل از تغییر تنظیمات SSH، همیشه یک session باز نگه دارید تا اگر اشتباهی رخ داد، دسترسیتان به سرور قطع نشود.
📌 فایل آموزشی کامل SSH Hardening فردا داخل کانال قرار میگیرد.
❤3
🛡️ Fail2Ban فقط برای SSH نیست!
لاگ سرویسها را بررسی میکند، الگوهای مشکوک را با
📌 نصب در Ubuntu/Debian:
نمونه jail برای SSH:
بررسی وضعیت:
کاربردها:
🔐 SSH
🌐 Nginx / Apache
📩 Mail Server
📁 FTP
⚙️ API Login Endpoint
⚠️ نکته مهم:
Fail2Ban جای firewall، rate limiting و secure config را نمیگیرد؛ فقط یک لایه دفاعی reactive بر اساس logهاست.
Fail2Ban یک ابزار Log-Based Intrusion Prevention است.لاگ سرویسها را بررسی میکند، الگوهای مشکوک را با
regex filter تشخیص میدهد و IP مهاجم را با iptables یا nftables موقتاً ban میکند.📌 نصب در Ubuntu/Debian:
sudo apt update
sudo apt install fail2ban -y
sudo systemctl enable --now fail2ban
نمونه jail برای SSH:
[sshd]
enabled = true
logpath = /var/log/auth.log
maxretry = 5
findtime = 10m
bantime = 1h
بررسی وضعیت:
sudo fail2ban-client status
sudo fail2ban-client status sshd
کاربردها:
🔐 SSH
🌐 Nginx / Apache
📩 Mail Server
📁 FTP
⚙️ API Login Endpoint
⚠️ نکته مهم:
Fail2Ban جای firewall، rate limiting و secure config را نمیگیرد؛ فقط یک لایه دفاعی reactive بر اساس logهاست.
❤2👍2🙏1
🤖 وقتی میگوییم AI Agent، خیلیها یاد ابزارهایی مثل Codex یا Claude Code میافتند.
اما Agentی که خودمان میسازیم فقط یک LLM نیست.
ما مشخص میکنیم:
🧠 چه Contextی ببیند 🛠 به چه Toolهایی دسترسی داشته باشد 🔄 چطور تصمیم بگیرد و Action انجام دهد 🗂 چه چیزی را در Memory نگه دارد 🔐 چه Permissionهایی داشته باشد 🛡 چه Guardrailهایی محدودش کنند
مجموعهی اینها همان «Agent Harness» است.
مثلاً در DevOps میتوانیم Agentی بسازیم که فقط داخل یک Kubernetes Namespace کار کند، لاگ و Event را بررسی کند و فقط Actionهای مشخصی انجام دهد.
خلاصه:
LLM = مغز Agent Harness = سیستم کنترل این مغز
و ترکیب این دو، یک Agent واقعی میسازد.
اما Agentی که خودمان میسازیم فقط یک LLM نیست.
ما مشخص میکنیم:
🧠 چه Contextی ببیند 🛠 به چه Toolهایی دسترسی داشته باشد 🔄 چطور تصمیم بگیرد و Action انجام دهد 🗂 چه چیزی را در Memory نگه دارد 🔐 چه Permissionهایی داشته باشد 🛡 چه Guardrailهایی محدودش کنند
مجموعهی اینها همان «Agent Harness» است.
مثلاً در DevOps میتوانیم Agentی بسازیم که فقط داخل یک Kubernetes Namespace کار کند، لاگ و Event را بررسی کند و فقط Actionهای مشخصی انجام دهد.
خلاصه:
LLM = مغز Agent Harness = سیستم کنترل این مغز
و ترکیب این دو، یک Agent واقعی میسازد.
❤1
🆘 بدترین زمان برای تمام شدن توکن؟
وسط یک باگ یا اینسیدنت؛ دقیقاً وقتی که بیشتر از همیشه به ایجنتت نیاز داری.
اینجاست که Free Buff میتونه بهعنوان پلن B به کارت بیاد.
🤖 یک ایجنت کدنویسی رایگان که از داخل ترمینال روی پروژه کار میکنه و به چند مدل مختلف دسترسی میده.
من کجا ازش استفاده میکنم؟
✅ بررسی و جمعکردن لاگها ✅ پیدا کردن فایلهای مرتبط ✅ خلاصهسازی وضعیت ✅ بررسی اولیه کد ✅ ساخت گزارش
اما برای کارهایی که نیاز به ریزنینگ عمیق دارن یا تصمیمهای حساس پروداکشن، ترجیح میدم از مدلهای قویتر استفاده کنم.
⚠️ یک نکته مهم:
رایگان بودن یعنی نباید هر دیتایی رو بدون بررسی واردش کنیم.
سکرت، توکن، اطلاعات حساس و ریپازیتوری خصوصی رو بدون بررسی سیاست داده وارد نکن.
📌 برای من، فریباف یعنی:
یک ایجنت پشتیبان خوب؛ نه لزوماً مغز اصلی operation.
وسط یک باگ یا اینسیدنت؛ دقیقاً وقتی که بیشتر از همیشه به ایجنتت نیاز داری.
اینجاست که Free Buff میتونه بهعنوان پلن B به کارت بیاد.
🤖 یک ایجنت کدنویسی رایگان که از داخل ترمینال روی پروژه کار میکنه و به چند مدل مختلف دسترسی میده.
من کجا ازش استفاده میکنم؟
✅ بررسی و جمعکردن لاگها ✅ پیدا کردن فایلهای مرتبط ✅ خلاصهسازی وضعیت ✅ بررسی اولیه کد ✅ ساخت گزارش
اما برای کارهایی که نیاز به ریزنینگ عمیق دارن یا تصمیمهای حساس پروداکشن، ترجیح میدم از مدلهای قویتر استفاده کنم.
⚠️ یک نکته مهم:
رایگان بودن یعنی نباید هر دیتایی رو بدون بررسی واردش کنیم.
سکرت، توکن، اطلاعات حساس و ریپازیتوری خصوصی رو بدون بررسی سیاست داده وارد نکن.
📌 برای من، فریباف یعنی:
یک ایجنت پشتیبان خوب؛ نه لزوماً مغز اصلی operation.
❤1
🔐 SSH Tunnel یعنی چی؟
فرض کن PostgreSQL روی سرور فقط از داخل همون سرور قابل دسترسیه:
بهجای Public کردن پورت دیتابیس، با SSH Tunnel یک مسیر امن میسازی:
📌 مسیر ارتباط:
SSH Tunnel برای دسترسی امن به سرویسهای داخلی مثل اینها هم کاربرد داره:
✅ Grafana ✅ Prometheus ✅ Redis ✅ Internal API ✅ Admin Panel
سه مدل مهم:
💡 برای یک DevOps Engineer، SSH فقط برای Login نیست؛ یک ابزار امن برای دسترسی به سرویسهای داخلی هم هست.
فرض کن PostgreSQL روی سرور فقط از داخل همون سرور قابل دسترسیه:
127.0.0.1:5432بهجای Public کردن پورت دیتابیس، با SSH Tunnel یک مسیر امن میسازی:
ssh -L 5432:localhost:5432 user@server
حالا روی سیستم خودت به این آدرس وصل میشی:localhost:5432📌 مسیر ارتباط:
Laptop ↓ SSH Tunnel ↓ Server ↓ PostgreSQLSSH Tunnel برای دسترسی امن به سرویسهای داخلی مثل اینها هم کاربرد داره:
✅ Grafana ✅ Prometheus ✅ Redis ✅ Internal API ✅ Admin Panel
سه مدل مهم:
-L ← Local Forwarding -R ← Remote Forwarding -D ← Dynamic Forwarding💡 برای یک DevOps Engineer، SSH فقط برای Login نیست؛ یک ابزار امن برای دسترسی به سرویسهای داخلی هم هست.
❤4