Yazılımın serbest bırakılması, eskiden bir bakım penceresi ve çapraz parmaklar anlamına geliyordu. Modern ekipler, yayınları rutin hale getiren stratejiler kullanır ve mavi-yeşil ve kanarya konuşlandırması seçimi karşılaşacağınız ilk tercihlerden biridir. Her ikisi de riski azaltır, ancak bunu zıt şekillerde yaparlar: Biri tam bir değişim hazırlarken diğeri gerçek kullanıcılarla azar azar test eder.

Bu kılavuz her birinin nasıl çalıştığını ve pratikte maliyetinin ne kadar olduğunu açıklamaktadır. Küçük kullanıcı yönlendirme ve geri alma örneklerini Python 3.13’te çalıştırdık ve çıktı bu çalıştırmadan geliyor. Kubernetes örnekleri açıklayıcıdır ve bunları biz çalıştırmadık. Yüzdeleri ve eşikleri uyarlamak için başlangıç ​​örnekleri olarak değerlendirin.

Kısa cevap

Mavi-yeşil dağıtım ile iki özdeş üretim ortamını çalıştırırsınız. Biri, siz yeni sürümü dağıtırken ve test ederken kullanıcılara hizmet verir, diğerinde ise tüm trafiği tek hareketle değiştirirsiniz.

Canary konuşlandırmasıyla yeni sürüm, eski sürümün yanında çalışır. Gerçek trafiğin küçük bir yüzdesini ona gönderir, sonuçları karşılaştırır ve herkese hizmet edene kadar payı adım adım artırırsınız. Adını, madencilerin bir zamanlar tehlikenin erken uyarısı olarak kullandıkları kanaryalardan alıyor.

Mavi-yeşil vs kanarya yan yana

Mavi-yeşil dağıtım nasıl çalışır?

1. Mavi yayındadır ve tüm trafiğe hizmet eder.
2. Yeni sürümü, hiçbir kullanıcı trafiği almayan yeşil‘e dağıtın.
3. Gerçek üretim ortamında, duman testlerini ve dahili kullanıcıları kullanarak yeşili kapsamlı bir şekilde test edin.
4. Trafiği yeşile göndermek için yönlendiriciyi, yük dengeleyiciyi veya DNS’yi değiştirin.
5. Mavi hâlâ çalışır durumda ve hazır durumdayken yakından izleyin.
6. Bir sorun varsa geri dönün. Her şey yolundaysa, mavi bir sonraki boş ortam olur.

Kubernetes’te, bir Hizmetin seçicisini değiştirerek trafiğin farklı etiketli Kapsüllere taşınmasını sağlayarak geçiş yapabilirsiniz:

apiVersion: v1
kind: Service
metadata:
  name: shop
spec:
  selector:
    app: shop
    version: green   # was: blue
  ports:
    - port: 80
      targetPort: 8000

Güçlü Yönler: Kavramsal olarak basittir; üretim kurulumunu kullanıcılar görmeden önce tam olarak test edebilirsiniz ve geri alma neredeyse anında gerçekleşir. Zayıf yönler: Yinelenen altyapı pahalı olabilir, testlerinizden kaçan bir hata aynı anda herkese ulaşır ve geçiş sırasında açık oturumlar ve uçuş sırasındaki çalışmalara dikkat edilmesi gerekir. Anahtar için DNS kullanıyorsanız önbelleğe alınan kayıtlar bunu geciktirebilir. Kavramlarda yeni misiniz? Yeni başlayanlar için Kubernetes eğitimimize bakın.

Canary dağıtımı nasıl çalışır?

1. Yeni sürümü kararlı sürümle birlikte dağıtın.
2. Trafiğin küçük bir kısmını, örneğin %5’ini kanaryaya yönlendirin.
3. Hata oranlarını, gecikmeyi ve iş ölçümlerini kararlı sürümle karşılaştırın.
4. Sağlıklıysa %25’e, sonra %50’ye, sonra %100’e artırın.
5. Herhangi bir sorun olursa tüm trafiği kararlı sürüme geri gönderin.

Pek çok takım önce iç kadroyla, ardından düşük riskli bir bölgeyle ve ancak o zaman daha geniş halkla bir kanarya başlatır.

Güçlü Yönler: Kötü bir sürüm yalnızca küçük bir grubu etkiler ve gerçek trafikten hiçbir test ortamının tam olarak yeniden oluşturamayacağını öğrenirsiniz. Zayıf Yönler: Yüzdeye dayalı yönlendirme ve sürüm başına metriklere ihtiyacınız var, kullanıma sunma daha uzun sürüyor ve iki sürüm bir süre birlikte çalışıyor. Küçük bir kanarya, özellikle trafiğin az olduğu zamanlarda anlamlı bir sinyal veremeyecek kadar sessiz olabilir.

Kararlı kullanıcı yönlendirme

Her istekte rastgele bir sürüm seçmek, eski ile yeni arasında geçiş yapabilecekleri için kullanıcılara kafa karıştırıcı bir deneyim yaşatır. Yaygın bir çözüm, sabit bir kullanıcı kimliğini bir gruba karma hale getirmektir, böylece her kullanıcı her zaman aynı yanıtı alır:

import hashlib

def bucket(user_id):
    digest = hashlib.sha256(user_id.encode()).hexdigest()
    return int(digest, 16) % 100

def version_for(user_id, canary_percent):
    return "v2" if bucket(user_id) < canary_percent else "v1"

users = [f"user-{i}" for i in range(10000)]
for percent in (5, 25, 50, 100):
    share = sum(version_for(u, percent) == "v2" for u in users) / len(users)
    print(percent, round(share * 100, 1))

# 5 5.0
# 25 24.5
# 50 49.9
# 100 100.0

Gerçek pay hedefi yakından takip etti. Bu yöntemin iki kullanışlı özelliği daha var ve çalışmamız her ikisini de doğruladı. Aynı kullanıcı her zaman aynı sürümü aldı. Ve %5’lik gruptaki herkes hâlâ %25’e dahil olduğundan, halihazırda yeni sürüme sahip olan hiç kimse, kullanıma sunma büyüdükçe geri taşınmadı.

Gerçek sistemlerde genellikle bu yönlendirmeyi bir hizmet ağı, yük dengeleyici veya Argo Rollouts veya Flagger gibi bir araç yönetir, dolayısıyla bunu kendiniz yazmanıza gerek yoktur. Ne yaptıklarını anlamak yine de faydalıdır.

Kararın otomatikleştirilmesi

Bir kanarya yalnızca birisi gerçekten versiyonları karşılaştırıyorsa işe yarar. Otomatik kontroller, bir kişinin grafikleri izlemesinden daha güvenilirdir. Kanaryanın hata oranını kararlı sürümünkiyle karşılaştıran temel fikir şu:

def should_rollback(canary_errors, canary_total, base_errors, base_total,
                    tolerance=1.5, min_requests=500):
    if canary_total < min_requests:
        return False   # not enough data to decide
    return (canary_errors / canary_total) > (base_errors / base_total) * tolerance

should_rollback(3, 100, 10, 5000)        # False: too few requests
should_rollback(30, 1000, 100, 10000)    # True:  3% against 1%
should_rollback(12, 1000, 100, 10000)    # False: 1.2% is within tolerance

İlk duruma dikkat edin. Hata oranı yüksek görünüyor, ancak yalnızca 100 istekle henüz yeterli kanıt yok. Gerçek araçlar daha dikkatli istatistikler uygular ve birkaç sinyali birlikte inceler:

Veritabanı sorunu

Uygulama kodu saniyeler içinde değiştirilebilir, ancak veriler değiştirilemez. Her iki strateji de genellikle tek bir veritabanını paylaşır; bu nedenle, kullanıma sunma sırasında ve geri alma sonrasında eski ve yeni sürümlerin her ikisinin de aynı şemayla çalışması gerekir.

Standart cevap, genişlet ve daralt modelidir. Diyelim ki name‘yi full_name olarak yeniden adlandırmak istiyorsunuz:

1. Genişlet: yeni sütunu ekleyin. Eski kod etkilenmez.
2. Geçiş: her iki sütuna da yazan ve eski satırları dolduran kodu yayınlayın.
3. Geçiş: yeni sütundan okunan kodu yayınlayın.
4. Sözleşme: Hiçbir şey eski sütunu kullanmadığında, daha sonraki bir sürümde onu kaldırın.

Bu birkaç sürüm alır, ancak her adım güvenli bir şekilde geri alınabilir. RENAME COLUMN‘i tek seferde çalıştırmak, hangi sürümün diğer adı beklediğini bozar. Kilit tutabilecekleri için uzun süren şema değişikliklerine de dikkat edin. Bununla ilgili daha fazla bilgi için SQL işlemleri hakkında bilgi edinin.

Yuvarlanma ve diğer stratejiler

Kubernetes Dağıtımı, varsayılan olarak birçok hizmete uygun olan sürekli bir güncelleme yapar. Sürekli güncelleme de kademeli olarak değişir, ancak payı örnek sayısına bağlıdır ve tek başına sonuçları analiz etmez veya kötü ölçümleri duraklatmaz.

Özellik bayrakları ne olacak?

Dağıtım, kodu sunuculara yerleştirir ve sürüm, bir özelliği kullanıcıların kullanımına sunar. Özellik bayrakları, herhangi bir şey dağıtmadan seçilen kullanıcılar için bir özelliği açmanıza izin vererek bunları ayrı tutar. Her iki stratejiyle de çok iyi çalışıyorlar: bayrak kapalıyken konuşlandırın, ardından yavaş yavaş etkinleştirin. Bir bayrak sizi başlangıçta çöken bir sürümden koruyamayacağı için bu stratejilerin yerini almazlar. Teknik borç olarak biriken eski bayrakları kaldırmayı unutmayın.

Nasıl seçilir

Ayrıca birleştirilebilirler. Bazı ekipler yeşil bir ortam hazırlıyor ve daha sonra trafiği yavaş yavaş bu alana kaydırarak temiz bir ortam ve sınırlı bir patlama yarıçapı elde ediyor. Neyi seçerseniz seçin, GitHub Eylemleri kılavuzumuzda açıklandığı gibi, bunu CI/CD ardışık düzeniniz aracılığıyla otomatikleştirin.

Yaygın hatalar

• Önemli şema değişiklikleri yapmak. Eski kod verileri okuyamazsa geri almanın bir faydası olmaz.
• Geri alma kriterinin olmaması. “Kötü”nün ne anlama geldiğine bir olay sırasında değil, yayın başlamadan önce karar verin.
• Ortamların sürüklenmesine izin vermek. Yeşil, maviden farklıysa testleriniz daha az kanıtlıyor. Her ikisini de kod olarak altyapı ile tanımlayın.
• Yalnızca teknik metrikler ölçülüyor. Bir sürüm hatasız olabilir ve yine de ödemeyi bozabilir.
• Asla geri alma alıştırması yapmayın. Baskı altında olduğunuzda işe yaraması için prova yapın.
• Arka planda yapılan işleri unutmak. Çalışanların ve zamanlanmış görevlerin de geçiş sırasında bir plana ihtiyacı vardır.

Son sözler

Mavi-yeşil size temiz ve hızlı bir geçiş sağlar. Kanarya size küçük, ölçülü bir pozlama sağlar. İzlemeniz hâlâ basitse, güncellemeler veya mavi-yeşil güncellemelerle başlayın ve kanaryaları denemeden önce sürüm başına metriklere yatırım yapın. Daha sonra veritabanı da dahil olmak üzere bir sonraki sürümünüzde geri alma provası yapın. Bu tek alıştırma aslında neyin düzeltilmesi gerektiğini ortaya çıkarma eğilimindedir.

Sık sorulan sorular

Öğrenmeye devam et