وب‌سرور و سرو فایل‌های استاتیک با NGINX

وب‌سرور چه می‌کند؟

تا این‌جای هفته، همیشه کسی دیگر پاسخگو بود — درخواست می‌فرستادیم و سرورهای دیگر جواب می‌دادند. حالا وقتش رسیده خودمان یک سرور بسازیم. وب‌سرور برنامه‌ای است که روی یک پورت (معمولاً 80 یا 443) گوش می‌دهد، به درخواست‌ها پاسخ می‌دهد، و در ساده‌ترین حالتش، فایل‌های استاتیک (HTML، CSS، JS، تصویر) را از دیسک می‌خواند و همان را برمی‌گرداند. NGINX یکی از پرکاربردترین وب‌سرورها در دنیای DevOps است؛ هم سبک و سریع است و هم در همین هفته چند بار دیگر با آن کار خواهیم کرد — به‌عنوان Reverse Proxy و Load Balancer.

نصب و وضعیت سرویس

1sudo apt update && sudo apt install nginx
2systemctl status nginx.service
3ss -tulpn | grep :80

بعد از نصب، NGINX خودش را به‌صورت سرویس بالا می‌آورد و روی پورت 80 گوش می‌دهد. از این‌جا به بعد، هر وقت پیکربندی را تغییر دادید، دو دستور زیر را اجرا کنید:

1sudo nginx -t
2sudo systemctl reload nginx.service
  • nginx -t پیکربندی را از نظر درستی چک می‌کند — همیشه پیش از Reload این را بزنید، تا با یک پیکربندی خراب، سرویس را از کار نیندازید.
  • reload پیکربندی جدید را اعمال می‌کند بدون این‌که اتصال‌های فعال را قطع کند؛ فقط اگر سرویس واقعاً خاموش است، سراغ start بروید.

ساختار پیکربندی

پیکربندی NGINX از بلوک‌هایی به نام block تشکیل شده. دو نوع block در این هفته اهمیت دارند:

  • http — تنظیمات کلی سرور وب؛ در Ubuntu، فایل‌های آن معمولاً در /etc/nginx/ قرار دارند.
  • server — برای هر سایت یا دامنه یک block جدا؛ همین‌جا مشخص می‌شود روی چه پورتی گوش می‌دهد، دامنه‌اش چیست و محتوا از کجا باید بیاید.

در Ubuntu، هر server block در یک فایل جدا داخل /etc/nginx/sites-available/ نوشته می‌شود و با یک symlink در /etc/nginx/sites-enabled/ فعال می‌شود. این الگوی جدا نگه‌داشتن «پیکربندی آماده» از «پیکربندی فعال» را در ابزارهای دیگر هم ممکن است ببینید.

تمرین: سرو یک صفحه‌ی استاتیک

اول یک فایل استاتیک ساده می‌سازیم:

1echo '<h1>Hello from NGINX</h1>' | sudo tee /var/www/html/index.html >/dev/null

بعد فایل پیش‌فرض /etc/nginx/sites-available/default را باز کنید و محتوایش را به این شکل ساده کنید تا این server block را داشته باشد:

 1server {
 2    listen 80 default_server;
 3    listen [::]:80 default_server;
 4
 5    root /var/www/html;
 6    index index.html;
 7
 8    location / {
 9        try_files $uri $uri/ =404;
10    }
11}

سه خط این‌جا کلیدی‌اند: root می‌گوید محتوا کجاست، index می‌گوید هر مسیر بدون فایل مشخص، پیش‌فرض کدام فایل را بگیرد، و location / قاعده‌ی نگاشت URL به فایل واقعی روی دیسک را تعیین می‌کند. حالا تغییرات را اعمال و نتیجه را بررسی کنید:

1sudo nginx -t
2sudo systemctl reload nginx.service
3curl -v http://127.0.0.1/

اگر همه‌چیز درست پیش رفته باشد، curl کد 200 و محتوای صفحه را برمی‌گرداند. حالا یک فایل که وجود ندارد را بخواهید (curl -v http://127.0.0.1/missing) تا کد 404 را با چشم خودتان ببینید — همان رفتاری که در درس HTTP یاد گرفتید، این بار از یک وب‌سرور واقعی.

یک آزمایش کوچک دیگر: مقدار root را عمداً به یک مسیر ناموجود مثل /var/www/wrong تغییر دهید و sudo nginx -t را اجرا کنید. جالب است بدانید که nginx -t این خطا را نمی‌گیرد — چون از نظر syntax درست است، فقط مسیر غلط است. Reload کنید و دوباره curl -v http://127.0.0.1/ بزنید تا کد 403 یا 404 را ببینید. این دقیقاً همان نوع خطایی است که در دنیای واقعی زمان زیادی می‌گیرد چون هیچ پیام روشنی نمی‌دهد؛ برگردانید root را به مقدار درست و ادامه دهید. در ادامه‌ی همین هفته، همین NGINX را به‌عنوان Reverse Proxy جلوی یک Backend مجزا قرار می‌دهیم.

منابع یادگیری

مستندات و مقالات

  • NGINX Beginner’s Guide — منبع اصلی این درس؛ ساختار پیکربندی و server block را کامل‌تر توضیح می‌دهد