نشر الأزرق الأخضر والكناري

نشر أزرق أخضر وكناري

1) التحدي والأفكار الرئيسية

• الأزرق الأخضر: احتفظ بنسختين متوازيتين (أزرق - نشط، أخضر - جديد)، قم بتبديل حركة المرور ذريًا. التراجع السريع → يعود الأزرق على الفور.
• كناري: قم بتشغيل الإصدار الجديد على مراحل (1٪ → 5٪ → 25٪ → 50٪ → 100٪)، راقب مقاييس SLO وتوقف/تراجع أثناء التحلل.

المبدأ العام هو فصل «تسليم القطع الأثرية» عن «إدراج حركة المرور» وأتمتة إمكانية الملاحظة + التراجع.

2) متى تختار

• يحتاج إلى تبديل فوري (RTO)، خدمات بسيطة بدون دولة ؛
• وهناك نوافذ صارمة للإطلاق/التجميد وفحوصات صافية للدخان ؛
• من المكلف الاحتفاظ بقدرة مضاعفة طويلة - لكن من الممكن لفترة قصيرة.

• تغييرات معقدة، يلزم التحقق تدريجيا من صحة حركة المرور الحقيقية ؛
• هناك قياس ناضج عن بعد (SLO، مقاييس الأعمال)، قدرة التوقف التلقائي ؛
• الحد بشكل حاسم من نصف قطر الضرر (fintech/iGaming streams).

نمط المجموعة: طرح اللون الأخضر والتبديل إليه من خلال مراحل الكناري (الأزرق الأخضر كإطار، كناري كطريقة لحمل حركة المرور).

3) بنية توجيه حركة المرور

1. موازن L4/L7 (ALB/NLB، Cloud Load Balancer) - المجموعات المستهدفة المرجحة.

2. بوابة واجهة برمجة التطبيقات/WAF - المسار/الوزن حسب الإصدارات والرؤوس وملفات تعريف الارتباط والمناطق.

3. Service Mesh (Istio/Linkerd/Consul) - توزيع النسبة المئوية، حقن الأخطاء، المهلة/إعادة الطباعة/مقابض التقييد.

4. الدخول/NGINX/المبعوث - أوزان المنبع وتوجيه السمات.

5. Argo Rollouts/Flagger - وحدة تحكم المشغل، والتقدم التلقائي، والتكامل مع Prometheus/New Relic/Datadog.

4) Kubernetes: قوالب عملية

4. 1 Blue-Green (عبر محدد الخدمة)

نشر Два: «زرقاء التطبيق» и «خضراء التطبيق».
خدمة واحدة «تطبيق svc» مع محدد لـ «الإصدار» المطلوب.

yaml apiVersion: apps/v1 kind: Deployment metadata: { name: app-green, labels: { app: app, version: green } }
spec:
replicas: 4 selector: { matchLabels: { app: app, version: green } }
template:
metadata: { labels: { app: app, version: green } }
spec:
containers:
- name: app image: ghcr. io/org/app:1. 8. 0 apiVersion: v1 kind: Service metadata: { name: app-svc }
spec:
selector: {app: app, version: blue} # ← switch to green - change ports: [{port: 80, targetPort: 8080}]

التبديل - التغيير الذري للمحدد (أو الملصقات) مع التصريف المتحكم فيه.

4. 2 كناري (Istio VirtualService)

yaml apiVersion: networking. istio. io/v1beta1 kind: VirtualService metadata: { name: app }
spec:
hosts: ["app. example. com"]
http:
- route:
- destination: { host: app. blue. svc. cluster. local, subset: v1 }
weight: 90
- destination: { host: app. green. svc. cluster. local, subset: v2 }
weight: 10

تغيير «الوزن» خطوة بخطوة ؛ أضف إعادة تجربة، مهلة، كاشف خارجي إلى DestinationRule.

4. 3 Argo Rollouts (تشغيل الكناري التلقائي)

yaml apiVersion: argoproj. io/v1alpha1 kind: Rollout metadata: { name: app }
spec:
replicas: 6 strategy:
canary:
canaryService: app-canary stableService: app-stable steps:
- setWeight: 5
- pause: {duration: 300} # 5 min observation
- analysis:
templates:
- templateName: slo-guard
- setWeight: 25
- pause: { duration: 600 }
- analysis:
templates: [{ templateName: slo-guard }]
- setWeight: 50
- pause: {}
trafficRouting:
istio:
virtualService:
name: app routes: ["http-route"]

يرتبط تحليل النموذج بالمقاييس (انظر أدناه).

5) بوابات SLO والتراجع التلقائي

• تقنية: «p95 _ latency»، «5xx _ rate»، «خطأ _ ميزانية _ حرق»، «وحدة المعالجة المركزية/خنق الذاكرة».
• البقالة: «CR (إيداع)»، «نجاح المدفوعات»، «احتيال التسجيل»، «ARPPU» (على النوافذ الباردة).

• إذا كان معدل 5xx من الإصدار الجديد> 0. 5٪ لمدة 10 دقائق - توقف مؤقتًا وتراجع.
• إذا كان 'p95 _ latency' ↑> 20٪ من القاعدة - التراجع.
• إذا استمر الترويج للكناري ولكن الميزانية SLO محروقة> 2 ٪/ساعة - انتظر.

yaml apiVersion: argoproj. io/v1alpha1 kind: AnalysisTemplate metadata: { name: slo-guard }
spec:
metrics:
- name: http_5xx_rate interval: 1m successCondition: result < 0. 005 provider:
prometheus:
address: http://prometheus. monitoring:9090 query:
sum(rate(http_requests_total{app="app",status=~"5.."}[5m])) /
sum(rate(http_requests_total{app="app"}[5m]))

6) البيانات والتوافق (السبب الأكثر شيوعًا للألم)

• التوسع: إضافة أعمدة/فهارس جديدة غير قابلة للإلغاء، ودعم كلا المخططين.
• هاجر: الكتابة المزدوجة/القراءة، ملء الظهر.
• العقد: حذف الحقول القديمة/الرمز بعد الخروج من 100٪ من حركة المرور.
• الحدث/قوائم الانتظار: حمولة الإصدار (v1/v2)، دعم الخصوصية.
• ذاكرة التخزين المؤقت/الجلسات: مفاتيح النسخة ؛ ضمان توافق الشكل.

7) التكامل مع CI/CD و GitOps

CI: بناء مرة واحدة، توقيع الصورة، SBOM، الاختبارات.
القرص المدمج: ترويج القطع الأثرية من خلال البيئات ؛ يحكم بلو جرين/كناري البيانات.
GitOps: وحدة تحكم → MR (Argo CD/Flux) تطبق الأوزان/المحددات.
البيئات/الموافقات: لخطوات الإنتاج - البوابة اليدوية + قرارات التدقيق.

8) NGINX/المبعوث و Cloud LBs: أمثلة سريعة

8. 1 NGINX (أوزان المنبع)

nginx upstream app_upstream {
server app-blue:8080 weight=90;
server app-green:8080 weight=10;
}
server {
location / { proxy_pass http://app_upstream; }
}

8. 2 AWS ALB (المجموعات المستهدفة المرجحة)

TG-Blue: 90، TG-Green: 10 → تغير الأوزان عبر IaC/CLI.
ربط تنبيهات CloudWatch للتراجع عن النصوص التلقائية (تغيير الوزن إلى 0/100).

9) السلامة والامتثال

صفر الثقة بين الإصدارات: التمييز بين أسرار التشفير/مفاتيح التشفير.
Policy-as-Code: رفض نشر الصورة غير الموقعة، «لا أحدث».
الأسرار والتكوينات كقطع أثرية للنسخة ؛ يتضمن التراجع عن التكوينات.
التدقيق: من، عندما رفع الوزن/غير المحدد، بأي تذكرة.

10) التكلفة والقدرة

يتطلب Blue-Green ضعف الطاقة لفترة الإصدار → تخطيط النافذة.
يمكن أن يستمر الكناري لفترة أطول → تكلفة القياس عن بعد/المراقبة، والمحتوى الموازي لنسختين.
التحسين: التوزيع التلقائي بواسطة HPA/VPA، والنوافذ القصيرة الزرقاء الخضراء، والإصدارات الليلية للخدمات «الثقيلة».

11) كتب التشغيل

1. أوقف الترقية مؤقتًا.
2. خفض الوزن الأخضر إلى 0٪ (الكناري )/محدد العودة إلى الأزرق (الأزرق الأخضر).
3. تحقق: عادت الأخطاء/زمن الوصول إلى اتصالات الصرف الأساسية.
4. افتح حادثة، جمع القطع الأثرية (جذوع الأشجار، المسارات، مقارنة المقاييس).
5. إصلاح/إعادة برمجة المسرح، وقيادة الدخان، وإعادة تشغيل التقدم.

12) الأنماط المضادة

إعادة بناء قطعة أثرية بين المسرح والحث (انتهاك «البناء مرة واحدة»).
الكناري «الأصم» بدون SLO/المقاييس هو إجراء شكلي وليس دفاعًا.
نقص أعلام الميزات: يضطر الإصدار إلى تضمين السلوك بنسبة 100٪ في وقت واحد.
الفحوصات الصحية/الحيوية غير العاملة → القيعان «اللزجة» والاستقرار الزائف.
توافق قاعدة البيانات «بشكل عشوائي»: ينتهي العقد عند التبديل.
علامات الصورة القابلة للتغيير/« الأحدث »في الحافز.

13) قائمة التنفيذ المرجعية (0-45 يومًا)

0-10 أيام

اختر استراتيجية للخدمات: B/G أو Canary أو مجتمعة.
مكّن من توقيع الصور والفحوصات الصحية وعينات الاستعداد و «لا أحدث».
قم بإعداد لوحات معلومات SLO (الكمون/معدل الخطأ/مقاييس الأعمال).

11-25 يومًا

أتمتة الأوزان (Istio/Argo Rollouts/ALB-weights).
ضبط التحليل القوالب، التنبيهات والتراجع التلقائي.
بيان القالب (Helm/Kustomize)، يتكامل مع GitOps.

26-45 يومًا

تنفيذ استراتيجية عقود الانتقال الموسعة لقاعدة البيانات.
قم بتغطية أعلام تبديل القتل الحرجة.
اقض «يوم اللعبة»: قم بمحاكاة التراجع والحادث.

14) مقاييس النضج

النسبة المئوية للإطلاقات من خلال Blue-Green/Canary (الهدف> 90٪).
متوسط وقت التبديل/التراجع (الهدف <3 دقائق).
حصة الإصدارات مع التوقف التلقائي SLO (وبدون حوادث).
تغطية الخدمة عن بعد (آثار/سجلات/مقاييس)> 95٪.
تبلغ حصة هجرات DB وفقًا لخطة عقود الهجرة الموسعة أكثر من 90٪.

15) المرفقات: نماذج السياسة وخط الأنابيب

OPA (عدم السماح بالصور غير الموقعة)

rego package admission. image

deny[msg] {
input. request. kind. kind == "Deployment"
some c img:= input. request. object. spec. template. spec. containers[c].image not startswith(img, "ghcr. io/org/")
msg:= sprintf("Image not from trusted registry: %v", [img])
}

قيم هيلم للكناري (مبسطة)

yaml canary:
enabled: true steps:
- weight: 5 pause: 300
- weight: 25 pause: 600
- weight: 50 pause: 900 sloGuards:
max5xxPct: 0. 5 maxP95IncreasePct: 20

إجراءات GitHub - تعزيز الوزن (زائف)

yaml
- name: Promote canary to 25%
run: kubectl patch virtualservice app \
--type=json \
-p='[{"op":"replace","path":"/spec/http/0/route/1/weight","value":25}]'

16)

لا يستبعد الأزرق والأخضر والكناري بعضهما البعض، بل استراتيجيات متكاملة. قم ببنائها فوق القطع الأثرية الموقعة وإمكانية رصد SLO والبوابات التلقائية والتحكم في GitOps. التسليم المنفصل عن الشمول، والحفاظ على التراجع السريع وانضباط الهجرة - وتصبح الإصدارات متوقعة وآمنة وسريعة.