نقل Laravel إلى سيرفر جديد يحتاج تسليم حالة التطبيق، وليس رفع الكود وتشغيل الصفحة فقط. يجب الحفاظ على مفاتيح التشفير اللازمة، ونقل البيانات والملفات المتغيرة، وضبط الجلسات والطوابير والمجدول والتكاملات. أكبر أخطاء النقل أن تعمل الواجهة بينما تبقى المهام على المصدر القديم، أو أن يعمل المجدول على الطرفين وينفذ الإجراء مرتين. اطلب خطة تحويل تحدد متى تتوقف الكتابة ومن يستلم كل مهمة وكيف يثبت نجاحها.
ارسم خريطة التطبيق قبل تقدير مدة النقل
احصر إصدار Laravel وPHP والامتدادات وComposer ومتطلبات بناء الواجهة، وحدد قاعدة البيانات وRedis والتخزين والبريد وواجهات الخدمات الخارجية. راجع مدير العمليات الذي يشغل العمال وملفات النشر والمهام المجدولة والمجلدات القابلة للكتابة. كل مكون خارجي يحتاج بيانات اتصال وصلاحيات ومسؤول اختبار، حتى لو لم يوجد داخل مجلد المشروع.
لا تفترض أن نسخة المستودع تحتوي كل شيء؛ قد تكون هناك ملفات مستخدمين محلية أو إعدادات خادم أو أسرار محفوظة خارجه. حدد الإصدار البرمجي المراد نقله بدقة، وابن تبعيات متوافقة من ملفات القفل. إذا كان النقل يتضمن ترقية PHP أو Laravel، أضف اختبارات توافق ونطاق رجوع يتناسب مع تغير الكود والبيانات.
حافظ على APP_KEY ولا تولده عشوائياً
يرتبط APP_KEY بتشفير بيانات يستخدمها التطبيق. توضح وثائق تشفير Laravel أثر تغيير المفتاح على فك البيانات والجلسات، ودعم مفاتيح سابقة في الإصدارات التي توفر ذلك. نقل تطبيق قائم لا يعادل تثبيت تطبيق جديد؛ توليد مفتاح مختلف دون خطة قد يجعل بيانات مشفرة غير قابلة للقراءة على الوجهة.
انقل المفتاح والأسرار اللازمة عبر قناة مقيدة، واختبر قراءة عينة مناسبة من البيانات المشفرة دون كشفها. إذا وجدت شبهة تسريب فهذه عملية تدوير أسرار مخططة، لا سبب لنسخ السر بلا مراجعة أو تغييره بلا فهم. كذلك احصر مفاتيح توقيع أو خدمات أخرى قد لا تعتمد على APP_KEY ولا تنتقل تلقائياً معه.
أعد بناء إعدادات الوجهة بطريقة صحيحة
راجع قيم البيئة الخاصة بالقاعدة والكاش والطوابير والجلسات والبريد والتخزين وعنوان التطبيق. لا تنسخ ملف كاش إعدادات مبنياً في بيئة أخرى وتفترض أنه سيقرأ القيم الجديدة. تشرح وثائق نشر Laravel أثر config:cache، وضرورة حصر استخدام env في ملفات الإعداد عند تفعيل الكاش.
اضبط جذر الويب على المجلد العام المخصص، وصلاحيات الكتابة للمجلدات المطلوبة دون فتح المشروع كله. تأكد أن أسرار البيئة والسجلات غير متاحة من الويب، وأن وضع إظهار الأخطاء التفصيلية غير مفعّل للإنتاج. اختبر الإعداد الفعلي من التطبيق، لا مجرد صحة النص في ملف لم يعد يُقرأ بالطريقة المتوقعة.
انقل الحالة المتغيرة وحدد مكانها
| المكون | سؤال النقل | اختبار القبول |
|---|---|---|
| قاعدة البيانات | ما نقطة النسخ ومصدر الكتابة الأخير؟ | بيانات حديثة ومعاملات سليمة |
| ملفات المستخدمين | محلية أم مخزن خارجي؟ | قراءة ورفع ملف تجريبي معتمد |
| الجلسات | هل المخزن والمفاتيح وخصائص الكوكيز متوافقة؟ | دخول وصلاحيات وسلوك انتهاء متوقع |
| الكاش والأقفال | مشترك أم مستقل وبأي namespace؟ | عدم خلط البيئات وصحة التنسيق |
| الطوابير | أين تنتظر المهام ومن يستهلكها؟ | عدم فقد مهام أو تكرار أثرها |
| المجدول | أي سيرفر يملك تشغيل المهمة؟ | دورة واحدة موثقة في وقتها |
حافظ على توافق الكود مع مخطط البيانات طوال الانتقال. تنفيذ migrations ليس خطوة آمنة تلقائياً لمجرد أنه أمر معتاد في النشر؛ راجع التغييرات والأقفال والمدة وتوافق النسخة القديمة إن بقيت تعمل. الرجوع بكود قديم بعد تغيير غير متوافق في القاعدة قد يفشل حتى لو عاد DNS إلى المصدر.
سلّم الطوابير دون حذف أو تكرار عشوائي
حدد هل ستبقى خدمة الطابور نفسها أم ستنقل مخزنها أيضاً. راجع المهام المنتظرة والمؤجلة والجارية والفاشلة، وتوافق صيغة المهمة مع إصدار الكود في العمال الجدد. لا تعالج النقل بمسح الطابور أو تشغيل كل الفاشل دفعة واحدة؛ بعض المهام قد نفذ أثرها بالفعل قبل تسجيل الفشل.
توضح وثائق طوابير Laravel أن العمال طويلو العمر يحتاجون إدارة لإعادة تحميل تغييرات الكود، وتفصل إعدادات التشغيل والتوقف وإعادة المحاولة. ضع تسلسلاً لتصريف العمال القديمة أو إيقافها بصورة مناسبة ثم تشغيل البديل، وراجع مهل المشرف ومدة المهمة وحد إعادة ظهورها وفق موصل الطابور المستخدم.
امنع تشغيل المجدول مرتين
نسخ cron إلى السيرفر الجديد مع بقاء القديم فعالاً قد يضاعف التقارير أو الإشعارات أو الفوترة. عيّن نقطة تشغيل واضحة عند التحويل، أو استخدم آلية تنسيق متوافقة مع التطبيق. وتشرح وثائق جدولة Laravel تشغيل مهمة على سيرفر واحد عبر قفل مع متطلبات لمخزن مشترك مدعوم.
لا تفترض أن onOneServer يمنع التكرار إذا كانت البيئتان تستخدمان مخزنين مستقلين أو أسماء مختلفة. كما لا تعتمد على وضع الصيانة وحده لضبط كل أعمال التطبيق؛ قد توجد مهام مستثناة أو خدمات خارج الإطار. اختبر جدولة مهمة آمنة وسجل جهة التنفيذ قبل فتح الأعمال الفعلية.
اختبر التكاملات من هوية الشبكة الجديدة
قد تتطلب خدمة خارجية السماح بعنوان خروج محدد، أو عنوان callback ثابتاً، أو شهادة واسم نطاق مطابقين. راجع هذه الاعتماديات مع البريد والدفع والتخزين والإشعارات. نجاح اتصال تجريبي من المصدر لا يثبت نجاحه من الوجهة. اعزل مفاتيح ووجهات الاختبار حتى لا ترسل النسخة التجريبية طلبات حقيقية للعملاء.
في مثال افتراضي، لوحة شركة تفتح بعد النقل لكن فواتيرها لا تخرج لأن عامل الطابور يستخدم إعداداً قديماً. وفي مثال آخر، الملفات السابقة تظهر لكن الرفع الجديد يذهب إلى قرص لا يراه باقي العمال. هذه عيوب قبول وظيفي، وليست دليلاً على الحاجة إلى CPU أكبر.
نفذ التحويل بخطة كتابة ورجوع
حدد نافذة تجميد أو مزامنة نهائية تناسب البيانات، ثم تحقق من اكتمال النسخة وتوجيه الويب وتسليم العمال والمجدول. راقب الأخطاء والطوابير وزمن العمليات بعد الفتح. يحتفظ الفريق بالمصدر وفق خطة الرجوع دون السماح له بإنتاج بيانات متعارضة أو تنفيذ أعمال خلفية غير مقصودة.
استخدم دليل نقل الاستضافة للإطار العام، وراجع أخطاء النسخ الاحتياطي لاختبار الاستعادة. إذا استقبلت الوجهة بيانات جديدة، فالرجوع يحتاج حمايتها ومصالحتها مع آثار الخدمات الخارجية، وليس مجرد استيراد النسخة الأولى فوق الواقع الحالي.
أسئلة شائعة عن نقل Laravel
هل أنشئ APP_KEY جديداً على السيرفر الجديد؟
ليس لمجرد النقل. احتفظ بالمفتاح اللازم لقراءة البيانات، وأي تدوير يجب أن يخطط وفق إصدار التطبيق ونوع البيانات ومتطلبات الحماية.
هل يكفي نسخ مجلد storage؟
لا؛ راجع الأقراص المعرفة في التطبيق والروابط والمخازن الخارجية وقاعدة البيانات والطوابير. موقع البيانات يحدده الإعداد الفعلي.
متى أحتاج ترقية الموارد أثناء النقل؟
إذا أثبت قياس حمل ممثل أن البيئة الجديدة لا تحقق زمن الخدمة وسعة العمال المطلوبة. افصل ذلك عن أخطاء المفاتيح والاتصال والجدولة.
اطلب نقلاً يشمل الأعمال الخلفية
أرسل إصدار التطبيق وخريطة القاعدة والطوابير والتخزين والمهام عبر طلب عرض سعر نقل Laravel. اطلب ضمن استضافة Laravel خطة للمفاتيح والحالة والعمال والمجدول، وتقرير قبول يثبت اكتمال عملية عمل فعلية على الوجهة الجديدة.