Blue-green — productionning ikki alohida, imkon qadar bir xil muhitini saqlab, yangi versionni bo‘sh muhitga deploy qilish va tekshirgandan keyin trafficni unga almashtirish strategiyasi. Muhitlardan biri blue, ikkinchisi green deb shartli nomlanadi.
Bir muhit active production trafficni qabul qiladi, ikkinchisi yangi release uchun tayyorlanadi.
Ishlash tartibi
Agar blue active bo‘lsa:
- yangi version greenga deploy qilinadi;
- migration va konfiguratsiya tayyorlanadi;
- smoke va acceptance test bajariladi;
- traffic blue’dan greenga o‘tkaziladi;
- metriclar kuzatiladi;
- blue rollback uchun vaqtincha saqlanadi.
Keyingi release’da rollar almashishi mumkin.
Traffic switch
Almashtirish:
orqali bajariladi.
Load balancer switch odatda DNSdan tezroq va nazoratli.
DNS cache sabab o‘zgarish barcha clientga darhol yetmasligi mumkin.
Zero-downtime
Yangi environment traffic olishdan oldin to‘liq ishga tushiriladi.
Shuning uchun deploy paytida service to‘xtashi shart emas.
Switch vaqtida mavjud connection va in-flight requestlar ehtiyotkor tugatiladi.
Connection draining ishlatilishi mumkin.
Smoke test
Green hali public traffic olmayotganda maxsus endpoint yoki internal host orqali tekshiriladi.
Testlar:
Faqat process running bo‘lishi application tayyorligini bildirmaydi.
Rollback
Yangi muhitda muammo bo‘lsa traffic eski blue muhitga qaytariladi.
Bu code rollbackni tezlashtiradi.
Biroq green database’da backward-incompatible o‘zgarish qilgan bo‘lsa blue qayta ishlamasligi mumkin.
Rollback strategiyasi data bilan birga rejalashtiriladi.
Database
Ko‘pincha ikki muhit bitta production database’dan foydalanadi.
Schema ikki versionga ham mos bo‘lishi kerak.
Bosqichlar:
- expand — yangi schema qo‘shish;
- migrate — data va code o‘tishi;
- contract — eski schema olib tashlash.
Contract faqat rollback oynasi tugagandan keyin bajariladi.
Alohida database
Har muhit o‘z database’iga ega bo‘lsa switch oldidan data synchronization muammosi paydo bo‘ladi.
Write traffic active muhitda davom etadi.
Replication, dual-write yoki qisqa freeze kerak bo‘lishi mumkin.
Bu architecture murakkab va conflict xavfiga ega.
Session
User session in-memory saqlansa switchdan keyin login yo‘qolishi mumkin.
Session shared store’da yoki client tokenida saqlanadi.
Cookie key va encryption secret ikki muhitda compatible bo‘ladi.
In-flight websocket connectionlar alohida boshqariladi.
Background job
Blue va green bir vaqtda ishga tushganda ikkala muhit bir xil cron yoki queue jobni bajarib yuborishi mumkin.
Scheduler faqat active environmentda yoqiladi yoki distributed lock ishlatiladi.
Worker versionlari event formatiga mos bo‘lishi kerak.
Cache
Yangi version cache key formatini o‘zgartirsa eski muhit bilan collision bo‘lishi mumkin.
Versioned key yoki cache namespace ishlatiladi.
Green warm-up uchun cache oldindan to‘ldirilishi mumkin.
Old cache rollbackda foydali bo‘lishi mumkin.
Configuration
Ikki environment infrastructure jihatdan bir xil bo‘lishi kerak.
Config drift:
- boshqa environment variable;
- boshqa certificate;
- dependency version;
- network rule;
- autoscaling;
- secret
release paytida yashirin xato yaratadi.
Infrastructure as Code driftni kamaytiradi.
Xarajat
Ikki to‘liq production environment bir vaqtning o‘zida resurs talab qiladi.
Compute, database replica va network xarajati oshadi.
Serverless yoki container platformada bo‘sh muhit qisqa vaqt saqlanishi mumkin.
Katta stateful tizimda qimmatroq.
Blue-green va rolling
Rolling deployment instance’larni navbat bilan yangi versionga almashtiradi.
Bir muddat ikki version bir poolda ishlaydi.
Blue-green esa ikki alohida environment orasida switch qiladi.
Rolling kam resurs, blue-green sodda rollback berishi mumkin.
Blue-green va canary
Canary yangi versionga oz traffic beradi va bosqichma-bosqich oshiradi.
Blue-green odatda katta yoki to‘liq traffic switch qiladi.
Canary riskni statistik kuzatadi.
Blue-green oldindan test va tez rollbackga urg‘u beradi.
Release validation
Green environmentda productionga o‘xshash test bajariladi.
Ammo real traffic, scale va user diversity hali yo‘q.
Switchdan keyin monitoring shart.
Synthetic test production behaviorini to‘liq kafolatlamaydi.
DNS usuli
Blue va green alohida IP yoki hostnamega ega bo‘lishi mumkin.
DNS record active muhitga o‘zgartiriladi.
TTL past bo‘lsa tezroq, ammo recursive resolver eski recordni uzoqroq saqlashi mumkin.
Rollback ham cache sabab kechikadi.
Load balancer usuli
Backend pool yoki target group almashtiriladi.
Health check tayyor instance’larni aniqlaydi.
Traffic switch atomic yoki weighted bo‘lishi mumkin.
Bu canary va blue-green orasidagi hybrid rolloutga imkon beradi.
Monitoring
Switchdan oldin va keyin:
- error;
- latency;
- saturation;
- business transaction;
- log;
- trace;
- dependency health
solishtiriladi.
Version va environment label barcha telemetry’da bo‘ladi.
Eski muhitni o‘chirish
Blue darhol o‘chirilmasa rollback oynasi saqlanadi.
Ammo juda uzoq saqlash security patch va drift muammosi yaratadi.
Rollback muddati tugagach eski environment yo‘q qilinadi yoki keyingi release uchun qayta tayyorlanadi.
Immutable artifact
Blue va green bir xil build artifactdan, faqat konfiguratsiya farqi bilan yaratilishi kerak. Greenda test qilingan image’ni qayta build qilib productionga chiqarish supply-chain va reproducibility muammosi yaratadi.
Secret rotation
Ikki muhit bir vaqtda ishlaganda eski va yangi credential overlap davriga ega bo‘lishi mumkin. Secret birdan bekor qilinsa rollback qilinadigan blue ishlamay qoladi. Rotation release oynasi bilan muvofiqlashtiriladi.
Bog‘liq tushunchalar
Blue-green deployment, Zero-downtime deployment, Traffic switch, Rollback, Canary deployment, Rolling deployment, Load balancer, Database migration, Progressive delivery, Release strategy