بلاگ هوش‌گراف

استقرار پروژه، DevOps و زیرساخت ابری برای تیم‌های ایرانی

دستورات لینوکس / لینوکس 2 دقیقه مطالعه

۳۰ دستور ضروری لینوکس برای DevOps (با مثال عملی)

راهنمای کاربردی دستورات لینوکس برای عیب‌یابی، دیپلوی و مدیریت سرور؛ از ls و grep تا systemctl و rsync.

هوش‌گراف 28 تیر 1405

اگر تازه وارد مسیر DevOps شده‌اید یا روی سرور لینوکس کار می‌کنید، بخش بزرگی از روزتان با ترمینال می‌گذرد. هدف این راهنما معرفی دستورات ضروری لینوکس است که واقعاً در عیب‌یابی، دیپلوی و نگهداری سرویس‌ها به کار می‌آیند؛ نه فهرستی بی‌پایان از گزینه‌هایی که شاید هرگز نبینید.

تمرکز ما روی درک «چه زمانی» و «چرا» است. هر دستور با مثال عملی، خروجی تقریبی و اشتباه رایج همراه است تا بتوانید در لحظه فشار production هم تصمیم درست بگیرید.

پیمایش فایل‌سیستم: ls، cd، pwd، tree

همیشه با دانستن مسیر فعلی شروع کنید. دستور pwd مسیر مطلق را نشان می‌دهد و از سردرگمی بین دایرکتوری‌ها جلوگیری می‌کند. با cd بین مسیرها جابه‌جا می‌شوید؛ cd – به مسیر قبلی برمی‌گردد و برای کار سریع بین دو پوشه مفید است.

pwd
ls -lah
cd /var/www && ls -lt

گزینه -lah در ls اندازه خوانا، فایل‌های مخفی و جزئیات مالکیت را می‌دهد. برای پروژه‌های بزرگ، مرتب‌سازی بر اساس زمان ویرایش (ls -lt) کمک می‌کند آخرین تغییر را پیدا کنید. اگر tree نصب باشد، ساختار پوشه‌ها را یک‌جا می‌بینید؛ در غیر این صورت find . -maxdepth 2 -type d جایگزین قابل‌قبولی است.

جست‌وجو: find و grep

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

find /var/log -name '*.log' -mtime -1
grep -Rni 'error' /var/log/nginx/ --include='*.log' | head

در grep گزینه -i حروف بزرگ/کوچک را نادیده می‌گیرد، -n شماره خط می‌دهد و -R بازگشتی است. برای لاگ‌های بزرگ از rg (ripgrep) یا journalctl استفاده کنید تا سریع‌تر باشید. اشتباه رایج: جست‌وجوی بدون محدودیت روی کل دیسک که I/O را اشباع می‌کند؛ همیشه مسیر را محدود کنید.

پروسس و منابع: ps، top، htop، free، df، du

وقتی سرویس کند است، اول بفهمید CPU، RAM یا دیسک مقصر است. free -h وضعیت حافظه را نشان می‌دهد. df -h پر شدن پارتیشن‌ها را می‌گوید و du -sh * مشخص می‌کند کدام پوشه حجم گرفته است.

free -h
df -h
du -sh /var/lib/docker/* 2>/dev/null | sort -h | tail

با ps aux | grep nginx پروسس مرتبط را می‌بینید. top یا htop برای مانیتور لحظه‌ای است. اگر load average بالا و CPU idle زیاد است، ممکن است مشکل I/O wait باشد؛ ستون wa در top را چک کنید.

مجوزها: chmod، chown، umask

بسیاری از خطاهای «Permission denied» به مالکیت اشتباه وب‌سرور یا کانتینر برمی‌گردد. chown کاربر و گروه را عوض می‌کند و chmod حالت دسترسی را. روی فایل‌های حساس مثل کلید SSH معمولاً 600 و برای پوشه .ssh مقدار 700 مناسب است.

sudo chown -R www-data:www-data /var/www/app
chmod 600 ~/.ssh/id_ed25519
chmod 700 ~/.ssh

آرشیو و انتقال: tar، scp، rsync

tar برای بسته‌بندی و فشرده‌سازی، scp برای کپی ساده روی SSH و rsync برای همگام‌سازی کارآمد است. rsync با –delete باید با احتیاط استفاده شود چون فایل مقصد را حذف می‌کند.

tar -czf backup.tgz ./app
rsync -avz ./app/ user@server:/var/www/app/

شبکه: ss، curl، ping

به‌جای netstat قدیمی از ss -tulpn استفاده کنید تا ببینید چه سرویسی روی چه پورتی listen می‌کند. curl -I هدر HTTP را نشان می‌دهد و برای تست reverse proxy عالی است.

ss -tulpn | grep :80
curl -I https://example.com

سرویس و لاگ: systemctl و journalctl (مرور)

برای دیدن وضعیت سرویس: systemctl status nginx. برای دنبال کردن لاگ: journalctl -u nginx -f. جزئیات کامل این دو ابزار در مقاله جداگانه آمده است؛ اینجا فقط بدانید بدون آن‌ها عیب‌یابی سرویس ناقص می‌ماند.

متن‌کاوی سبک: awk، sed، cut

برای استخراج ستون از خروجی دستورات، cut و awk کافی‌اند. sed برای جایگزینی سریع در فایل‌هاست؛ اما روی production ترجیحاً با نسخه پشتیبان یا در pipeline امن کار کنید.

df -h | awk 'NR==1 || /\/$/ {print}'
sed -n '1,20p' /etc/hosts

مشاهده فایل‌های بزرگ: less و tail -f

less برای حرکت در فایل بدون بار کردن همه محتواست. tail -f برای دنبال کردن لاگ زنده است. ترکیب با grep لحظه‌ای: tail -f app.log | grep –line-buffered ERROR

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

نکات عملی بیشتر درباره دستورات لینوکس

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

یک عادت خوب این است که برای هر سناریوی پرتکرار یک runbook کوتاه داشته باشید: علائم مشکل، دستور تشخیص، اقدام اصلاحی، و معیار موفقیت. این runbook لازم نیست رسمی باشد؛ حتی یک فایل Markdown در ریپو هم کافی است تا تیم یکسان عمل کند.

در محیط‌های ایران، محدودیت شبکه، latency رجیستری و قطعی لحظه‌ای DNS هم باید در runbook بیاید. اگر دستوری به اینترنت وابسته است، مسیر جایگزین یا کش محلی را از قبل مشخص کنید.

اشتباهات رایجی که باید از آن‌ها دوری کنید

  • کپی‌کردن دستور از اینترنت بدون فهم پارامترها
  • اجرای دستور مخرب روی production بدون بکاپ
  • نادیده گرفتن لاگ و فقط نگاه به پیام خطای اول
  • تغییر همزمان چند لایه (شبکه + سرویس + فایروال) بدون جداسازی تست
  • ذخیره secret داخل ریپو یا اسکریپت‌های عمومی

چک‌لیست جمع‌بندی

قبل از بستن کار روی دستورات لینوکس، این موارد را مرور کنید: آیا تغییر مستند شد؟ آیا rollback مشخص است؟ آیا مانیتورینگ یا حداقل یک healthcheck ساده وضعیت را نشان می‌دهد؟ آیا دسترسی‌ها حداقل لازم هستند؟ اگر پاسخ هر کدام منفی است، کار را تمام‌شده فرض نکنید.

یادگیری عمیق زمانی رخ می‌دهد که بعد از هر حادثه، یک یادداشت کوتاه بنویسید: چه دیدید، چه فرضی اشتباه بود، و دفعه بعد چه می‌کنید. این چرخه از ده‌ها دوره آموزشی سطحی مؤثرتر است.

نکات عملی بیشتر درباره دستورات لینوکس

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

یک عادت خوب این است که برای هر سناریوی پرتکرار یک runbook کوتاه داشته باشید: علائم مشکل، دستور تشخیص، اقدام اصلاحی، و معیار موفقیت. این runbook لازم نیست رسمی باشد؛ حتی یک فایل Markdown در ریپو هم کافی است تا تیم یکسان عمل کند.

در محیط‌های ایران، محدودیت شبکه، latency رجیستری و قطعی لحظه‌ای DNS هم باید در runbook بیاید. اگر دستوری به اینترنت وابسته است، مسیر جایگزین یا کش محلی را از قبل مشخص کنید.

اشتباهات رایجی که باید از آن‌ها دوری کنید

  • کپی‌کردن دستور از اینترنت بدون فهم پارامترها
  • اجرای دستور مخرب روی production بدون بکاپ
  • نادیده گرفتن لاگ و فقط نگاه به پیام خطای اول
  • تغییر همزمان چند لایه (شبکه + سرویس + فایروال) بدون جداسازی تست
  • ذخیره secret داخل ریپو یا اسکریپت‌های عمومی

چک‌لیست جمع‌بندی

قبل از بستن کار روی دستورات لینوکس، این موارد را مرور کنید: آیا تغییر مستند شد؟ آیا rollback مشخص است؟ آیا مانیتورینگ یا حداقل یک healthcheck ساده وضعیت را نشان می‌دهد؟ آیا دسترسی‌ها حداقل لازم هستند؟ اگر پاسخ هر کدام منفی است، کار را تمام‌شده فرض نکنید.

یادگیری عمیق زمانی رخ می‌دهد که بعد از هر حادثه، یک یادداشت کوتاه بنویسید: چه دیدید، چه فرضی اشتباه بود، و دفعه بعد چه می‌کنید. این چرخه از ده‌ها دوره آموزشی سطحی مؤثرتر است.

نظرات

هنوز نظری ثبت نشده. دیدگاه‌تان را بنویسید.

ثبت نظر

ایمیل شما منتشر نمی‌شود. فیلدهای ضروری علامت * دارند.