Blue-Green Deployment Nedir?

İki ortam, tek anahtar

Klasik yayında yeni sürüm, çalışan sunucunun üzerine kurulur. Kurulum sırasında servis birkaç saniye ya da dakika yanıt veremez; bir şey ters giderse eski sürüme dönmek için kurulumu tersine işletmek gerekir. Blue-green yaklaşımı bunu, birbirinin aynı iki ortamla çözer. Biri (diyelim mavi) canlı trafiği karşılarken diğeri (yeşil) boşta bekler. Yayın akışı şöyledir:

1. Yeni sürüm boştaki yeşil ortama kurulur; canlı kullanıcılar bundan etkilenmez.
2. Yeşil ortam, üretim yapılandırmasıyla sağlık kontrollerinden ve duman testlerinden (smoke test) geçirilir.
3. Yönlendirme katmanı tüm yeni istekleri yeşile gönderecek şekilde değiştirilir.
4. Mavi ortam bir süre olduğu gibi bekletilir. Sorun çıkarsa trafik tekrar maviye çevrilir; çıkmazsa mavi, bir sonraki yayının hedefi olur.

Renklerin bir anlamı yoktur; önemli olan, rollerin her yayında yer değiştirmesidir. Bu yüzden rollback, yeniden kurulum değil tek bir trafik değişikliğidir.

Trafik hangi katmanda çevrilir?

Geçişin anlık ve geri alınabilir olması, anahtarın nerede durduğuna bağlıdır:

• Yük dengeleyici veya reverse proxy: En yaygın yöntemdir. Hedef grup ya da upstream tanımı değiştirilir, yapılandırma yeniden yüklenir; açık bağlantılar tamamlanırken yeni istekler yeni ortama gider.
• Container orkestrasyonu: Kubernetes'te servis seçicisinin (selector) etiketini değiştirmek, trafiği başka bir pod grubuna yönlendirir.
• DNS: Mümkündür ama en yavaş seçenektir. Kayıtların önbellekte kalma süresi (TTL) nedeniyle bazı istemciler eski adrese bir süre daha gider; geri dönüş de aynı gecikmeye tabidir.

# Nginx: canlı upstream yeşil ortamı gösteriyor
upstream app_live {
    server 10.0.0.12:3000;    # yeşil (yeni sürüm)
    # server 10.0.0.11:3000;  # mavi (önceki sürüm, beklemede)
}

# Değişikliği doğrulayıp kesintisiz yeniden yükle
nginx -t && nginx -s reload

En zor kısım: paylaşılan durum

Uygulama sunucuları ikiye katlanabilir, ama veritabanı genellikle tektir. Geçiş anında ve sonrasındaki geri dönüş penceresinde, mavi ve yeşil aynı veritabanına bağlıdır. Dolayısıyla şema iki sürümle de uyumlu olmalıdır: kolon silme veya yeniden adlandırma gibi kırıcı migrasyonlar ayrı yayınlara bölünür. Aynı dikkat başka paylaşılan durumlar için de geçerlidir:

• Oturumlar: Oturum bilgisi sunucu belleğinde tutuluyorsa, geçişte kullanıcılar oturumdan düşer. Oturumları ortak bir depoda (ör. Redis) veya imzalı çerezde tutmak bu sorunu ortadan kaldırır.
• Arka plan işleri: Zamanlanmış görevler ve kuyruk tüketicileri iki ortamda birden çalışırsa aynı iş iki kez yapılabilir. Hangi ortamın bu işleri yürüttüğü açıkça belirlenmelidir.
• Uzun bağlantılar: WebSocket veya dosya yükleme gibi süren bağlantılar için eski ortamın bağlantıları boşaltmasına (drain) zaman tanınmalıdır.

Bedeli ve sınırları

Blue-green, en azından yayın süresince iki tam üretim kapasitesi gerektirir. Bulut ortamında boştaki ortam geçişten sonra küçültülerek maliyet azaltılabilir, ama geri dönüş penceresi boyunca ayakta kalması gerekir. Bir diğer sınır, geçişin “ya hep ya hiç” olmasıdır: yeşil ortamdaki bir hata, anahtar çevrildiği anda tüm kullanıcılara ulaşır. Bu riski kademeli olarak almak isteyen ekipler trafiği yüzdelerle bölen canary deployment yöntemini kullanır; iki yöntem birlikte de uygulanabilir.

Boştaki ortam, yayın öncesi son kontrol için de değerlidir. Ama bir staging ortamının yerini tutmaz: canlı veritabanına bağlı olduğu için yıkıcı testler orada yapılamaz.