همهٔ وباپلیکیشنها به یک سرور برنامه نیاز ندارند. بخش بزرگی از اینترنت — سایتهای شخصی، صفحههای فرود، مستندات و حتی اپهای SPA با بکاند جدا — فقط فایلهای استاتیک (HTML، CSS و JavaScript) هستند. در کنارش، هر سروری هم تعدادی فرآیند پسزمینه دارد که باید همیشه زنده بمانند: ورکرهای صف، کرونجابها و اسکریپتهای طولانی. در این مقاله به دو ابزار ساده اما حیاتی میپردازیم: میزبانی استاتیک و مدیریت فرآیندها با Supervisor.
میزبانی استاتیک — سادهترین نوع دپلوی
میزبانی استاتیک یعنی سرو کردن فایلهای آمادهٔ HTML، CSS و JavaScript بدون هیچ مرحلهٔ اجرای کد در سمت سرور. خبری از Node.js، PHP یا دیتابیس نیست؛ وبسرور فقط فایل را از دیسک میخواند و به مرورگر میدهد. این سادگی، مزیتهای بزرگی دارد: سرعت بالا، امنیت بالا (سطح حملهٔ تقریباً صفر) و مقیاسپذیری آسان (فایلها را میتوان هر جای دنیا کش کرد).
فرآیند دپلوی فوقالعاده ساده است: خروجی را بسازید (یا اصلاً نسازید — خودِ فایلها) و آپلود کنید. برای یک پروژهٔ ساده، حتی یک دستور کافی است:
rsync -avz ./dist/ user@server:/var/www/site/نکات کلیدی میزبانی استاتیک
SPA و History Fallback
اپهای تکصفحهای (SPA) مثل React و Vue از روتینگ سمت کلاینت استفاده میکنند؛ یعنی مسیرهایی مثل /dashboard و /settings در سمت مرورگر مدیریت میشوند نه سرور. اگر کاربر مستقیم وارد /dashboard شود، سرور باید به جای خطای ۴۰۴، همان index.html را برگرداند. به این کار History Fallback میگویند و در Nginx با یک بلاک ساده پیاده میشود.
هدرهای کش (Caching Headers)
فایلهای استاتیک را باید با Cache-Control مناسب سرو کرد: فایلهای دارای هش (مثل app.a1b2c3.js) با کش طولانی و فایلهای بدون هش (مثل index.html) با کش کوتاه یا بدون کش. این کار سرعت بارگذاری را چند برابر میکند.
ادغام با CDN
چون فایلها بدون حالت (Stateless) هستند، میتوان آنها را روی CDN قرار داد تا از نزدیکترین نقطه به کاربر سرو شوند. این یعنی زمان بارگذاری یکسان در تهران و فرانکفورت — چیزی که برای سایتهای پویا به این سادگی نیست.
HTTPS و فشردهسازی
گواهی SSL (مثلاً Let's Encrypt) و فشردهسازی gzip یا Brotli از الزامات امروزی هر سایت استاتیک است. هر دو در سطح وبسرور یا PaaS قابل فعالسازی هستند.
مقایسهٔ میزبانی استاتیک: PaaS در برابر S3 و Netlify
برای سرو فایلهای استاتیک چند مسیر رایج وجود دارد: باماستوریج ابری مثل S3، پلتفرمهای تخصصی مثل Netlify، یا یک PaaS عمومی. مقایسهٔ خلاصه:
| ویژگی | PaaS عمومی | S3 / Object Storage | Netlify / Vercel |
|---|---|---|---|
| راهاندازی | ساده — پوشه را آپلود کنید | متوسط — تنظیم Bucket و Policy | ساده — اتصال Git |
| توسعهٔ فراتر از استاتیک | بله — بکاند و فرآیند پسزمینه | خیر | محدود (Serverless) |
| CDN داخلی | قابل فعالسازی | CloudFront جدا | داخلی |
| کنترل هدرها | کامل | کامل (Metadata) | محدود به فایل تنظیمات |
| قیمت برای ترافیک کم | مناسب | بسیار ارزان | رایگان تا سقف معین |
| مناسب برای | سایت + اپلیکیشن ترکیبی | ذخیرهٔ فایل و سایت ساده | سایتهای JAMstack |
Supervisor — فرمانروای فرآیندهای پسزمینه
اپلیکیشن استاتیک سرو شد؛ حالا اسکریپتهایی که باید شبانهروز کار کنند چه میشوند؟ ورکر صف ایمیل، اسکریپت پشتیبانگیری، ربات تلگرام یا سرویس همگامسازی — اگر این فرآیندها بمیرند، هیچکس بیدار نمیشود که دوبارهشان راه بیندازد.
Supervisor یک سیستم مدیریت فرآیند (Process Control System) متنباز و بسیار سبک است که توسط کاربران پایتون توسعه یافته و در سال ۲۰۰۴ منتشر شده. سوپروایزر فرآیندهای شما را اجرا، نظارت، ریاستارت و لاگگیری میکند — و اگر فرآیندی از کار بیفتد، خودش دوباره آن را بالا میآورد.
مفاهیم اصلی Supervisor
برنامهها (Programs)
هر فرآیندی که میخواهید مدیریت شود، یک برنامه است. هر برنامه با یک دستور، دایرکتوری کاری، تعداد نمونه (NumProcs) و کاربر اجراکننده تعریف میشود:
[program:worker]
command=/usr/bin/python3 /opt/app/worker.py
directory=/opt/app
user=www-data
autostart=true
autorestart=true
startsecs=5
stdout_logfile=/var/log/app/worker.log
stderr_logfile=/var/log/app/worker-error.logاتوریاستارت (Autorestart)
با autorestart=true، اگر فرآیند با خطا بمیرد، سوپروایزر بلافاصله آن را دوباره اجرا میکند. startsecs هم مشخص میکند که فرآیند چقدر باید سالم بماند تا «موفق» در نظر گرفته شود — این از ریاستارتهای بینهایت هنگام بالا نیامدن برنامه جلوگیری میکند.
گروههای فرآیند (Process Groups)
برنامههای مرتبط را میتوان در یک گروه جمع کرد تا با یک دستور همه با هم شروع یا متوقف شوند:
supervisorctl start all— شروع همهٔ برنامههاsupervisorctl restart worker:*— ریاستارت کل یک گروهsupervisorctl status— وضعیت زندهٔ همهٔ فرآیندها
لاگگیری
سوپروایزر خروجی استاندارد و خطا را به فایلهای لاگ جداگانه هدایت میکند، با پشتیبانی از چرخش خودکار (Log Rotation). دیگر خبری از nohup و لاگهای گمشده نیست.
مدیریت از راه دور
با supervisorctl (CLI) یا رابط وب supervisord، بدون دسترسی مستقیم به shell، میتوان فرآیندها را متوقف، شروع یا وضعیتشان را مشاهده کرد.
مقایسهٔ Supervisor با systemd و PM2
| ویژگی | Supervisor | systemd | PM2 |
|---|---|---|---|
| نوع | مدیر فرآیند مستقل (Python) | مدیر سرویس سیستمعامل | مدیر فرآیند Node.js |
| سادگی پیکربندی | بالا — INI ساده | متوسط — Unit file | بالا — دستور/JSON |
| اتوریاستارت | بله | بله | بله |
| گروهبندی | بله (Groups) | محدود (Target) | بله (Ecosystem) |
| زبانهای پشتیبانیشده | همه (هر فرمان) | همه | فقط Node.js |
| راهاندازی بدون root | بله (کاربر عادی) | خیر (سرویس سیستمی) | بله |
| مناسب برای | سرورهای اشتراکی و ساده | سرور اختصاصی مدرن | پروژههای Node.js |
موارد استفادهٔ Supervisor
۱. ورکرهای صف (Queue Workers)
در معماریهای مبتنی بر صف (مثل Redis یا RabbitMQ)، ورکرها باید همیشه در دسترس باشند. سوپروایزر آنها را زنده نگه میدارد و در صورت کرش، فوری ریاستارت میکند.
۲. دیمونهای شبهکرون
اسکریپتهایی که باید هر چند دقیقه اجرا شوند — یا باید بهجای کرون، خودشان حلقهٔ اجرا داشته باشند (و توسط سوپروایزر زنده بمانند) یا در کنار کرون مدیریت شوند.
۳. اسکریپتهای طولانی و استریم
رباتهای تلگرام، شنوندههای WebSocket، سرویسهای همگامسازی — هر فرآیند طولانیمدتی با لاگگیری و ریاستارت خودکار.
۴. محیطهای اشتراکی و بدون root
جایی که نمیتوانید سرویس systemd بسازید، سوپروایزر به عنوان کاربر عادی اجرا میشود — انتخاب اول در سرورهای اشتراکی و کانتینرها.
چه زمانی این ترکیب انتخاب مناسبی است؟
- سایت شما اساساً استاتیک است یا SPA با بکاند جدا دارد
- نیاز به دپلوی ساده و بدون پیچیدگی دارید — فایلها را آپلود کنید، تمام
- تعداد فرآیندهای پسزمینهٔ شما کم و ساده است
- به اتوریاستارت و لاگگیری برای اسکریپتهای خودکار نیاز دارید
- به دنبال راهی سبکتر از Kubernetes برای یک سرور هستید
برای چه چیزهایی مناسب نیست؟
- اپهای پویای سنگین — اگر منطق سمت سرور، دیتابیس و جلسهٔ کاربر دارید، به اپسرور واقعی و PaaS کامل نیاز دارید
- مقیاس کلان و خودکار — بالا آوردن دهها نمونه بر اساس ترافیک، کار ارکستراتورهایی مثل Kubernetes است
- اسکریپتهای یکباره — برای کارهای کوتاه و یکباره، کرون و systemd timer سادهترند
- اپلیکیشنهای Node.js توزیعشده — اگر فقط Node دارید، PM2 امکانات بیشتری (Cluster، پایش) ارائه میدهد
- نیاز به SLA و HA کامل — برای سرویسهای حیاتی چند سروری، باید به راهحلهای توزیعشده فکر کنید
لکسویا در سرویس پلتفرم ابری (PaaS) خود از این تکنولوژی پشتیبانی میکند — با چند کلیک دپلوی کنید.
نتیجهگیری
میزبانی استاتیک به شما آرامش میدهد: بدون سرور برنامه، بدون نگرانی امنیتی و با سرعت خیرهکننده. و Supervisor در کنارش، فرآیندهای پسزمینه را با کمترین پیچیدگی زنده و تحت کنترل نگه میدارد. این دو با هم، یک سرور ساده را به یک زیرساخت منظم تبدیل میکنند.
اگر حجم کارتان در حد یک یا چند سرور است و پیچیدگی Kubernetes برایتان بیش از حد است، این ترکیب ساده — یک وبسرور برای استاتیک و یک مدیر فرآیند برای بقیه — کاملترین و کمدردسرترین پاسخ است.