النشر الأزرق-الأخضر على AWS ECS لخدمات Go بدون توقف

كل نشر هو لحظة خطر. الطريقة الأبسط للقضاء على وقت توقف النشر في AWS ECS هي Blue-Green Deployment. لكن التفاصيل التشغيلية هي حيث تعثر معظم الفرق. إليك كيف ننفذها لخدمات Go في الإنتاج.

لماذا التحديث التدريجي يسبب مشاكل

التحديثات التدريجية في ECS هي الافتراضية. تستبدل تدريجياً نسخ المهام القديمة بالجديدة. للخدمات عديمة الحالة ذات عمر الطلب القصير، عادةً ما تعمل بشكل جيد. لكن هناك أنماط فشل تظهر فقط عند التدقيق.

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

النشر الأزرق-الأخضر يُلغي فترة التعايش. النسخة القديمة تظل نشطة 100% حتى التحقق الكامل من النسخة الجديدة. التبديل فوري.

بنية ECS Blue-Green

الإعداد يستخدم خدمتَي ECS ومجموعتَي هدف ALB خلف مستمع واحد:

• خدمة Blue: الإنتاج الحالي، يستقبل 100% من الحركة.
• خدمة Green: النسخة الجديدة، تُنشر وتُتحقق منها قبل تحويل الحركة.
• قاعدة مستمع ALB: تُوجَّه إلى Blue افتراضياً، قابلة للتحويل إلى Green.

عند الإصدار:

1. انشر النسخة الجديدة على خدمة Green.
2. انتظر حتى تجتاز كل مهام Green فحوصات الصحة.
3. شغّل اختبارات الدخان مقابل Green.
4. حوّل الحركة: عدّل قاعدة مستمع ALB للتوجيه إلى Green.
5. راقب معدلات الأخطاء 5-10 دقائق.
6. إذا كان مستقراً: انقل Blue للنسخة الجديدة للدورة التالية.
7. إذا لم يكن مستقراً: أعد توجيه ALB إلى Blue خلال 30 ثانية.

صحة الخدمة في Go

يجب أن يكون فحص الصحة ذا معنى. فحص يعيد 200 دائماً لا يحميك من نشر معطوب:

func (h *Handler) Health(w http.ResponseWriter, r *http.Request) {
    ctx, cancel := context.WithTimeout(r.Context(), 3*time.Second)
    defer cancel()

    if err := h.db.PingContext(ctx); err != nil {
        http.Error(w, `{"status":"unhealthy"}`, 503)
        return
    }
    w.Write([]byte(`{"status":"ok"}`))
}

الإغلاق السلس

النشر الأزرق-الأخضر لا يكون بدون توقف إلا إذا أغلقت الحاويات بشكل نظيف. حين يُصفّي ECS مهمة، يرسل SIGTERM. خدمة Go يجب أن تنهي الطلبات الجارية قبل الخروج:

quit := make(chan os.Signal, 1)
signal.Notify(quit, syscall.SIGTERM, syscall.SIGINT)
<-quit

ctx, cancel := context.WithTimeout(context.Background(), 45*time.Second)
defer cancel()
srv.Shutdown(ctx)

اضبط stopTimeout في تعريف مهمة ECS على 60 ثانية وسياق إغلاق Go على 45 ثانية. اضبط أيضاً تأخير إلغاء تسجيل ALB على 30 ثانية.

استراتيجية ترحيل قاعدة البيانات

النشر الأزرق-الأخضر يُحوّل الحركة بشكل فوري، لكن ترحيلات قاعدة البيانات لا. القاعدة التي نتبعها هي Expand-then-Migrate:

1. انشر نسخة تعمل مع كلا المخططَين القديم والجديد (إضافات فقط: أعمدة بقيم افتراضية، جداول جديدة، أعمدة قابلة للقيمة الفارغة).
2. شغّل الترحيل.
3. انشر النسخة التي تستخدم المخطط الجديد حصراً.

مراقبة فترة التحويل

مباشرة بعد تحويل الحركة إلى Green، راقب:

• معدل الأخطاء على مجموعة هدف Green.
• زمن استجابة الطلبات P99 (يجب أن يكون ضمن 20% من خط أساس Blue).
• سجلات أخطاء التطبيق في CloudWatch.
• عدد اتصالات قاعدة البيانات.

نشغّل نافذة مراقبة خمس دقائق قبل اعتبار الإصدار مستقراً. إذا انحرف أي مقياس بشكل ملحوظ، الرجوع هو أمر واحد ويستغرق ثلاث ثوان.

دروس من الإنتاج

• فحوصات الصحة يجب أن تكون ذات معنى. استجابة 200 على خدمة معطوبة تهزم الغرض.
• مهلة الإغلاق السلس يجب أن تأخذ بالاعتبار نافذة إغلاق Go ووقت تصفية ECS.
• ترحيلات قاعدة البيانات يجب أن تتبع نمط Expand-Contract.
• احتفظ بسكريبت الرجوع جاهزاً وجرّبه في بيئة التطوير قبل أول إصدار إنتاجي.

الثقة التشغيلية التي تأتي من معرفة أن أي نشر يمكن التراجع عنه في ثلاث ثوان تغيّر طريقة تعامل الفرق مع الإصدارات عملياً.