هاست پایتون و Node.js: اشتراکی کافی است یا سرور مجازی؟

هاست پایتون و Node.js پلنی است که به شما اجازه می‌دهد یک برنامهٔ همیشه‌روشن اجرا کنید و وب‌سرور درخواست‌ها را به آن پروسه بسپارد؛ کاری که هاست PHP معمولی از پایه برایش ساخته نشده. این تفاوت فنی است، نه تجاری: هرچقدر هم پلن PHP گران باشد، جنگو یا اکسپرس روی آن بالا نمی‌آید. پیش از خرید باید بدانید نسخهٔ اشتراکی این قابلیت تا کجا کار می‌کند، چون در ایران این دسته کوچک است و برای بخشی از پروژه‌ها سرور مجازی جواب عملی‌تر و حتی ارزان‌تری است.

در حال حاضر ۵۴ پلن از ۵ شرکت ایرانی در این دسته رصد می‌شود — همین عدد، بهترین توصیف اندازهٔ این بازار است. آخرین بررسی قیمت: ۱۸ شهریور ۱۴۰۵.

چرا هاست PHP نمی‌تواند جنگو یا اکسپرس را اجرا کند؟

چون مدل اجرای این دو زبان با PHP فرق دارد و کل زیرساخت هاست اشتراکی حول مدل PHP چیده شده است.

مدل PHP: هر درخواست، یک پروسهٔ کوتاه

وقتی کاربر صفحه‌ای را باز می‌کند، وب‌سرور فایل PHP را به مفسر می‌دهد، خروجی ساخته می‌شود و پروسه تمام می‌شود. بین دو درخواست هیچ چیزی زنده نمی‌ماند. همین یک ویژگی است که هاست اشتراکی را ممکن کرده: صدها سایت روی یک ماشین، بدون آنکه هیچ‌کدام دائماً حافظه اشغال کند. مدیریت این پروسه‌ها هم کار وب‌سرور است، نه شما.

مدل پایتون و Node: یک پروسهٔ همیشه‌روشن

اپ جنگو یا اکسپرس یک برنامهٔ زنده است که بالا می‌آید، به یک پورت گوش می‌دهد و تا وقتی خاموشش نکنید حافظه اشغال می‌کند. حالت درون‌حافظه دارد، اتصال‌های دیتابیس را نگه می‌دارد و خودش مسیریابی می‌کند. برای اجرای آن روی هاست اشتراکی، وب‌سرور باید بپذیرد که درخواست‌ها را به یک پروسهٔ متعلق به شما بفرستد و آن پروسه را زنده نگه دارد. این همان کاری است که ابزارهایی مثل Passenger انجام می‌دهند و دلیل وجود این دستهٔ جداگانه هستند.

«Setup Python App» در cPanel دقیقاً چه کار می‌کند؟

این بخش، رابط گرافیکی یک ابزار مدیریت اپ به نام Passenger است که در بستهٔ انتخابگر پایتون و Node در CloudLinux ارائه می‌شود. کاری که برایتان انجام می‌دهد مشخص و محدود است.

چه چیزی برایتان می‌سازد

• یک محیط مجازی (virtualenv) جدا برای پروژه، تا کتابخانه‌های شما با بقیهٔ سیستم قاطی نشود.
• سه تنظیم اصلی: پوشهٔ پروژه، نشانی وبی که اپ روی آن سرو می‌شود، و فایل شروع برنامه.
• یک دکمه برای نصب وابستگی‌ها از روی فایل requirements یا package و یک دکمه برای ری‌استارت.
• یک جدول کوچک برای تعریف متغیرهای محیطی، که جای مناسبی برای کلیدها و رشتهٔ اتصال دیتابیس است.

وقتی اولین درخواست برسد، Passenger اپ شما را بالا می‌آورد و از آن به بعد درخواست‌ها را به همان پروسه می‌دهد. برای یک API کوچک یا یک سایت محتوایی، این ترتیب کاملاً کار می‌کند و نیازی به هیچ دانش سیستمی ندارید.

کجا کم می‌آورد

محدودیت‌ها را بهتر است قبل از خرید بدانید تا بعد از استقرار:

• پروسه دست شما نیست. Passenger تصمیم می‌گیرد کی اپ بالا بیاید و کی به‌خاطر بی‌کاری خاموش شود. یعنی اولین درخواست بعد از مدتی سکوت، کند است.
• کار پس‌زمینه جای درستی ندارد. صف کار، زمان‌بند داخلی و پروسهٔ کارگر که باید مستقل از درخواست وب زنده بماند، در این مدل بی‌خانمان است.
• وب‌سوکت معمولاً دردسر دارد. اتصال طولانی و دائمی با منطق «درخواست و پاسخ کوتاه» جور نیست و در بسیاری از پیکربندی‌های اشتراکی یا کار نمی‌کند یا مدام قطع می‌شود.
• بستهٔ سیستمی نصب نمی‌شود. دسترسی مدیر ندارید، پس کتابخانه‌هایی که موقع نصب به کامپایلر یا کتابخانهٔ سیستمی نیاز دارند ممکن است اصلاً نصب نشوند. این شایع‌ترین دیوار پروژه‌های پردازش تصویر و علم داده است.
• سقف حافظه و پروسه سخت‌گیرانه است. اپ زنده همیشه حافظه گرفته و در محیط اشتراکی، سهم شما محدود است. برنامه‌ای که بی‌احتیاط حافظه بگیرد، کشته می‌شود.
• پایگاه داده معمولاً MySQL است. اگر پروژه‌تان فرض کرده PostgreSQL در دسترس است، احتمالاً باید یا تنظیمات را عوض کنید یا سراغ لایهٔ بالاتر بروید.

کی هاست اشتراکی واقعاً کافی است؟

وقتی برنامهٔ شما فقط به درخواست پاسخ می‌دهد و کار دیگری در پس‌زمینه ندارد. چند نمونهٔ واقعی که روی پلن اشتراکی خوب جواب می‌دهند: یک API کوچک با فلسک که چند نقطهٔ پایانی دارد و به یک جدول وصل است؛ یک وبلاگ یا سایت نمونه‌کار با جنگو که بازدید سنگینی ندارد؛ یک فرم ثبت‌نام یا پنل داخلی برای چند ده کاربر؛ یا یک وب‌هوک که پیام می‌گیرد، در دیتابیس می‌نویسد و جواب می‌دهد.

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

کی چاره‌ای جز سرور مجازی ندارید؟

هر وقت به چیزی نیاز دارید که بین دو درخواست زنده بماند یا از سطح حساب کاربری فراتر برود. فهرست زیر کوتاه است ولی تقریباً بدون استثنا:

• وب‌سوکت و ارتباط زنده. چت، اعلان لحظه‌ای، داشبورد بلادرنگ.
• کارگر پس‌زمینه و صف. ارسال ایمیل انبوه، پردازش فایل، ساخت گزارش، هر چیزی که با Celery یا صف مشابه اجرا می‌شود.
• کار طولانی. اگر پاسخ یک درخواست بیش از چند ثانیه طول بکشد، در محیط اشتراکی قطع می‌شود.
• بستهٔ سیستمی خاص. کتابخانهٔ پردازش تصویر یا ویدئو، موتور جست‌وجو، یا هر چیزی که با ابزار بسته‌بندی سیستم‌عامل نصب می‌شود.
• نسخهٔ دقیق و کنترل‌شده. وقتی پروژه به نسخهٔ مشخصی از زبان یا کتابخانه گره خورده و شما نمی‌توانید منتظر بمانید تا شرکت میزبان آن را اضافه کند.
• استقرار خودکار. اگر می‌خواهید با هر پوش، نسخهٔ جدید بالا برود.

حرف صادقانه این است: برای بخش بزرگی از پروژه‌های پایتون و Node در ایران، یک سرور مجازی ایران ارزان جواب عملی‌تری از پلن اشتراکی این دسته است — به شرطی که یک نفر بلد باشد آن را نگه دارد. اگر آن یک نفر وجود ندارد، حرف عوض می‌شود؛ سرور رهاشده بدترین گزینه است. پیش از سفارش، راهنمای خرید سرور مجازی را ببینید.

مشکل مدیریت پروسه

روی سرور خودتان، اپ Node را با یک مدیر پروسه بالا می‌آورید: pm2 یا یک سرویس systemd. این ابزار اپ را بعد از کرش دوباره بالا می‌آورد، بعد از ری‌بوت خودکار اجرا می‌کند، لاگ‌ها را نگه می‌دارد و اجازه می‌دهد چند نمونه از برنامه را کنار هم اجرا کنید.

روی هاست اشتراکی هیچ‌کدام از این‌ها دست شما نیست؛ Passenger هم مدیر پروسه است و هم تنها مدیر پروسه. مزیتش این است که چیزی برای پیکربندی ندارید، عیبش این است که رفتارش قابل تنظیم نیست: تعداد نمونه‌ها، سیاست ری‌استارت و زمان خاموشی بر اثر بی‌کاری را شما تعیین نمی‌کنید. لاگ‌ها هم معمولاً در یک فایل مشترک جمع می‌شوند که خواندنش راحت نیست. اگر برنامه‌تان به چند کارگر جدا نیاز دارد، اینجا جایش نیست.

نسخهٔ Node و پایتون را چطور قفل کنیم؟

در پنل، نسخه را از یک فهرست کشویی انتخاب می‌کنید و همان نسخه برای اپ شما فعال می‌شود. سه نکته که معمولاً دیر کشف می‌شوند:

• فهرست نسخه‌ها محدود است. نسخه‌ای که پروژه‌تان می‌خواهد ممکن است اصلاً در فهرست نباشد. این را قبل از خرید بپرسید، نه بعد از آپلود.
• فیلد engines در package تضمینی نیست. روی این محیط، فهرست کشویی حرف آخر را می‌زند؛ نه فایل پروژه.
• ماژول‌های کامپایل‌شده به نسخه گره خورده‌اند. وابستگی‌هایی که موقع نصب کامپایل می‌شوند، بعد از عوض کردن نسخه از کار می‌افتند و باید دوباره نصب شوند. اگر نسخه را بالا بردید و اپ بالا نیامد، معمولاً همین است.

قاعدهٔ کاری ساده: فایل قفل وابستگی‌ها را در پروژه نگه دارید، نسخه را بدون دلیل عوض نکنید، و هر بار که عوضش کردید وابستگی‌ها را از نو نصب کنید.

استقرار روی هاست ایرانی: واقعیت کار

انتظار استقرار با گیت را کنار بگذارید. روی بیشتر پلن‌های اشتراکی ایرانی، هیچ قلابی برای پوش وجود ندارد و بعضی پلن‌ها اصلاً SSH نمی‌دهند. چرخهٔ واقعی معمولاً این است: فایل‌ها را فشرده می‌کنید، از فایل‌منیجر یا FTP آپلود می‌کنید، در همان‌جا باز می‌کنید، از پنل دکمهٔ نصب وابستگی‌ها را می‌زنید و بعد ری‌استارت.

چند نکتهٔ عملی برای اینکه این چرخه اذیت نکند: پوشهٔ وابستگی‌ها را آپلود نکنید و بگذارید روی خود سرور نصب شود؛ متغیرهای محیطی را در جدول پنل بگذارید نه در فایل داخل پوشهٔ عمومی؛ فایل‌های ثابت جنگو را قبل از آپلود جمع کنید چون ممکن است نتوانید آن دستور را روی سرور اجرا کنید؛ و برای هر تغییر کوچک، عادت کنید اول روی یک زیردامنهٔ آزمایشی امتحان کنید. اگر پلنی SSH می‌دهد، ارزش تفاوت قیمتش را دارد — با ترمینال، همین چرخه چند دقیقه‌ای می‌شود. تفاوت محیط‌های مدیریتی را در مقایسهٔ cPanel و DirectAdmin توضیح داده‌ایم.

اشتراکی یا سرور مجازی: مقایسهٔ کوتاه

این‌ها ارزان‌ترین پلن‌های اشتراکی این دسته هستند که رصد می‌کنیم:

موقع مقایسه، فقط به قیمت و فضا نگاه نکنید. سه چیز را جدا بپرسید: کدام نسخه‌ها در فهرست هست، SSH داده می‌شود یا نه، و سقف حافظهٔ اپ چقدر است. برای دیدن پلن‌ها کنار هم ابزار مقایسه کمک می‌کند و اگر تصمیمتان به سمت لایهٔ بالاتر رفت، سرور مجازی آلمان برای پروژه‌هایی که به سرویس‌های بین‌المللی وصل می‌شوند گزینهٔ رایجی است. اگر مخاطبتان داخلی است و فقط محیط اجرای آزادتری می‌خواهید، راهنمای سرور مجازی ایران شرط‌های خرید داخلی — از نوع مجازی‌سازی تا سابقهٔ آی‌پی — را جمع کرده.

پرسش‌های متداول

می‌توانم روی هاست وردپرسی معمولی یک اسکریپت پایتون اجرا کنم؟

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

Next.js را می‌شود روی هاست اشتراکی بالا آورد؟

اگر خروجی را به شکل فایل ثابت بگیرید، بله و حتی روی یک هاست لینوکس معمولی هم اجرا می‌شود، چون دیگر برنامه‌ای در کار نیست. اگر رندر سمت سرور می‌خواهید، به همان پلن اجرای Node نیاز دارید و همهٔ محدودیت‌های بالا سر جایش است.

چرا اپ من اولین بار خیلی کند باز می‌شود؟

چون بعد از مدتی بی‌کاری پروسه خاموش شده و اولین درخواست باید منتظر بالا آمدن دوبارهٔ برنامه بماند. روی محیط اشتراکی معمولاً نمی‌توانید این رفتار را خاموش کنید. راه‌حل نصفه‌ونیمه‌اش یک درخواست دوره‌ای برای زنده نگه داشتن اپ است؛ راه‌حل واقعی، محیطی است که خودتان مدیر پروسه‌اش باشید.

پشتیبانی شرکت کد من را دیباگ می‌کند؟

نه، و انتظارش هم منصفانه نیست. مرز مسئولیت معمولاً این است: بالا آمدن محیط و در دسترس بودن نسخه‌ها با شرکت میزبان، و درست بودن کد و وابستگی‌ها با شما. برای همین در این دسته، کیفیت مستندات شرکت به اندازهٔ سرعت پاسخ تیکت اهمیت دارد.

پایگاه دادهٔ PostgreSQL روی این پلن‌ها هست؟

معمولاً نه؛ چیزی که در دسترس است MySQL یا MariaDB است. اگر پروژه به PostgreSQL گره خورده، عملاً همین یک بند شما را به سرور مجازی می‌رساند. این را قبل از خرید بپرسید، چون بعد از استقرار تغییرش پرهزینه است.

جمع‌بندی: مسیر تصمیم

1. ببینید برنامه‌تان بین دو درخواست به چیزی زنده نیاز دارد یا نه. اگر ندارد، اشتراکی کافی است.
2. اگر وب‌سوکت، صف کار یا کار طولانی دارید، از همین‌جا سراغ سرور مجازی بروید و وقت تلف نکنید.
3. فهرست نسخه‌ها، وجود SSH و سقف حافظه را قبل از خرید بپرسید؛ هر سه بعداً قابل تغییر نیستند.
4. وابستگی‌ها را روی خود سرور نصب کنید و فایل قفل را در پروژه نگه دارید.
5. اگر کسی را برای نگهداری سرور ندارید، اشتراکی محدود بهتر از سرور مجازی رهاشده است.

برای دیدن گزینه‌های موجود، فهرست پلن‌های پایتون و Node.js را ببینید و اگر هنوز بین لایه‌ها مردد هستید، یابندهٔ هاست با چند سؤال کوتاه کمک می‌کند.

هاست پایتونهاست Node.jsجنگوPassenger