آبی سبز و قناری استقرار

آبی سبز و قناری استقرار

1) چالش و ایده های کلیدی

• آبی سبز: نگه داشتن دو نسخه موازی (آبی فعال، سبز جدید)، تغییر ترافیک اتمی. بازگشت سریع → فورا بازگشت آبی.
• Canary: نسخه جدید را در مراحل روشن کنید (1٪ → 5٪ → 25٪ → 50٪ → 100٪)، معیارهای SLO را نظارت کنید و در هنگام تخریب متوقف/رول کنید.

اصل کلی این است که «تحویل مصنوعی» را از «ورود به ترافیک» جدا کنید و قابلیت مشاهده خودکار را افزایش دهید.

2) هنگامی که انتخاب کنید

• نیاز به سوئیچینگ فوری (RTO سخت)، خدمات ساده بدون حالت ؛
• پنجره های آزادی/انجماد دقیق و چک های دود روشن وجود دارد ؛
• نگه داشتن ظرفیت دو برابر طولانی گران است - اما برای مدت کوتاهی امکان پذیر است.

• تغییرات پیچیده، اعتبار سنجی گام به گام در ترافیک واقعی مورد نیاز است.
• تله متری بالغ (SLO، معیارهای تجاری)، قابلیت توقف خودکار وجود دارد.
• بحرانی محدود کردن شعاع آسیب (fintech/iGaming جریان).

الگوی دسته کوچک موسیقی جاز: رول از سبز و سوئیچ به آن را از طریق قناری مراحل (آبی سبز به عنوان یک قاب، قناری به عنوان یک روش حمل ترافیک).

3) معماری مسیریابی ترافیک

1. متعادل کننده L4/L7 (ALB/NLB، متعادل کننده بار ابر) - گروه های هدف وزن.

2. دروازه API/WAF - مسیر/وزن توسط نسخه ها، هدر ها، کوکی ها، مناطق.

3. مش سرویس (Istio/Linkerd/Consul) - توزیع درصد، تزریق خطا، دستگیره های timeout/retray/restriction.

4. Ingress/NGINX/Envoy - وزن بالادست و مسیریابی ویژگی.

5. Argo Rollouts/Flagger - اپراتور-کنترل کننده، پیشرفت خودکار، ادغام با Prometheus/New Relic/Datadog.

4) Kubernetes: قالب های عملی

4. 1 آبی سبز (از طریق انتخاب خدمات)

استقرار Два: «برنامه آبی» и «برنامه سبز».
یک سرویس «app-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 قناری (ایستگاه سرویس مجازی)

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

تغییر «وزن» به گام ؛ اضافه کردن تلاش مجدد, اتمام وقت, outlier-detector به DestinationRule.

4. 3 آرگو رول اوت (اجرای خودکار قناری)

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»، «error _ budget _ burn»، «CPU/Memory throttling».
• مواد غذایی: «CR (سپرده)»، «موفقیت پرداخت»، «تقلب نمره»، «ARPPU» (در پنجره های سرد).

• اگر «5xx _ rate» نسخه جدید> 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) داده ها و سازگاری (شایع ترین علت درد)

• گسترش: ستون ها/شاخص های nullable جدید را اضافه کنید، از هر دو طرح پشتیبانی کنید.
• مهاجرت: دوبار نوشتن/خواندن، پر کردن مجدد.
• قرارداد: پس از خروج 100٪ از ترافیک، فیلدها/کد قدیمی را حذف کنید.
• رویداد/صف: نسخه payload (v1/v2)، idempotency پشتیبانی.
• کش/جلسات: کلید نسخه; اطمینان از سازگاری فرمت.

7) ادغام با CI/CD و GitOps

CI: ساخت یک بار، امضای تصویر، SBOM، آزمایش.
CD: ارتقاء مصنوعی از طریق محیط ؛ آبی سبز/قناری توسط مانیفست اداره می شود.
GitOps: MR → کنترل کننده (Argo CD/Flux) وزن/انتخابگرها را اعمال می کند.
محیط/مصوبات: برای مراحل تولید - دروازه دستی + تصمیمات حسابرسی.

8) NGINX/Envoy و Cloud LB: نمونه های سریع

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-آبی: 90, TG-سبز: 10 → تغییر وزن از طریق IaC/CLI.
لینک هشدار CloudWatch به بازگشت خودکار اسکریپت (تغییر وزن به 0/100).

9) ایمنی و انطباق

اعتماد صفر بین نسخه ها: تمایز بین اسرار رمزگذاری/کلید های نورد.
سیاست به عنوان کد: disallow unsigned image deploy, 'no latest'.
اسرار و پیکربندی به عنوان مصنوعات نسخه ؛ rollback شامل rollback تنظیمات است.
حسابرسی: چه کسی، زمانی که او وزن را بلند کرد/انتخاب را تغییر داد، با چه بلیط.

10) هزینه و ظرفیت

آبی سبز نیاز به دو برابر قدرت برای دوره انتشار، برنامه ریزی یک پنجره.
Canary می تواند طولانی تر → هزینه تله متری/نظارت، محتوای موازی دو نسخه.
بهینه سازی: خودکار سازی توسط HPA/VPA، پنجره های کوتاه آبی سبز، انتشار شب برای خدمات سنگین.

11) کتابهای اجرا

1. ترفیع را متوقف کنید

2. کاهش وزن سبز به 0٪ (قناری )/انتخاب بازگشت به آبی (آبی سبز).
3. بررسی: خطاها/تأخیر به اتصالات اساسی و تخلیه بازگشته است.
4. باز کردن یک حادثه، جمع آوری مصنوعات (سیاهههای مربوط، آهنگ، مقایسه معیارها).
5. ثابت/reprod به مرحله، درایو دود، راه اندازی مجدد پیشرفت.

12) ضد الگوهای

بازسازی یک مصنوع بین مرحله و prod (نقض «ساخت یک بار»).
قناری «ناشنوا» بدون SLO/معیارها یک تشریفات است، نه دفاع.
فقدان پرچم های ویژگی: انتشار مجبور است رفتار 100٪ را در یک بار شامل شود.
Non-working health-checks/liveness → «چسبنده» پایین و ثبات کاذب.
سازگاری پایگاه داده «تصادفی»: قرارداد هنگام تعویض خراب می شود.
برچسب های تصویر قابل تغییر/« آخرین »در تولید.

13) چک لیست پیاده سازی (0-45 روز)

0-10 روز

یک استراتژی برای خدمات انتخاب کنید: B/G، Canary یا ترکیبی.
امضای تصویر، چک های بهداشتی، نمونه های آمادگی، «آخرین» را فعال کنید.
آماده داشبورد SLO (تاخیر/نرخ خطا/معیارهای کسب و کار).

11-25 روز

خودکار وزن (Istio/Argo Rollouts/ALB-وزن).
پیکربندی قالب های تجزیه و تحلیل، هشدارها و بازگشت خودکار.
جلوه های قالب (Helm/Kustomize)، با GitOps ادغام می شود.

26-45 روز

پیاده سازی استراتژی expand-migrate-contract برای پایگاه داده.
پوشش بحرانی کشتن سوئیچ پرچم.
صرف «روز بازی»: شبیه سازی بازگشت و حادثه.

14) معیارهای بلوغ

٪ از طریق آبی سبز/قناری (هدف> 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 بسازید. تحویل جدا از ورود، نگه داشتن بازگشت سریع و نظم و انضباط مهاجرت - و انتشار قابل پیش بینی، امن و سریع است.