المستوى: متوسط — المقال مكتوب لحد عارف يعني إيه deploy وload balancer، وتعامل مع سيرفر إنتاج قبل كده. لو لسه مبتدئ، فيه مثال بسيط في الأول هيوصّلك الفكرة قبل التفاصيل التقنية.

Blue-Green Deployment: تنشر النسخة الجديدة وانت مغمّض

أهم مكسب من المقال ده: تنشر تحديث على الإنتاج من غير ما المستخدم يشوف ثانية توقف واحدة، ولو طلع خطأ ترجّع النسخة القديمة في تمن ثواني بدل ما تعيد deploy كامل في ست دقايق.

المشكلة باختصار

الطريقة الشائعة إنك توقّف الخدمة، تحدّث الكود، تشغّلها تاني. ده بيفشل في حاجتين. الأولى إن المستخدم بيشوف صفحة 502 طول مدة التحديث. التانية إن لو النسخة الجديدة فيها bug، الرجوع معناه deploy تاني من الأول، والناس بتتألم طول الوقت ده.

الافتراض هنا إن عندك خدمة بتشتغل 24 ساعة وفيها ترافيك حقيقي، يعني نافذة الصيانة مش رفاهية متاحة ليك.

الفكرة الأساسية بمثال بسيط

تخيّل مطعم عنده مطبخين متطابقين، أزرق وأخضر. الزباين كلهم بياكلوا من المطبخ الأزرق دلوقتي. عايز تجرّب وصفة جديدة؟ بتجهّزها بالكامل في المطبخ الأخضر وانت مقفول من غير ما حد ياكل منه. تتأكد إن كل حاجة تمام، وبعدين بتقول للجرسون: من دلوقتي قدّم من الأخضر. التحويل بيحصل في لحظة، والزبون مالحظش حاجة. لو طلعت الوصفة الجديدة وحشة، بترجّع الجرسون للأزرق على طول، والأزرق لسه شغّال زي ما هو.

علميًا: Blue-Green Deployment معناه إنك بتشغّل نسختين متطابقتين من بيئة الإنتاج بالتوازي. واحدة بس هي اللي بتستقبل ترافيك المستخدمين في كل لحظة (Blue)، والتانية (Green) بتستقبل النسخة الجديدة وبتتجرّب عليها. النشر بيتحوّل لعملية واحدة: تحويل مسار الترافيك من Blue لـ Green على مستوى الـ load balancer أو الـ DNS. مفيش إعادة تشغيل، ومفيش توقف.

التطبيق العملي بـ Nginx

أبسط شكل: عندك بيئتين شغّالتين على بورتين مختلفين، والـ Nginx بيوجّه الترافيك لواحدة منهم. التبديل بيبقى تغيير سطر واحد و reload.

البيئة الزرقاء على البورت 8080، والخضراء على 8081. ملف الإعداد بيشاور على ملف upstream منفصل:

# /etc/nginx/conf.d/app.conf
upstream app_backend {
    server 127.0.0.1:8080;   # blue (live حاليًا)
}

server {
    listen 80;
    server_name app.example.com;

    location / {
        proxy_pass http://app_backend;
        proxy_set_header Host $host;
    }
}

دلوقتي نزّل النسخة الجديدة على البورت 8081 (green) وجرّبها داخليًا. لما تطمّن، بدّل سطر واحد وأعمل reload من غير قطع للاتصالات المفتوحة:

# 1) شغّل النسخة الجديدة على بورت green
docker run -d --name app-green -p 8081:3000 myapp:v2

# 2) اعمل health check داخلي قبل أي تحويل
curl -fsS http://127.0.0.1:8081/health || { echo "green مش جاهز"; exit 1; }

# 3) بدّل الـ upstream من 8080 لـ 8081
sed -i 's/127.0.0.1:8080/127.0.0.1:8081/' /etc/nginx/conf.d/app.conf

# 4) reload بدون إسقاط الاتصالات الحالية
nginx -t && nginx -s reload

دلوقتي كل الترافيك الجديد رايح على green. سيب الأزرق شغّال. لو حصل خطأ بعد دقيقة، الرجوع هو نفس الخطوة بالعكس:

# rollback فوري: رجّع التوجيه للبيئة الزرقاء
sed -i 's/127.0.0.1:8081/127.0.0.1:8080/' /etc/nginx/conf.d/app.conf
nginx -t && nginx -s reload

الأرقام: قبل وبعد

على خدمة fintech بسيطة (سيرفر واحد، حوالي 12 ألف طلب/ساعة) كان الـ rolling restart التقليدي بياخد حوالي 45 ثانية كل المستخدمين فيها بيشوفوا أخطاء 5xx. بعد Blue-Green: التوقف صفر، لأن التبديل بيحصل في reload أقل من ثانية والاتصالات القديمة بتكمل على الأزرق. الأهم: زمن الرجوع نزل من 6 دقايق (إعادة build وdeploy) لـ 8 ثواني (reload عكسي). دي تقديرات مقاسة على إعداد واحد؛ النتيجة بتختلف حسب حجم الترافيك ووقت الـ health check.

الـ trade-offs اللي لازم تعرفها

• تكلفة بنية تحتية مضاعفة وقت النشر: بتكسب نشر بدون توقف، بتخسر إنك بتشغّل نسختين كاملتين بالتوازي. لو سيرفرك بياخد 4GB RAM، هتحتاج 8GB في لحظة التبديل. على cloud ده ممكن يبقى دقايق من الفاتورة المضاعفة بس، لكنه حقيقي.
• قاعدة البيانات هي العقدة الصعبة: البيئتين غالبًا بيشاركوا نفس الـ database. ده معناه إن أي migration لازم تبقى backward compatible — يعني الـ schema الجديد يشتغل مع الكود القديم والجديد في نفس الوقت. لو عملت DROP COLUMN قبل ما تبدّل، الأزرق هيكسر.
• الجلسات والحالة (state): لو بتخزّن session في ذاكرة السيرفر، التبديل هيطرد المستخدمين. لازم تكون الجلسات في مكان مشترك زي Redis قبل ما تفكّر في Blue-Green.

متى لا تستخدم هذه الطريقة

متستخدمهاش لو عندك تطبيق صغير وعميلك متقبّل نافذة صيانة بالليل — التعقيد مش مستاهل وقتها. وكمان متستخدمهاش لو الـ migrations عندك بطبيعتها مدمّرة (destructive) وصعب تخليها backward compatible، لأن مشاركة الـ database هتوقعك. ولو تكلفة مضاعفة الموارد في ساعة الذروة عبء على ميزانيتك، الـ Canary deployment (تحويل تدريجي لنسبة صغيرة من الترافيك) بيبقى أوفر في الموارد.

الخطوة التالية

افتح إعداد الـ Nginx بتاعك دلوقتي وتأكد من حاجة واحدة: هل عندك endpoint اسمه /health بيرجّع 200 بس لما التطبيق يبقى جاهز فعلًا (متصل بالـ DB وكله تمام)؟ لو لأ، ده أول حاجة تعملها قبل أي Blue-Green، لأن التحويل من غير health check حقيقي معناه إنك ممكن تبدّل لبيئة لسه مش جاهزة. ضيف الـ endpoint، اربطه بفحص اتصال الـ DB، وبعدين ابنِ خطوة التبديل فوقه.

المصادر

• Martin Fowler — "BlueGreenDeployment" (martinfowler.com)، التعريف الأصلي للنمط.
• AWS — "Blue/Green Deployments" ضمن AWS Well-Architected وWhitepaper الخاص بـ deployment strategies.
• توثيق Nginx الرسمي — أوامر nginx -s reload والـ graceful configuration reload (nginx.org).
• توثيق Kubernetes — Services وتبديل الـ selector بين نسختين (kubernetes.io).