استراتيجيات النشر: Blue-Green وCanary والمتدرج

أسئلة استراتيجية النشر تختبر فهمك لموثوقية الإنتاج. دعنا نتقن كل نهج.

مقارنة استراتيجيات النشر

الاستراتيجية	المخاطرة	سرعة التراجع	تكلفة الموارد	التعقيد
المتدرج	متوسطة	بطيء	منخفضة	منخفض
Blue-Green	منخفضة	فوري	عالية (2x)	متوسط
Canary	الأدنى	سريع	متوسطة	عالي
Shadow	الأدنى	غير متاح	عالية	الأعلى

النشر المتدرج

يُحدّث الحالات تدريجياً:

الوقت 0: [v1] [v1] [v1] [v1]
الوقت 1: [v2] [v1] [v1] [v1]
الوقت 2: [v2] [v2] [v1] [v1]
الوقت 3: [v2] [v2] [v2] [v1]
الوقت 4: [v2] [v2] [v2] [v2]

التحديث المتدرج في Kubernetes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # الحد الأقصى للـ pods الإضافية أثناء التحديث
      maxUnavailable: 1  # الحد الأقصى للـ pods غير المتاحة أثناء التحديث
  selector:
    matchLabels:
      app: web
  template:
    spec:
      containers:
      - name: web
        image: app:v2
        readinessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 5

الإيجابيات: بسيط، حمل موارد منخفض السلبيات: تراجع أبطأ، إصدارات مختلطة أثناء النشر

نشر Blue-Green

حافظ على بيئتين متطابقتين:

              ┌─────────────┐
              │  موازن      │
              │  الحمل      │
              └──────┬──────┘
                     │
         ┌───────────┴───────────┐
         │                       │
    ┌────▼────┐             ┌────▼────┐
    │  Blue   │             │  Green  │
    │  (v1)   │             │  (v2)   │
    │ نشط    │             │ احتياط  │
    └─────────┘             └─────────┘

AWS Blue-Green مع ALB

# مجموعات الهدف لـ blue و green
resource "aws_lb_target_group" "blue" {
  name     = "blue-tg"
  port     = 80
  protocol = "HTTP"
  vpc_id   = var.vpc_id
}

resource "aws_lb_target_group" "green" {
  name     = "green-tg"
  port     = 80
  protocol = "HTTP"
  vpc_id   = var.vpc_id
}

# قاعدة المستمع - التبديل بين blue/green
resource "aws_lb_listener_rule" "main" {
  listener_arn = aws_lb_listener.main.arn

  action {
    type             = "forward"
    target_group_arn = var.active_color == "blue" ? aws_lb_target_group.blue.arn : aws_lb_target_group.green.arn
  }

  condition {
    path_pattern {
      values = ["/*"]
    }
  }
}

الإيجابيات: تراجع فوري، نشر بدون توقف السلبيات: تكلفة بنية تحتية مضاعفة، هجرات قاعدة البيانات معقدة

نشر Canary

نقل حركة المرور تدريجياً للإصدار الجديد:

المرحلة 1:  [v1: 95%] ────► [v2: 5%]   # اختبر مع 5%
المرحلة 2:  [v1: 80%] ────► [v2: 20%]  # زد إذا صحي
المرحلة 3:  [v1: 50%] ────► [v2: 50%]  # نصف-نصف
المرحلة 4:  [v1: 0%]  ────► [v2: 100%] # طرح كامل

Canary في Kubernetes مع Istio

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: web-app
spec:
  hosts:
  - web-app
  http:
  - route:
    - destination:
        host: web-app
        subset: stable
      weight: 90
    - destination:
        host: web-app
        subset: canary
      weight: 10

---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: web-app
spec:
  host: web-app
  subsets:
  - name: stable
    labels:
      version: v1
  - name: canary
    labels:
      version: v2

تحليل Canary

# Argo Rollouts canary مع التحليل
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: web-app
spec:
  strategy:
    canary:
      steps:
      - setWeight: 5
      - pause: {duration: 5m}
      - analysis:
          templates:
          - templateName: success-rate
      - setWeight: 25
      - pause: {duration: 5m}
      - setWeight: 50
      - pause: {duration: 5m}
      - setWeight: 100

---
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate
spec:
  metrics:
  - name: success-rate
    interval: 1m
    successCondition: result[0] >= 0.95
    provider:
      prometheus:
        address: http://prometheus:9090
        query: |
          sum(rate(http_requests_total{status=~"2.."}[5m])) /
          sum(rate(http_requests_total[5m]))

الإيجابيات: أقل مخاطرة، قرارات مبنية على البيانات السلبيات: إعداد معقد، يتطلب ملاحظة جيدة

أسئلة المقابلة

س: "الـ canary يُظهر معدل خطأ 2% مقابل 0.5% للمستقر. ماذا تفعل؟"

الجواب:

1. لا تذعر - اجمع المزيد من البيانات أولاً
2. تحقق إذا ذو دلالة إحصائية - 5% من الحركة قد تحتوي على ضوضاء
3. افحص أنواع الأخطاء - هل هي أخطاء جديدة أم موجودة؟
4. تحقق من المقاييس - زمن الاستجابة، CPU، ذاكرة pods الـ canary
5. إذا تأكد أنه سيء - تراجع تلقائي أو يدوي
6. السبب الجذري - تحقق قبل المحاولة التالية

س: "كيف تتعامل مع هجرات قاعدة البيانات في blue-green؟"

الجواب:

النهج	الوصف
Expand-Contract	أضف المخطط الجديد بجانب القديم، هاجر، ثم احذف القديم
أعلام الميزات	انشر كود يتعامل مع كلا المخططين
نسخ القراءة	Blue يقرأ من الأساسي، green من النسخة أثناء الهجرة
متوافق للخلف	تأكد أن مخطط v2 يعمل مع كود v1

-- مرحلة Expand (تعمل مع كلا الإصدارين)
ALTER TABLE users ADD COLUMN email_verified BOOLEAN DEFAULT false;

-- مرحلة Contract (بعد ذهاب v1)
ALTER TABLE users DROP COLUMN old_column;

س: "النشر المتدرج عالق عند 50%. كيف تستكشف الأخطاء؟"

# تحقق من حالة النشر
kubectl rollout status deployment/web-app

# تحقق من حالة pod
kubectl get pods -l app=web-app
kubectl describe pod <stuck-pod>

# تحقق من الأحداث
kubectl get events --sort-by='.lastTimestamp'

# المشاكل الشائعة:
# - فشل readiness probe
# - أخطاء سحب الصورة
# - حدود الموارد (pods معلقة)
# - PodDisruptionBudget يحظر

لقد أتقنت CI/CD وIaC. الوحدة التالية: Kubernetes وتنسيق الحاويات—قلب البنية التحتية الحديثة. :::