DevOps والبنية التحتية
أنشر Laravel وNode على Linux مع Docker ووكلاء عكسيين ونسخ احتياطي ومراقبة كافية لمعرفة الخلل قبل العميل.
يعني Docker أن البيئة المُختبرة هي نفسها التي تُنشر — نفس الحاويات ونفس إصدارات التبعيات — بدل نشر يعمل على جهاز وينهار غامضاً على آخر. يُنهي وكيل عكسي طبقة TLS ويوجّه الحركة إلى الحاوية الصحيحة، ويُشغّل CI/CD نفس خطوات البناء والاختبار مع كل دفعة حتى يُكتشف نشر معطوب قبل وصوله للإنتاج لا بعده.
النسخ الاحتياطي حقيقي فقط إذا اختُبرت استعادته مرة واحدة على الأقل. أُعِدّ نسخاً احتياطية مجدولة لـ PostgreSQL أو MySQL أو SQLite حسب الحزمة، وأتحقق أن الاستعادة تعمل فعلاً بدل الوثوق بأن مهمة cron نجحت بصمت طوال العام الماضي.
المراقبة مملة عمداً: فحوصات توفر وتتبع أخطاء وتجميع سجلات بحجم الفريق الفعلي، لا لوحة لا ينظر إليها أحد. الهدف معرفة المشكلة من تنبيه لا من تذكرة دعم عميل.
مشاكل الأعمال
- نشر لا يعمل إلا لأنه يعيش في ذهن مطور واحد وإعداد جهاز واحد.
- نسخ احتياطي لم تُستعَد قط، فلا يعرف أحد فعلياً إن كانت تعمل حتى يوم الحاجة إليها.
- بلا مراقبة، فيعلم الفريق بعطل من عميل لا من تنبيه.
- أسرار ومفاتيح API مُسجَّلة في المستودع أو متبادلة عبر الدردشة، بدل إدارتها عبر متغيرات بيئة أو مدير أسرار.
- خادم VPS واحد يشغّل قاعدة البيانات والتطبيق والوكيل العكسي دون فصل، فيمكن لنشر سيئ إسقاط الحزمة كاملة دفعة واحدة.
- لا بيئة تجريبية قريبة بما يكفي من الإنتاج لاكتشاف فرق في الإعداد قبل وصوله للعملاء.
- إعداد خادم يدوي وغير موثّق، فيعني استبدال VPS معطل إعادة بناء الإعداد من الذاكرة بدل تشغيل سكربت.
- سجلات متناثرة عبر الحاويات بلا مكان مركزي للبحث فيها، فيعني تصحيح مشكلة الدخول عبر SSH إلى ثلاثة أماكن مختلفة والبحث يدوياً.
منهج التطوير
- حوسبة التطبيق بحاويات Docker حتى تكون البيئة المُختبرة هي نفسها التي تُنشر، مع وكيل عكسي يتولى TLS والتوجيه.
- إعداد CI/CD حتى يشغّل كل دفعة نفس خطوات البناء والاختبار، فيُكتشف نشر معطوب قبل وصوله للإنتاج.
- جدولة نسخ احتياطي لقاعدة البيانات المستخدمة فعلاً — PostgreSQL أو MySQL أو SQLite — والتحقق من الاستعادة لا رمز خروج مهمة النسخ فقط.
- إدارة الأسرار عبر متغيرات بيئة أو مدير أسرار، دون تسجيلها أبداً في المستودع، وتدويرها عند مغادرة أحد ممن يملكون وصولاً.
- فصل المسؤوليات حتى على خادم واحد — قاعدة بيانات وتطبيق ووكيل عكسي كل في حاويته الخاصة — حتى لا يُسقط نشر سيئ لأحدها البقية.
- إبقاء البيئة التجريبية قريبة بما يكفي من الإنتاج — نفس الحاويات وشكل بيانات مشابه — حتى يظهر فرق الإعداد هناك لا أمام العملاء.
- برمجة تهيئة الخوادم (أو استخدام البنية التحتية كشيفرة) حتى يكون استبدال VPS معطل تشغيل سكربت لا إعادة بناء إعداد من الذاكرة تحت الضغط.
- تجميع سجلات كل حاوية في مكان واحد قابل للبحث، حتى يكون تصحيح مشكلة استعلام بحث لا جلسة SSH في ثلاثة أجهزة مختلفة.
ما تحصل عليه
- نشر يعمل بنفس الطريقة على الجهاز التالي كما عمل على الأول، لأن البيئة مُعرَّفة في الكود لا في الذاكرة.
- نسخ احتياطي أُثبتت استعادتها فعلاً، لا مجدولة فقط على أمل أن تعمل.
- مشاكل يكشفها تنبيه قبل أن يلاحظها عميل، لأن المراقبة مُحجَّمة للفريق لا مُتجاهلة كلوحة لا يفتحها أحد.
- أسرار لا تجلس في سجل git بحيث يجدها أي شخص يملك وصولاً للمستودع.
- نشر سيئ يُسقط حاوية واحدة بدل الحزمة كاملة، لأن المسؤوليات فُصلت منذ البداية.
- فروق إعداد تُكتشف في البيئة التجريبية قبل وصولها لعميل، بدل تصحيحها حية في الإنتاج.
- خادم معطل يُستبدل بتشغيل سكربت خلال دقائق، بدل بعد ظهر مرهق لإعادة بناء الإعداد من الذاكرة.
- مشكلة تُصحَّح من عرض سجلات واحد قابل للبحث بدل جلسات SSH في ثلاث حاويات مختلفة على أمل إيجاد السطر الصحيح.
- سجل نشر يُظهر بالضبط ما تغيّر ومتى، حتى يمكن تتبّع أي تراجع إلى الالتزام الذي سبّبه بدل تخمينه.
مشاريع مختارة
أسئلة شائعة
Do you work with AWS?
Yes, when the product needs it. Many products are better served by a well-run VPS plus Docker until traffic or compliance says otherwise.