🔐 گرفتن 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 نگه دار.

🔐 SSH Key-Based Authentication یعنی چی؟

معمولاً برای ورود به سرور با 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 مثل کلید اصلی خانه شماست؛ هیچ‌وقت آن را برای کسی نفرستید.

🔐 چند نکته مهم برای 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 فردا داخل کانال قرار می‌گیرد.

🛡️ Fail2Ban فقط برای SSH نیست!

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هاست.

🤖 وقتی می‌گوییم 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 واقعی می‌سازد.

🆘 بدترین زمان برای تمام شدن توکن؟
وسط یک باگ یا اینسیدنت؛ دقیقاً وقتی که بیشتر از همیشه به ایجنتت نیاز داری.
اینجاست که Free Buff می‌تونه به‌عنوان پلن B به کارت بیاد.
🤖 یک ایجنت کدنویسی رایگان که از داخل ترمینال روی پروژه کار می‌کنه و به چند مدل مختلف دسترسی می‌ده.
من کجا ازش استفاده می‌کنم؟
✅ بررسی و جمع‌کردن لاگ‌ها ✅ پیدا کردن فایل‌های مرتبط ✅ خلاصه‌سازی وضعیت ✅ بررسی اولیه کد ✅ ساخت گزارش
اما برای کارهایی که نیاز به ریزنینگ عمیق دارن یا تصمیم‌های حساس پروداکشن، ترجیح می‌دم از مدل‌های قوی‌تر استفاده کنم.
⚠️ یک نکته مهم:
رایگان بودن یعنی نباید هر دیتایی رو بدون بررسی واردش کنیم.
سکرت، توکن، اطلاعات حساس و ریپازیتوری خصوصی رو بدون بررسی سیاست داده وارد نکن.
📌 برای من، فری‌باف یعنی:
یک ایجنت پشتیبان خوب؛ نه لزوماً مغز اصلی operation.

‏🔐 SSH Tunnel یعنی چی؟
‏فرض کن PostgreSQL روی سرور فقط از داخل همون سرور قابل دسترسیه:
127.0.0.1:5432
‏به‌جای Public کردن پورت دیتابیس، با SSH Tunnel یک مسیر امن می‌سازی:
ssh -L 5432:localhost:5432 user@server
‏حالا روی سیستم خودت به این آدرس وصل می‌شی:
localhost:5432
‏📌 مسیر ارتباط:
Laptop ↓ SSH Tunnel ↓ Server ↓ PostgreSQL
‏SSH Tunnel برای دسترسی امن به سرویس‌های داخلی مثل این‌ها هم کاربرد داره:
‏✅ Grafana ‏✅ Prometheus ‏✅ Redis ‏✅ Internal API ‏✅ Admin Panel
‏سه مدل مهم:
-L ← Local Forwarding -R ← Remote Forwarding -D ← Dynamic Forwarding
‏💡 برای یک DevOps Engineer، SSH فقط برای Login نیست؛ یک ابزار امن برای دسترسی به سرویس‌های داخلی هم هست.

🔥 توکن ایجنت رو بیخودی نسوزون
🤖 اگه با AI کد می‌زنی، احتمالاً داری برای یه سری کار Token مصرف می‌کنی که اصلاً لازم نیست Agent انجامشون بده.
مثلاً بعد از هر تغییر بهش می‌گی:
«برو روی سرور، نسخه جدید رو اجرا کن، Log رو چک کن، ببین سرویس بالا اومده یا نه…»
و این چرخه هر بار تکرار می‌شه.
درحالی‌که این بخش می‌تونه کاملاً اتوماتیک باشه.
کدت رو Push می‌کنی و یک Pipeline خودش:
⚙️ Test می‌کنه 📦 Build می‌کنه 🚀 Deploy می‌کنه
این همون CI/CD در DevOpsه.
حالا Agent فقط نتیجه رو چک می‌کنه:
✅ Deploy موفق شد؟ تمام. ❌ Fail شد؟ همون Failure رو تحلیل کن.
تازه History تمام Deployها و تغییراتت هم باقی می‌مونه.
📌 هر کاری که Agent می‌تونه انجام بده، لزوماً نباید Agent انجامش بده.
کارهای تکراری رو اتوماتیک کن؛ Token ایجنتت رو برای جایی نگه دار که واقعاً به فکر کردن نیاز داری.

🔥 گیت‌لب فقط جای نگهداری کد نیست!
یکی از مهم‌ترین قابلیت‌های گیت‌لب، سیستم CI/CD داخلی آن است.
یعنی به‌جای انجام دستی تست، ساخت و دیپلوی، یک پایپ‌لاین تعریف می‌کنی و گیت‌لب خودش این مسیر را اجرا می‌کند.
مثلاً:
💻 توسعه‌دهنده کد را روی گیت‌لب Push می‌کند.
🧪 تست‌ها خودکار اجرا می‌شوند.
📦 ایمیج Docker ساخته می‌شود.
🗂 ایمیج داخل Container Registry گیت‌لب ذخیره می‌شود.
🚀 نسخه جدید روی سرور یا Kubernetes دیپلوی می‌شود.
این فرایند معمولاً داخل فایل gitlab-ci.yml تعریف می‌شود.
⚙️ با CI/CD گیت‌لب می‌توانی:
✅ Job و Stage تعریف کنی.
✅ Pipeline را براساس Branch یا Merge Request کنترل کنی.
✅ از Runner برای اجرای Jobها استفاده کنی.
✅ Variable و Secret مدیریت کنی.
✅ Artifact و Cache داشته باشی.
✅ Docker Image را داخل Registry گیت‌لب ذخیره کنی.
✅ روی Staging و Production دیپلوی کنی.
✅ Pipeline دستی یا زمان‌بندی‌شده بسازی.
✅ تاریخچه Buildها و Deployها را ببینی.
📌 مسیر کلی:
۱. کد ۲. تست ۳. ساخت ایمیج ۴. ذخیره در رجیستری ۵. دیپلوی
همه این مراحل می‌توانند اتوماتیک، قابل تکرار و قابل ردیابی انجام شوند.

🤖 اگه با Claude Code یا Codex روی پروژه واقعی کار کرده باشی، احتمالاً این مشکل رو دیدی:
هر بار باید دوباره توضیح بدی پروژه چطور ساخته شده، قبلاً چه تصمیم‌هایی گرفتید و دفعه قبل کجا متوقف شدید.
مشکل فقط Prompt نیست.
🧠 AI حافظه‌ی ماندگاری از پروژه‌ات نداره.
تازه هر بار که حجم زیادی از اطلاعات پروژه رو دوباره وارد می‌کنی، Context بیشتری می‌فرستی و Token بیشتری هم مصرف می‌شه.
اینجاست که ابزاری مثل:
Graphiti
جالب می‌شه.
Graphiti کمک می‌کنه اطلاعات مهم پروژه، مثل تصمیم‌های قبلی، ارتباط سرویس‌ها و تغییرات انجام‌شده، بیرون از گفت‌وگوی فعلی نگه داشته بشن.
بعد Agent به‌جای اینکه هر بار همه‌چیز رو از اول بخونه، فقط اطلاعات مرتبط رو پیدا می‌کنه.
📌 یعنی: Context تمیزتر اطلاعات اضافی کمتر و در بعضی سناریوها مصرف Token کمتر
اما اصل ماجرا فقط Token نیست.
AI باید اطلاعات درست رو، دقیقاً وقتی بهش نیاز داره، دریافت کنه.
این همون چیزیه که در Context Engineering درباره‌ش صحبت می‌کنیم.

🤖 اگه بخوای AI Agentها رو روی Kubernetes اجرا کنی، kagent یکی از پروژه‌هاییه که باید بشناسی.
وقتی خودمون یک Agent می‌سازیم، فقط وصل کردن LLM به چند Tool کافی نیست.
باید بدونیم:
Agent کجا اجرا بشه؟ Toolها چطور در اختیارش قرار بگیرن؟ چطور به Kubernetes دسترسی داشته باشه؟ Memory، Observability و Permissionها چطور مدیریت بشن؟
اینجاست که kagent وارد می‌شه.
kagent یک Kubernetes-native platform برای AI Agentهاست که اجازه می‌ده Agentها رو مثل Resourceهای Kubernetes مدیریت کنیم.
برای Agent می‌تونیم مشخص کنیم:
🧠 از چه Model و Runtimeای استفاده کنه 🛠️ چه Toolهایی داشته باشه 🔌 به چه MCP Serverهایی وصل بشه 🔐 چه Permissionهایی داشته باشه 💾 Memory چطور مدیریت بشه 📊 و اجرای Agent چطور Observe بشه
در نسخه‌های جدید، مفهوم Agent Harness هم مهم‌تر شده؛ لایه‌ای که Runtime و سازوکار اجرای Agent رو مشخص می‌کنه.
در واقع kagent فقط یک Agent آماده نیست؛ هدفش فراهم کردن زیرساخت اجرای Agentها روی Kubernetes به شکل Cloud Nativeه.
📌 اگر Kubernetes بلدی و وارد دنیای AI Agentها شدی، kagent جاییه که این دو دنیا به هم می‌رسن.

🤖 اگر با ایجنت‌های هوش مصنوعی کار می‌کنی، این حداقل‌های امنیتی رو جدی بگیر.
ایجنت فقط جواب متنی نمی‌ده.
می‌تونه ابزار اجرا کنه، به سرویس‌های مختلف وصل بشه، فایل بخونه، دستور اجرا کنه، نتیجه رو بررسی کنه و اگر یک مسیر جواب نداد، مسیر دیگه‌ای رو امتحان کنه.
پس همون قابلیتی که ایجنت رو قدرتمند می‌کنه، اگر محدود نشه، می‌تونه تبدیل به ریسک امنیتی بشه.
ــــــــــــــــــــ
۱️⃣ ایجنت رو فقط با پرامپت محدود نکن
اینکه داخل پرامپت بنویسی:
«فقط اطلاعات عمومی رو بخون»
یا
«به این سرویس دست نزن»
به‌تنهایی کنترل امنیتی محسوب نمی‌شه.
ایجنت باید در سطح واقعی دسترسی هم محدود باشه.
اگر فقط قرار است اطلاعات عمومی وب را بخونه، نباید دسترسی به شِل، سرور، فایل‌های داخلی یا اطلاعات ورود اضافه داشته باشه.
اصل مهم:
«حداقل سطح دسترسی»
یعنی ایجنت فقط همون دسترسی‌ای رو داشته باشه که برای انجام همون کار لازم داره.
ــــــــــــــــــــ
۲️⃣ دسترسی شبکه ایجنت رو محدود کن
اگر ایجنت فقط باید به چند سرویس مشخص وصل بشه، لازم نیست به کل اینترنت یا شبکه داخلی دسترسی داشته باشه.
مشخص کن دقیقاً به چه مقصدهایی اجازه اتصال داره.
ایجنت نباید آزاد باشه هر آدرس، پورت یا سرویس داخلی رو امتحان کنه.
ــــــــــــــــــــ
۳️⃣ برای کارهای حساس، تأیید انسان بذار
همه‌چیز نباید خودکار انجام بشه.
خواندن یک صفحه عمومی شاید نیاز به تأیید نداشته باشه.
اما اگر ایجنت خواست:
• فایل بنویسه • دستور اجرا کنه • از اطلاعات ورود استفاده کنه • سرویس جدیدی رو صدا بزنه • برنامه رو منتشر کنه • زیرساخت رو تغییر بده
بهتره متوقف بشه و تأیید انسان بگیره.
ــــــــــــــــــــ
۴️⃣ تعداد تلاش‌های دوباره رو محدود کن
یکی از قابلیت‌های ایجنت اینه که اگر یک راه جواب نداد، راه دیگه‌ای رو امتحان کنه.
اما این تلاش نباید نامحدود باشه.
مثلاً اگر چند بار با عدم دسترسی روبه‌رو شد، نباید شروع کنه ده‌ها آدرس، پارامتر یا مسیر مختلف رو پشت سر هم امتحان کردن.
باید از قبل مشخص باشه:
• چند بار اجازه تلاش مجدد داره • تا چه مدت می‌تونه ادامه بده • چه چیزهایی رو اجازه داره تغییر بده • و چه زمانی باید متوقف بشه
ــــــــــــــــــــ
۵️⃣ همه فعالیت‌های ایجنت رو ثبت کن
باید بتونی ببینی:
• به کجا وصل شده • چه ابزاری استفاده کرده • چه درخواستی فرستاده • چه پاسخی گرفته • و بعد از خطا یا مسدود شدن چه تصمیمی گرفته
اگر این اطلاعات ثبت نشن، ممکنه بعداً حتی متوجه نشی ایجنت دقیقاً چه کاری انجام داده.
ــــــــــــــــــــ
حالا از طرف مقابل ماجرا نگاه کنیم.
اگر خودت یک سرویس عمومی یا رابط برنامه‌نویسی عمومی داری، باید فرض کنی کاربر روبه‌رو همیشه انسان نیست.
ممکنه یک ایجنت باشه که بعد از مسدود شدن، در چند ثانیه چند مسیر دیگه رو امتحان کنه.
ــــــــــــــــــــ
۶️⃣ هر درخواست رو در سمت سرور بررسی کن
اینکه یک مسیر داخل رابط کاربری دیده نمی‌شه، امنیت نیست.
اینکه آدرسش مخفیه هم امنیت نیست.
برای هر درخواست باید دوباره بررسی بشه که:
کاربر کیه؟
و دقیقاً اجازه انجام چه کاری رو داره؟
ــــــــــــــــــــ
۷️⃣ سرویس عمومی رو از سرویس‌های داخلی جدا کن
اگر سرویس عمومی دچار مشکل شد، نباید از همون مسیر بشه به بخش‌های حساس داخلی رسید.
مثلاً:
• سرویس‌های داخلی • فایل‌های داخلی • پایگاه‌داده مدیریتی • اطلاعات محرمانه • زیرساخت
باید بین بخش عمومی و داخلی مرز شبکه‌ای مشخص وجود داشته باشه.
ــــــــــــــــــــ
۸️⃣ خود سرویس عمومی هم حداقل دسترسی رو داشته باشه
اگر فقط باید اطلاعات بخونه، اجازه نوشتن بهش نده.
اگر فقط به یک پایگاه‌داده نیاز داره، اطلاعات ورودی‌ای بهش نده که بتونه باهاش به چند سرویس دیگه هم وصل بشه.
از اول محدوده خسارت رو کوچک نگه دار.
ــــــــــــــــــــ
۹️⃣ فقط ورود ناموفق رو بررسی نکن؛ رفتار رو ببین
مثلاً یک کاربر یا برنامه:
چند بار با عدم دسترسی روبه‌رو می‌شه،
بعد آدرس رو تغییر می‌ده،
پارامترها رو عوض می‌کنه،
مسیرهای مختلف رو امتحان می‌کنه،
و در زمان کوتاه تعداد زیادی درخواست متفاوت می‌فرسته.
این می‌تونه نشونه یک سیستم خودکار باشه که داره بعد از هر شکست، مسیر جدیدی رو امتحان می‌کنه.
پس باید روی تعداد درخواست‌ها، رفتار غیرعادی و الگوهای مشکوک نظارت داشته باشی.
ــــــــــــــــــــ
🔟 مدیریت اطلاعات محرمانه رو جدی بگیر
رمز عبور، کلید دسترسی و توکن نباید داخل این بخش‌ها باقی بمونن:
• کد برنامه • مخزن کد • بخش عمومی برنامه • گزارش‌های قابل مشاهده • پاسخ سرویس
و اگر یک اطلاعات ورود لو رفت، بهتره:
• دسترسی محدودی داشته باشه • عمر کوتاهی داشته باشه • و سریع قابل تعویض باشه
ــــــــــــــــــــ
جمع‌بندی:
در دنیای ایجنت‌های هوش مصنوعی فقط این مهم نیست که به ایجنت بگی:
«چه کاری نکن.»

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

اگر با Claude Code یا Codex روی پروژه‌های بزرگ کار می‌کنی، یکی از چیزهایی که می‌تونه کلی Context و Token اضافه مصرف کنه اینه که Agent هر بار دوباره مجبور بشه Codebase رو بگرده و بفهمه:
این Function از کجا Call شده؟ این Service به چی وصله؟ این Feature توی چه Fileهایی پخش شده؟ برای تغییر این بخش باید کجای Repository رو بررسی کنم؟
اینجاست که Graphify می‌تونه خیلی کمک‌کننده باشه.
Graphify از Codebase شما یک Knowledge Graph می‌سازه؛ یعنی Functionها، Classها، Componentها، Importها، Callها و Dependencyهای پروژه رو استخراج می‌کنه و ارتباط بین اون‌ها رو داخل یک Graph قرار می‌ده.
نکته جذابش؟
برای تحلیل Code لازم نیست API Key داشته باشی و لازم نیست LLM جدا نصب کنی. Code Parsing به‌صورت Local انجام می‌شه.
مثلاً روی یکی از پروژه‌های من، Graphify حدود 700 Source File رو بررسی کرد و خروجی این بود:
• بیش از 7,000 Node
• بیش از 16,000 Edge
• صدها Community
• 0 AI Token برای ساخت Graph
چرا این‌قدر سریع؟
چون قرار نیست مثل یک LLM تمام Fileها رو بخونه و معنی Code رو تحلیل کنه. ساختار Code رو Parse می‌کنه و از روی Function، Class، Import، Call و Dependencyها Graph رو می‌سازه.
نصب روی Ubuntu
اول مطمئن شو Python 3.10+ داری:
python3 --version
بعد uv رو نصب کن:
curl -LsSf https://astral.sh/uv/install.sh | sh
حالا Graphify:
uv tool install graphifyy
دقت کن Package با دو تا y نصب می‌شه:
graphifyy
ولی Command اینه:
graphify
بعد برو داخل Root پروژه:
cd /path/to/project
برای Claude Code:
graphify install --project --platform claude
برای Codex:
graphify install --project --platform codex
اگر هر دوتاشون رو استفاده می‌کنی، هر دو Command رو اجرا کن.
حالا Claude Code رو از Root پروژه باز کن و داخلش بزن:
/graphify .
Graphify شروع می‌کنه Repository رو Scan کردن، Source Fileها رو Parse می‌کنه، Relationshipها رو درمیاره و Graph پروژه رو می‌سازه.
خروجی داخل این Directory ذخیره می‌شه:
graphify-out/
و معمولاً این Fileها رو داری:
graph.html
GRAPH_REPORT.md
graph.json
graph.html برای دیدن Interactive Graph هست و graph.json همون Dataای هست که Agent می‌تونه برای Query کردن ساختار Codebase ازش استفاده کنه.
نکته مهم اینه که اگر هم Claude Code و هم Codex روی همین Project تنظیم شده باشن، هر دو می‌تونن از همین Graph استفاده کنن.
یعنی یک بار Codebase رو Map می‌کنی و بعد هر دو Agent یک نقشه از ساختار پروژه دارن.
مثلاً به Codex می‌گی:
مسیر Start شدن Lab رو از Student Portal تا VM Provisioning پیدا کن.
به‌جای این‌که از صفر کل Repository رو زیرورو کنه، می‌تونه اول Graphify رو Query کنه، محدوده مرتبط رو پیدا کنه و بعد فقط Source Codeهای لازم رو بررسی کنه.
فقط یک نکته:
Graphify جای Source Code رو نمی‌گیره.
بعضی Relationshipها ممکنه INFERRED باشن و باید دوباره با Source Code واقعی Verify بشن.

🤖 وقتی Skill داریم، دیگه CI/CD به چه درد می‌خوره؟
با ورود AI Agentها این سؤال خیلی مهم شده.
فرض کن برای Agent یک Skill ساختی.
Skill به Agent یاد می‌ده:
Test
Build
Scan
Tag
Deploy
پس شاید فکر کنی دیگه Pipeline لازم نیست.
اما این دو تا یک کار نمی‌کنن.
🧠 Skill
به Agent می‌گه یک کار رو چطور انجام بده.
مثلاً:
«قبل از Deploy، Security Scan انجام بده.»
🛡 CI/CD
مشخص می‌کنه چه چیزی اجازه داره وارد مرحله بعد بشه.
مثلاً:
Critical CVE > 0
⬇️
Pipeline Failed
یا:
Tests Failed
⬇️
No Deploy
یا برای Production:
Human Approval Required
اینجا دیگه تصمیم با Agent نیست.
Rule سازمان توسط Pipeline اجرا و Enforce می‌شه.
معماری می‌تونه این شکلی باشه:
AI Agent
⬇️
Pull Request
⬇️
CI/CD
⬇️
Security Gates
⬇️
Registry
⬇️
Deploy
Agent می‌تونه Error رو بخونه.
Fix پیشنهاد بده.
حتی Patch بسازه.
اما Fix دوباره باید از همون Gateها عبور کنه.
📌 Skill = Runbook برای Agent
📌 CI/CD = Automation + Enforcement
ورود AI باعث حذف CI/CD نمی‌شه.
اتفاقاً نقش CI/CD به‌عنوان Gate و Policy Enforcement مهم‌تر می‌شه.

GitLab داره استفاده از AI Agent داخل DevOps رو جدی‌تر می‌کنه.
با GitLab MCP Server، Agentهایی مثل Codex یا Claude Code می‌تونن از طریق MCP به GitLab وصل بشن و به Toolهای Repository، Merge Request و CI/CD دسترسی داشته باشن.
یعنی برای هر کار لازم نیست جداگانه GitLab API یا Tool اختصاصی بنویسیم.
MCP خودش Agent نیست؛ فقط Tool و Context رو در اختیار Agent می‌ذاره. Agent تصمیم می‌گیره برای رسیدن به Goal از چه Toolی استفاده کنه.
مثلاً Pipeline Fail می‌شه و Agent می‌تونه: • Job Log رو بخونه • Repository و Manifest رو بررسی کنه • Root Cause رو پیدا کنه • Fix پیشنهاد بده • Merge Request بسازه
اگر Kubernetes MCP هم داشته باشیم، Agent می‌تونه وضعیت Pod، Deployment و Logها رو هم بررسی کنه.
نکته مهم Security هست: Agent نباید دسترسی نامحدود داشته باشه.
Least Privilege + Tool Restriction + Human Approval
اینجاست که DevOps وارد دنیای Agentها می‌شه؛ چیزی که بهش Agentic DevOps می‌گیم.

در Kubernetes لازم نیست همه‌ی Podها دقیقاً با یک Runtime configuration اجرا شوند.
با RuntimeClass می‌توانیم مشخص کنیم هر Pod با کدام Runtime Handler اجرا شود؛ مثلاً Podهای معمولی با runtime پیش‌فرض و بعضی workloadهای خاص با Sysbox.
🔹 Sysbox چه چیزی به ما می‌دهد؟
Sysbox یک Container Runtime تخصصی است که Container را بیشتر شبیه یک Virtual Host سبک می‌کند.
یعنی داخل Container می‌توانیم workloadهایی مثل:
systemd
Docker daemon
Kubernetes / K3s
و حتی Containerهای دیگر را اجرا کنیم؛ بدون اینکه مجبور باشیم Pod را به شکل معمول privileged اجرا کنیم.
نکته مهم‌تر این است که Sysbox از User Namespace برای Isolation استفاده می‌کند؛ یعنی کاربری که داخل Container ظاهراً root است، روی Host دسترسی Root واقعی ندارد.
در Kubernetes کافی است برای Pod موردنظر RuntimeClass مربوط به Sysbox را انتخاب کنیم:
spec:
runtimeClassName: sysbox-runc
hostUsers: false
و بقیه‌ی Podهای کلاستر می‌توانند همچنان با Runtime پیش‌فرض اجرا شوند.