تعتمد استضافة تطبيقات Node.js في بيئة الاستضافة المشتركة على آلية تقنية تختلف جذرياً عن التشغيل المباشر عبر سطر الأوامر في الخوادم الخاصة. نحن في Hostna نشغّل خوادمنا في ألمانيا باستخدام لوحة تحكم Plesk، والتي تعتمد على محرك Phusion Passenger ليكون الوسيط بين خادم الويب Nginx أو Apache وبين تطبيق JavaScript الخاص بك. هذه الطريقة تسمح بتشغيل التطبيق دون الحاجة لصلاحيات root، ولكنها تفرض قيوداً معينة على كيفية إدارة العمليات واستهلاك الذاكرة.
الإجابة المباشرة على كيفية الاستضافة تكمن في رفع ملفات المشروع، ثم تحديد ملف التشغيل الرئيسي (غالباً ما يكون app.js أو index.js)، وتثبيت الاعتمادات عبر واجهة لوحة التحكم. ومع ذلك، يواجه المطورون في الخليج العربي تحديات تتعلق باستقرار التطبيق عند زيادة الطلبات، وهو ما يتطلب ضبطاً دقيقاً لملفات الإعدادات وتجنب الأخطاء الشائعة في مسارات الملفات.
فهم آلية عمل Phusion Passenger في الاستضافة المشتركة
عند رفع تطبيقك إلى الاستضافة المشتركة، لا يقوم النظام بتشغيل node server.js بشكل دائم كما تفعل في جهازك المحلي. بدلاً من ذلك، يقوم Phusion Passenger بمراقبة الطلبات القادمة عبر المنفذ 80 أو 443. عندما يصل طلب إلى الدومين الخاص بك، يقوم Passenger بتشغيل عملية Node.js إذا لم تكن تعمل بالفعل. هذا السلوك يسمى spawning.
من الناحية التقنية، يتم توجيه الطلبات من Nginx (الذي يعمل كـ Reverse Proxy) إلى مقبس Unix Socket يتصل بعملية التطبيق. إذا توقف التطبيق عن الاستجابة أو استهلك موارد تتجاوز المسموح بها في الخطة، يقوم النظام بإغلاق العملية تلقائياً. لذلك، من الضروري جداً التأكد من أن تطبيقك لا يعتمد على ذاكرة الحالة (Stateful) لأن العملية قد تُعاد تشغيلها في أي وقت.
إعداد ملف package.json والاعتمادات
أحد أكثر الأسباب شيوعاً لفشل تشغيل تطبيقات Node.js هو فقدان الاعتمادات أو عدم توافق النسخ. في لوحة التحكم، يجب عليك استخدام زر NPM Install الذي يقوم بتنفيذ الأمر في بيئة معزولة. تأكد دائماً من أن ملف package.json يحتوي على قسم scripts صحيح، وتحديداً start، رغم أن Passenger غالباً ما يتجاوزه ليبحث عن الملف المذكور في خانة Application Startup File.
{
"name": "my-app",
"version": "1.0.0",
"main": "app.js",
"dependencies": {
"express": "^4.18.2"
}
}عند تنفيذ تثبيت الحزم، يتم إنشاء مجلد node_modules. في الاستضافة المشتركة، يُنصح دائماً باستخدام خيار --production لتقليل عدد الملفات المرفوعة وحجم المساحة المستهلكة، حيث أن تجاوز عدد الملفات (Inodes) المسموح به قد يؤدي إلى توقف لوحة التحكم عن إجراء التحديثات.
إدارة ملفات البيئة .env والأمان
في بيئة بيئة نود جي إس، تُخزن مفاتيح الربط وقواعد البيانات عادة في ملف .env. في الاستضافة المشتركة، يجب أن يكون هذا الملف خارج مجلد httpdocs للتأكد من عدم الوصول إليه عبر المتصفح. تتيح لوحة التحكم إضافة Environment Variables يدوياً، وهي طريقة مناسبة للأمان، حيث يتم حقن هذه المتغيرات مباشرة في process.env الخاص بالتطبيق عند التشغيل.
إذا كنت تستخدم مكتبة dotenv، تأكد من تحديد المسار المطلق للملف، لأن المسارات النسبية قد تختلف عندما يقوم Passenger بتشغيل التطبيق من مجلد جذر مختلف. استخدام المسارات المطلقة مثل /var/www/vhosts/example.com/httpdocs/.env يقلل من احتمالية فشل تحميل الإعدادات.
حل مشكلة الخطأ 503 Service Unavailable
يظهر خطأ 503 عندما يفشل Passenger في بدء تشغيل عملية Node.js أو عندما يستغرق التطبيق وقتاً طويلاً في الاستجابة (Timeout). لتشخيص هذا الخطأ، يجب عليك تفعيل خيار عرض الأخطاء في المتصفح مؤقتاً أو فحص سجلات الأخطاء (Logs). يمكنك إضافة الكود التالي في بداية ملف app.js لتوجيه الأخطاء إلى ملف نصي يمكنك قراءته:
const fs = require('fs');
const process = require('process');
process.on('uncaughtException', (err) => {
fs.writeSync(1, `Caught exception: ${err}
`);
});غالباً ما يكون السبب هو نقص في الذاكرة المتاحة. في الاستضافة المشتركة، إذا حاول التطبيق استهلاك أكثر من المحدود له، سيقوم نظام OOM killer بإنهاء العملية مباشرة. إذا كان تطبيقك يحتاج إلى معالجة ثقيلة للصور أو تشغيل عمليات معقدة في الخلفية، فإن الانتقال إلى استضافة بوتات برمجية أو خادم افتراضي هو الخيار التقني السليم.
تحديث التطبيق وآلية restart.txt
عندما تقوم بتعديل الكود الخاص بك ورفعه عبر FTP، لن تلاحظ التغييرات مباشرة لأن العملية القديمة لا تزال تعمل في الذاكرة. لإجبار Passenger على إعادة تحميل التطبيق، يجب عليك إما الضغط على زر Restart App في لوحة التحكم، أو إنشاء ملف فارغ يسمى restart.txt داخل مجلد tmp في جذر التطبيق.
mkdir tmp
touch tmp/restart.txtبمجرد أن يكتشف المحرك وجود هذا الملف أو تغيير تاريخ تعديله، سيقوم بإنهاء العمليات الحالية وتشغيل النسخة الجديدة من الكود عند أول طلب يصل للموقع. هذه الآلية ضرورية جداً للمطورين الذين يعملون بنظام التحديث المستمر.
القيود التقنية ومتى يجب الترقية إلى VPS؟
هناك حدود واضحة لما يمكن تحقيقه على الاستضافة المشتركة. على سبيل المثال، تقنيات WebSockets عبر Socket.io قد لا تعمل بكفاءة عالية بسبب قيود مهلة الاتصال (Proxy Timeout) في Nginx. أيضاً، لا يمكنك تشغيل مدير عمليات مثل PM2 بشكل دائم لأن الاستضافة المشتركة تمنع العمليات التي تعمل في الخلفية لفترات طويلة دون وجود طلبات HTTP نشطة.
إذا كان مشروعك يتطلب:
- اتصالات
WebSocketدائمة ومستقرة. - تشغيل مهام مجدولة (Cron Jobs) معقدة كل دقيقة.
- الوصول إلى صلاحيات
rootلتثبيت حزم نظام معينة (مثلffmpeg). - استخدام منافذ (Ports) مخصصة غير 80 و443.
في هذه الحالات، ننصح بالاطلاع على الخوادم الافتراضية الموجهة للمنطقة التي تمنحك تحكماً كاملاً بالموارد. في Hostna، نوفر خوادم في ألمانيا تتيح لك تثبيت أي نسخة من Node.js وإدارة العمليات باستخدام systemd للمساعدة في إعادة التشغيل التلقائي بعد أي توقف.
يمكنك الاطلاع على توثيق شبكة مطوري موزيلا لفهم أفضل الممارسات في بناء تطبيقات مستقرة برمجياً قبل رفعها إلى الخادم. تذكر دائماً أن جودة الكود تلعب دوراً أساسياً في تقليل استهلاك الموارد؛ فمثلاً، ضبط TTFB (وقت الوصول لأول بايت) يعتمد بشكل كبير على سرعة استعلامات قاعدة البيانات وكفاءة Middleware في تطبيقك.
ماذا تفعل إذا لم يعمل التطبيق؟
إذا اتبعت الخطوات السابقة ولا يزال التطبيق يظهر خطأ Internal Server Error، يرجى التحقق من نسخة Node.js المختارة في لوحة التحكم، حيث أن بعض الحزم الحديثة تتطلب نسخة 18.x أو أحدث. إذا تواصلت مع فريق الدعم التقني، يرجى إرسال سجل الأخطاء الموجود في مجلد logs باللغة الإنجليزية، وتوضيح نسخة Node التي تستخدمها، ونتائج أمر npm install إذا ظهرت فيه أي تحذيرات تتعلق بـ node-gyp أو الاعتمادات الأصلية (Native Dependencies).
كُتبت هذه المقالة بمساعدة الذكاء الاصطناعي ضمن خط البحث الخاص بـ Hostna وراجعها شخص قبل النشر.