Zero-Downtime Blue-Green Deployments: Gizli İpuçları ve Uygulama Stratejileri
Merhaba sunucu yöneticileri!
Şeffaf, hızlı ve güvenilir güncellemeler her zaman büyük takdir toplar. Peki, **çok yüksek trafikli e‑ticaret siteleri için sıfır kesinti** ile dağıtım nasıl başarılır? Bu yazıda, pratik örnekler, gizli ipuçları ve yaygın hataları ele alarak *Blue‑Green Deployment* tekniğini 5 adımda öğretiyorum.
---
## 1. Altyapıyı Prepare‑For‑Production
> **Neden?** Her iki ortamınız (Blue & Green) aynı kaynaklara sahip olmalı; aksi halde, Blue’da test ederken Green’de farklı bir sürüm çalışabilir.
### 1.1. Temiz Çevre Deji
- **Kıyaslayabilirlik**: Her iki ortamın CPU, bellek, disk I/O ve ağ katmanları (Nginx, HAProxy) aynıdır.
- **Versioning**: Konfigürasyon dosyaları (docker-compose, helm chart) *farklı branch* üzerinde tutulur.
- **Canary Enabled**: `--configmap` ve `--set` parametreleri ile aynı anda farklı sürümler çalıştırılabilir.
## 2. Güncellemeleri Sıralı Yayınla
> **Neden?** Hızlı rollback ve düşük risk.
```bash
# 1. Yeni sürümü Green ortamına deploy et
helm upgrade --install myapp-dev -f values-dev.yaml ./chart
# 2. Green’i test et (k8s readiness probe = 2sec)
kubectl rollout status deployment/myapp-dev
```
- **Readiness** ve **Liveness** probe'ları farkındalık yaratır, eksik bir pod ile Green çevre kapanmaz.
## 3. Trafiği Yönlendir
> **Neden?** Yavaş geçiş ile kullanıcı deneyimi bozulmaz.
- **Horizontal Pod Autoscaler (HPA)**: Trazhı nispeten eşit dağıtmak için 50% oranında sadece Green pod'larını artır.
- **Istio VirtualService**: 95% trafik Green’de, 5% Blue’da kalır.
```yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: myapp
spec:
hosts:
- "*"
http:
- route:
- destination:
host: myapp-green
subset: v1
weight: 95
- destination:
host: myapp-blue
subset: v1
weight: 5
```
## 4. Veri Senkronizasyonu
> **Neden?** Blue’da çalışan eski versiyon ile Green’deki veriyi senkronize etmek gerekir.
- **Database Replication**: Yanıt süresiz replika planı var. Örneğin PostgreSQL için `pglogical` uzantısı.
- **Message Queue**: Redis Streams ile mesajı aşımlama.
- **Event‑Sourcing**: Event store’un bir konsolide bakımı.
## 5. Final Switch & Cleanup
> **Neden?** Adım adım geçiş ve olduğunda temizlik.
```bash
# 1. Trafiği temizle
kubectl label deployment myapp-dev app=green
# 2. Blue ortamını sil
helm delete myapp-prod
# 3. Green’i prod olarak etiketle
kubectl label deployment myapp-dev app=prod
```
- **Health‑Check**: Son checkout ile 48 saat boyunca canlı izleme.
- **Rollback**: Hata oluşursa `helm rollback myapp-prod N` ile eski sürüme dön.
---
### Gizli İpucu: Kendinize ‘Fail‑Safe’ Otomasyonu Koyun!
> **Bir test yolunu** (autotune döngüsü) takiben, `k8s` health‑checks'ları 99.9% üstünde izlenir. Olay döngüsünde bir *bronze* seviyesi kritik hata, otomatik olarak Green ortamından “sıkıntı” seviyesi icin Gray ortamına (canary) geçer.
### Kapsamlı Bakış
- **Monitoring**: Grafana + Prometheus + Loki combo’yu kullanın.
- **Alerting**: %0.1% oranında yanıt süresi artışı bir “warming” alarmı üretir.
- **Cost Savvy**: Blue ortamını sadece test fazında dönüştürün, sonra delete edin.
---
> **Sonuç:** 0 kesinti aracı, hızlı dönüşüm ve risk azaltımı sağlıyor. Yüksek trafik sitelerinde, hedef 99.999% uptime olduğunda bu tekniği yalnızca Google EE, Shopify toplulukları değil, kendi üretim ortamınızda da test edin.
Soru ve deneyimlerinizi aşağıda paylaşın – birlikte daha da ekosistemimize katkıda bulunalım!
