Blue-Green Deployment: Sıfır Kesinti için DevOps Stratejisi

MLOps mühendisi olarak çalışmaya ilk başladığımda, görüntü sınıflandırma için kullanılan bir ML modelini içeren küçük bir uygulamayı yayına almam gerekiyordu. İlk dağıtım sorunsuz geçti. Ancak modeli güncellediğimde kaos başladı. Öncelikle, test ortamımla üretim ortamı arasındaki bazı farklılıklar nedeniyle yeni modelimi barındıran Pod başlatılamadı. Ayrıca, eski modeli barındıran Pod çoktan yeni, başlamayan Pod’umla değiştirilmiş olduğundan müşteriler çalışamaz hale geldi. Bu tam bir kabustu. Sonrasında manuel olarak geri almam ve o modeli kullanan kullanıcılardan özür dilemem gerekti. 

Ancak dersimi aldım ve blue-green dağıtım stratejisine geçtim. Bu DevOps yaklaşımı, kesinti olmadan ve gece yarısı geri dönüşleri olmaksızın yeni güncellemeleri sorunsuzca teslim etmeyi sağlıyor. 

Bu rehberde, blue-green dağıtımın pratikte nasıl göründüğünü adım adım anlatacağım. Nasıl kurulur, artıları-eksileri nelerdir, dokümantasyondan öğrenemeyecekleriniz neler? İster ML servisleri, ister API’ler, ister tam yığın uygulamalar inşa edin, bu yaklaşım ekibinize yeni özellikleri güvenle yayına almak için gereken güvenlik ağını sunabilir.

Blue-Green Dağıtımı Anlamak

Blue-green dağıtım ilk duyduğumda bana olduğundan daha karmaşık gelmişti (en azından bana, başta zor görünmüştü). 

Özetle, kullanıcıları kesintiye uğratmadan yeni sürümler yayınlamak için akıllıca bir yöntemdir. Bunu, iki özdeş üretim ortamını koruyup trafiklerini aralarında değiştirerek yapar. 

Uygulamanızın hazırlıkta çalışıp üretimde çöktüğü sorunla karşılaştıysanız, bu strateji tam size göre!

Çekirdek mimari ve operasyonel işleyiş

Temel fikir: İki özdeş üretim ortamı tutarsınız. Biri mavi, diğeri ise yeşil olarak adlandırılır.

Mavi ortam, kullanıcıların şu anda etkileşimde bulunduğu ortamdır. Yayınlamak istediğiniz yeni bir sürüm olduğunda onu yeşil ortama dağıtır, test eder ve çalıştığından emin olduğunuzda üretim trafiğini maviden yeşile yönlendirirsiniz.

Bu strateji kesinti olmamasını sağlar; “üzgünüz, güncelleme yapıyoruz” mesajı yok. Kullanıcıların fark etmediği, perde arkasında gizli bir geçiş olur.

Pratikte sihir, yük dengeleyicide gerçekleşir. Dağıtım durumuna göre trafiği her iki ortama da yönlendirecek şekilde yapılandırırsınız. Bu, trafik üzerinde ince ayarlı kontrol sağlar ve geri almayı, trafiği tekrar mavi ortama çevirmek kadar kolay hale getirir. 

Bu strateji, yeni ML modelimde yaşadığım “hazırlıkta çalışıyordu ama...” anını adresler. Yeşil ortam da bir üretim ortamı olduğundan, kullanıcılar hiç kullanmadan önce gerçeği test ediyorsunuz.

Tipik akışın hızlı bir özeti şöyle: 

1. Yeni sürümü yeşile dağıtın.
2. Entegrasyon ve smoke testlerini çalıştırın.
3. Yük dengeleyiciyi kullanarak trafiği değiştirin. 
4. Yeşili anormallikler için izleyin.
5. Her şey yolundaysa maviyi küçültün veya gerekirse geri almak için hazır tutun.

Blue-green dağıtım Aşama 1: Test için yeni uygulama yeşilde, trafik hâlâ maviye yönlendiriliyor (Görsel: yazar).

Blue-green dağıtım Aşama 2: Trafik yeşil ortama yönlendirildi (Görsel: yazar). 

Tarihsel evrim ve sektörel benimseme

Blue‑green yaklaşımı, yaklaşık 2005 civarında ThoughtWorks içinde Daniel Terhorst‑North ve Jez Humble tarafından adlandırıldı ve kullanıldı. Daha sonra Jez Humble ve Dave Farley’nin 2010 tarihli Continuous Delivery kitabında belgelenip popülerleşti.

O zamandan beri, girişimlerden Netflix gibi günümüzün bulut-yerel devlerine ve günde birden fazla dağıtımı sorunsuz yapan herkese kadar yaygınlaştı.

Bulut platformları bu dönüşümü hızlandırdı. Kodla yönetilen altyapı, otomatik ölçekleme grupları ve Kubernetes gibi konteyner orkestrasyon araçlarıyla, kopya ortamları kurmak ve sürdürmek kolaylaştı.

Blue-green dağıtımlar, canary yayınlar ve özellik bayrakları gibi diğer dağıtım modellerine de ilham verdi. Blue-green’i anlarsanız, diğerlerini anlamak için de bir temel edinirsiniz.

DevOps’a yeni misiniz? DevOps Concepts kursuyla başlayın. İleri düzey iş akışlarına dalmadan önce çekirdek stratejileri anlamanıza yardımcı olan açık ve pratik bir temel sunar.

Blue-Green Dağıtımın Temel Faydaları

Açık konuşmak gerekirse, blue-green dağıtımları ilk duyduğumda iki üretim ortamını sürdürmenin hiç mantıklı olmadığını düşündüm. Ancak yeni ML modellerini ne kadar kolay yayına alabildiğimi ve kullanıcılardan gelen şikâyet ve eskalasyonların azaldığını gördüğümde, emeğe değdiğini anladım.

Aşağıdaki bölümlerde, blue-green dağıtımın faydalarını öne çıkaracağım.

Sıfıra yakın kesinti

Bu en bariz fayda; kimse kesinti istemez.

Blue-green ile hizmet kalitesinin düşmesini beklemeden trafiği eski ortamdan yenisine anında çevirebilirsiniz. Kullanıcılar değişimi fark etmez ve zaten olması gereken de budur.

Kullanıcıya dönük API’ler, panolar veya birkaç dakikalık kesintiyi bile göze alamayacak ML boru hatları çalıştırıyorsanız oyunun kurallarını değiştirir.

Kolay geri alma

Yeni bir sürüm yayınladığınızı ve birkaç dakika sonra çok sayıda dahili sunucu hatası verdiğini fark ettiğinizi düşünün. Blue-green dağıtımda, yük dengeleyiciyi tekrar mavi ortama çevirir ve hatayı acele etmeden düzeltebilirsiniz.

Bu güvenlik seviyesi, ekiplerin sık sık yayın yapma konusunda daha özgüvenli olmasını sağlar. “Çalışan sisteme dokunma” devri biter.

Üretimde güvenli test

Kullanıcıları riske atmadan üretimde test yapabilirsiniz. Yeşil ortamın güzelliği budur. Gerçek trafik uygulamaya ulaşmadan önce yük testleri, entegrasyon kontrolleri çalıştırabilir, hatta kullanıcı davranışını simüle edebilirsiniz.

Geleneksel hazırlık ortamlarından farklı olarak, aynı altyapı, yapılandırma ve diğer her şey üzerinde test yaparsınız.

Bu da testlerin gerçeği yansıtma olasılığını ciddi şekilde artırır.

A/B Testi ve kademeli yayınları destekleme

İki özdeş üretim ortamınız çalışır durumdayken daha fazlasını da yapabilirsiniz. Trafiğin %90’ını mavi sürüme, %10’unu yeşil sürüme yönlendirebilirsiniz. 

Ayrıca, hangi özelliklerin ne zaman devreye alınacağını kontrol etmek için feature flag’leri entegre edebilirsiniz; burada blue-green dağıtım, temel dağıtım zemini olarak iyi bir destek sağlar. 

Aşamalı teslimata daha derin dalmak isterseniz, Veri Mühendisliğinde CI/CD yazısına göz atın. A/B testini ve kademeli yayınları destekleyen boru hatlarının nasıl kurulacağını açıklar.

Daha iyi kullanıcı deneyimi ve iş sürekliliği

Blue-green dağıtım şunlara yardımcı olur:

• Kullanıcılara daha az hata yansıtmak.
• Sorun çıktığında mühendislik yanıt sürelerini artırmak.
• Yedekleri geri yüklemeyi basitleştirmek

Her gün insanların güvendiği kritik makine öğrenimi servislerini veya iç veri araçlarını dağıtıyorsanız, bunun önemi büyüktür.

Blue-Green Dağıtım için Planlama

Blue-green dağıtımı uygulamadan önce, öncelikle daha derinlemesine anlamak önemlidir.

Mimari, maliyet hususları ve kurumsal hazırlık açısından neler gerekeceğini parçalara ayıralım.

Altyapı gereksinimleri

İki özdeş üretim ortamına ihtiyacınız var. Bu da iki kat kurulum ve iki kat bakım demektir.

Ancak maliyetler konusunda paniğe kapılmadan önce, bunun her zaman iki kat maliyet anlamına gelmediğini unutmayın. Bulut platformları veya Kubernetes ile, yeşil ortam için kaynakları yalnızca gerektiğinde başlatıp sonrasında kapatabilirsiniz.

İki ortamı kurarken yardımcı olabilecekler şunlardır:

• Kodla yönetilen altyapı (örn. Terraform) ile ortamları hızla kopyalamak.
• Yapılandırma yönetimi ile yapılandırma sapmasından kaynaklanan sorunları önlemek.
• Kubernetes içinde mavi ve yeşil için farklı ad alanları (namespace) veya dağıtım nesneleri kullanmak.

Ayrıca, kurum içi kurulumlarda işlerin daha karmaşıklaştığını unutmayın; şu hususları sağlamanız gerekir:

• Yük dengeleyiciler trafiği anında değiştirecek kadar yapılandırılabilir olmalı.
• Ortamları hızlıca sağlanabilmelisiniz (belki sanallaştırma veya konteynerler aracılığıyla).
• Harici bağımlılıklar (örn. veritabanları, API’ler) senkronize ve izole olmalı.

Platformunuz için en kolay olanı belirlemek adına AWS, Azure ve GCP Hizmet Karşılaştırmasını referans alabilirsiniz.

Maliyet-fayda analizi

Şüpheciler her zaman iki üretim ortamı sürdürmenin artan maliyetlerini dile getirir. Evet, iki ortamı çalıştırmak ücretsiz değil. Ancak ikinci ortamın artan maliyeti ile işletmeniz için kesinti maliyeti arasında bir denge vardır. 

Kendinize şunları sorun:

• Başarısız bir dağıtımın ortalama etkisi (zaman veya para olarak) nedir?
• Hata ayıklamak, geri almak ve kesintiyi açıklamak kaç saat alıyor?
• Kaç kez “umarım kırılmaz” diyerek baskı altında yayın yapıyorsunuz?

Blue-green’in en büyük satış noktası budur: Daha az kesinti, daha hızlı iterasyon ve daha az mühendislik baskısı ile tükenmişlik. 

Maliyetleri optimize etme ipuçları:

• Yeşil ortamı test yüküne göre boyutlandırmak için otomatik ölçeklendirme kullanın.
• Yeşil ortam için spot instance’lar veya geçici VM’ler kullanın.
• Yeşil sürümü ayrı bir Kubernetes ad alanında çalıştırın ve geçişten sonra sıfıra ölçekleyin.

İyi yapılandırılmış bir CI/CD boru hattı bu ölçeklendirmeyi otomatik olarak da yönetebilir.

Önkoşullar ve organizasyonel hazırlık

Bu kısım genellikle gözden kaçar ama oldukça önemlidir.

Altyapı ve araçlar için bütçeniz olsa bile, ekibinizin kültürü ve sistemleri hazır değilse blue-green dağıtım çalışmayacaktır.

Şunlara ihtiyacınız olacak: 

• CI/CD iş akışları: Yeşile bağımsız olarak dağıtım ve test yapabilen boru hatları.
• İzleme ve gözlemlenebilirlik: Trafiği maviden yeşile değiştirmeden önce metrikleri kontrol etmeniz gerekir.
• Net geri alma stratejisi: İdeal olarak otomatik, kesinlikle pratiği yapılmış.
• Fonksiyonlar arası uyum: Geliştirme, Operasyon, QA ve Ürün ekiplerinin sürecin nasıl işlediğini anlaması gerekir.

Ekibinizin durumundan emin değilseniz, Makine Öğrenimi için CI/CD kursunu düşünün. Olgun bir dağıtım kurulumunun nasıl göründüğünü ve buna nasıl ulaşılacağını kapsamlı şekilde açıklar.

Teknik Uygulama

Şimdiye kadar, neden blue-green dağıtımları kullanmanız gerektiğini ele aldık. Bu bölümde nasıl uygulayacağınızı göstereceğim. 

Tipik bir blue-green dağıtım yaşam döngüsünü, özellikle veritabanlarını ele alma gibi zorlu kısma odaklanarak parçalayacağım.

Neyi otomatikleştireceğinizi, neyi izleyeceğinizi ve neleri atlamamanız gerektiğini öğreneceksiniz.

Standart dağıtım yaşam döngüsü

İyi uygulanmış bir blue-green dağıtımı belirli bir sırayı takip eder. Pratikte genelde şöyle görünür:

1. Yeşil ortamı sağlama: Bulutta, kurum içinde veya Kubernetes kullanarak mevcut (mavi) ortamınızı yansıtan üretim düzeyinde bir ortam başlatın.
2. Yeni sürümü yeşile dağıtma: CI/CD boru hattınızın kodu burada derleyip dağıtması gerekir; ideal olarak mevcut sürüm adayını etiketleyerek.
3. Otomatik testleri çalıştırma: Buna smoke testleri, entegrasyon kontrolleri ve kullanıcı davranışını simüle eden sağlık yoklamaları dahildir. Yeşilin kullanıcılarınız için hazır olup olmadığını kontrol edersiniz.
4. Günlük ve metrikleri izleme: Panolarınız temiz ve uyarı yoksa hazırsınız. Değilse sorunları düzeltip yeşile yeniden dağıtın.
5. Trafiği yeşile çevirme: Yük dengeleyicinizi tüm trafiği yeşil sunucuya yönlendirecek şekilde yeniden yapılandırın.
6. Maviyi devre dışı bırakma: Yeşilden emin olduğunuzda maviyi kapatın veya bir sonraki sürüme kadar yedek olarak tutun.

Geri alma adımını, yayına alma kadar hızlı yapın ki bir ekip üyesi bir dakikadan kısa sürede dağıtımı geri çevirebilsin.

Veri Mühendisliğinde CI/CD rehberi, bu otomatik aşamaları kurmak için mükemmel bir kaynaktır.

Veritabanı senkronizasyon stratejileri

Bu kısım zordur. Uygulamanız durum bilgisiz olabilir ama veritabanınız değildir. 

Bu kısmı dikkatle ele almazsanız kolay geri alamazsınız ve blue-green dağıtımın tüm anlamı kaybolur.

Bunu şöyle yönetebilirsiniz:

1. Geridönüşümlü uyumluluk için tasarlayın: Geçiş sırasında kullanıcılar birkaç milisaniye de olsa mavi ortama isabet ediyor olabilir. Şemanız bu süre boyunca her iki uygulama sürümüyle de çalışmalıdır. 
1. Alanları hemen silmeyin veya yeniden adlandırmayın.
2. Yeni sütunlar/tablolar ekleyin, varsayılan değerler kullanın.
3. Her iki sürüm de değişikliği destekleyene kadar katı kısıtlamalardan kaçının.
2. Migrasyonlarınızı sürümlendirin: Java tabanlı sistemler için Flyway veya Liquibase, Python + SQLAlchemy için Alembic gibi araçlar kullanın. 
3. Oturum durumunu yönetin: Uygulamanız bellek içi oturum depolama kullanıyorsa ortam değiştirmek kullanıcıların oturumunu kapatabilir veya işlevselliği bozabilir. Bunu önlemek için Redis, Memcached veya paylaşılan bir DB kullanın.
4. Geçiş sonrası veri tutarlılığını doğrulayın: Kritik veriler üzerinde tutarlılığı sağlamak için kontrolleri otomatikleştirin.
1. Kullanıcılar giriş yapabiliyor mu? 
2. Son değişiklikler kaydediliyor mu? 
3. Analitik boru hattı hâlâ doğru şekilde veri alıyor mu?
5. Yavaş sapmaları izleyin: Bazen değişiklikler hata vermez ve çalışıyor gibi görünür, ancak olay işleme gecikmeleri veya bozuk kayıtlar gibi ince sorunlara yol açabilir. Bu tür problemleri mümkün olduğunca erken bulmak için günlükleme ve gözlemlenebilirlik kullanın.

Üretim düzeyinde MLOps’u nasıl kullanacağınızla ilgileniyorsanız, MLOps Deployment and Life Cycling kursunu öneririm.

Diğer Dağıtım Stratejileriyle Karşılaştırmalı Analiz

Blue-green çoğunlukla diğer dağıtım stratejileri için bir temel olarak kullanılır; dağıtım sürecindeki farklı sorunları ele almak için varyasyonlar sunar. 

Mimarinize, yayın sıklığınıza ve karmaşıklık isteğinize bağlı olarak alternatifleri değerlendirin veya bazı yaklaşımları harmanlayın.

En yaygın senaryoyu karşılaştırarak başlayalım: blue-green vs. canary dağıtımlar.

Blue-green vs. canary dağıtımlar

Bu stratejiler sıklıkla karıştırılır, ancak farklı hedefler üzerine kuruludur.

Blue-green, tamamen anahtar çevirme modelidir. Yeşile dağıtır, test eder ve hazır olduğunuzda trafiğin %100’ünü çevirirsiniz.

Canary ise kademeli bir geçiştir. Yeni sürümü eskisinin yanında dağıtır ve küçük bir trafik yüzdesini (örn. %1, sonra %10, ardından %50) yavaş yavaş kaydırırken olası sorunları izlersiniz.

İki strateji arasındaki temel farklar:

Ben şahsen yeni ML modellerini üretime almak için blue-green kullandım, ancak kullanıcı tabanı da sınırlıydı. Modellerim daha büyük kitlelere açık olsaydı, muhtemelen canary yayınları tercih ederdim.

Altyapı ve operasyonel ödünleşimler

Her iki strateji de iyi araçlar gerektirir, ancak karmaşıklıkları farklı alanlardadır.

Blue-green, özdeş ortamlar gerektirir; bu da altyapı maliyetini artırır. Ancak yönlendirme oldukça basittir; trafiği bir ortamdan diğerine çevirmekten ibarettir. 

Canary ise altyapı maliyetleri açısından daha hafiftir; ancak trafiğin kademeli kaydırılmasına imkân verecek daha fazla mantık ister. Sorunları olabildiğince erken yakalamak için daha ayrıntılı gözlemlenebilirlik de gerektirir.

Dikkate almanız gereken diğer faktörler: 

• İzleme: Canary, ayrıntılı metrikler gerektirir (örn. kullanıcı başına veya istek başına gecikme), blue-green ise uygulamanın sağlıklı olup olmadığını bilmekle yetinir. 
• Otomasyon araçları: Argo Rollouts gibi araçlar Kubernetes’te her iki modeli de destekler, ancak canary için daha fazla kurulum gerekir.
• Dağıtım süresi: Blue-green hızlıdır. Canary temkinli ve zaman alıcıdır.

Peki sizin için hangisi doğru?

Ekibiniz CI/CD olgunluğunu yeni artırıyorsa, güven inşa etmek için blue-green en iyi yol olabilir. Aynı zamanda iyi bir başlangıç noktasıdır ve deneyim toplamanıza olanak verir. 

Ancak büyük bir kullanıcı tabanınız varsa veya önemli risk taşıyan değişiklikler (örn. fiyatlandırma mantığı) dağıtıyorsanız, canary iyi bir seçenek olabilir.

Azure odaklı ekipler için, Azure DevOps Eğitimi Azure üzerinde iyi bir CI/CD’nin nasıl uygulanacağını gösterir.

Platforma Özel Uygulamalar

Şimdi teori yeter. Daha teknik olalım. Blue-green dağıtımın, veri ekiplerinin her gün kullandığı Kubernetes, yönetilen bulut servisleri ve otomasyon araçları gibi platformlarda nasıl uygulandığına bakalım.

Her biri farklı özellikler sunar, ancak temel fikir aynıdır. İki özdeş ortam ve bir trafik anahtarı gerekir.

Kubernetes orkestrasyon kalıpları

Blue-green dağıtımı Kubernetes ile uygulamak oldukça basittir; gerekli araçların tümü Kubernetes’in içinde zaten mevcuttur. 

Bunu kurmanın birkaç yolu vardır:

• Ayrı dağıtımlar: my-app-blue ve my-app-greeni ortak etiketler ve servisleri paylaşan iki ayrı dağıtım olarak kurun.
• Revizyonlu tek dağıtım nesnesi: Daha az yaygındır, ancak sürümleri izlemek için açıklamalar (annotation) kullanırsanız mümkündür.
• Ad alanları: Tam izolasyon için maviyi ve yeşili ayrı ad alanlarında çalıştırın.

Buradaki kilit bileşen Kubernetes Service’tir. Etiket seçiciler (label selector) aracılığıyla trafiği mavi veya yeşil pod’lara yönlendiren yük dengeleyici görevi görür.

Diyelim ki şunlara sahipsiniz:

selector:  version: blueAltyapı:

Yeşil sürümü doğruladıktan sonra servis seçicisini version: green olarak güncellersiniz ve trafik anında yeniden yönlendirilir.

Yeni sürümün trafiği almadan önce tamamen hazır olduğundan emin olmak için readinessProbes kullanmanızı öneririm.

Bu süreç Argo Rollouts ve Flagger gibi araçlarla otomatikleştirilebilir; şu işleri üstlenirler:

• Kademeli trafik kaydırma
• Sağlık kontrolleri ve izleme
• Çökmelerde otomatik geri alma

ML odaklı altyapıya daha derin inmek ister misiniz? Fully Automated MLOpsa göz atın.

Bulut-yerel yönetilen servisler

AWS, Azure veya GCP’deyseniz güzel haber: blue-green dağıtım zaten yerleşik; sadece etkinleştirmeniz yeter.

AWS CodeDeploy (Elastic Beanstalk veya EC2 ile):

• Özel bir blue-green dağıtım stratejisi sunar
• Hangi ortamın yeşil olduğunu tanımlarsınız; CodeDeploy trafik kaydırma ve geri almayı yönetir

Azure Container Apps veya Azure App Service:

• Azure, sürümleri “slot” olarak aşamalandırmanıza ve sıfır kesintiyle takas etmenize imkân verir
• Tümüyle otomatik CI/CD için bunu Azure DevOps boru hatlarıyla birleştirin

Google Cloud (Cloud Run veya GKE):

• Cloud Run, revizyonlar arasında kademeli trafik bölmeyi destekler; test ve yayına alma için idealdir
• GKE ile, blue-green mantığını yönetmek için yük dengeleyici kuralları veya Istio kullanın

Her bulut sağlayıcısının kendine özgü kurulumu ve özellikleri vardır, ancak çok az şeyi kendiniz uygulamanız gerektiğinden işinizi kolaylaştırırlar. 

Yönetilen servisleri kullanmak ayrıca, altyapıyı kendinizin işletmemesi avantajını getirir; bulut sağlayıcıları servislerini günceller, sizin tek yapmanız gereken doğru şekilde yapılandırmaktır.

GCP’ye yeni misiniz? Cloud Run: GCP’de Konteynerleştirilmiş Uygulama Dağıtma Rehberina göz atın.

Cloud Foundry ve diğer araçlarla örnek

Cloud Foundry, alttaki altyapının büyük bölümünü soyutlayan, geliştiricilerin kod dağıtmaya odaklanmasına olanak tanıyan açık kaynaklı bir hizmet olarak platformdur (PaaS). Otomasyon, uyumluluk özellikleri ve hızlı dağıtım iş akışları sayesinde özellikle büyük kurumsal yapılarda popülerdir.

İşte resmi CLI kullanılarak Cloud Foundry’de tipik bir blue-green dağıtımın nasıl çalıştığı:

1. Uygulamanızın mavi sürümünü demo-time alt alan adıyla itin:

1. cf create-route example.com --hostname my-appcf push my-appcf map-route my-app example.com --hostname my-appAltyapı:

2. Mavi artık çalışıyor ve yönlendirici tüm trafiği my-app.example.com’a gönderiyor.
2. Yeşil sürümü itin; yeni bir ad ve rota ile:

1. cf create-route example.com --hostname my-app-tempcf push my-app-greencf map-route my-app-green example.com --hostname my-app-tempAltyapı:

2. Uygulamanın iki örneği şimdi ayakta, ancak trafiği gönderebileceğiniz iki rota var (my-app.example.com mavi için ve my-app-temp.example.com yeşil için).
3. Üretim rotasını yeşile eşleyin:

1. bashcf map-route my-app-green example.com -n my-appAltyapı:

2. Bu noktada eski (mavi) ve yeni (yeşil) sürümlerin ikisi de canlıdır, ancak maviyi açıkça kaldırmadıkça trafik her ikisine de yönlendirilir.
4. Yeşil sürümün doğru çalıştığını doğrulayın. Kendi rotası üzerinden test edebilir veya geçiş sonrası gerçek trafiği izleyebilirsiniz.
5. Rotayı maviden kaldırın ve tamamen yeşil dağıtıma geçin:

1. cf unmap-route my-app example.com -n my-appAltyapı:

2. Yönlendirici artık trafiği maviye göndermiyor.
6. Eski uygulamayı silin ve yeşil rotayı kaldırın (opsiyonel ama önerilir):

cf delete my-appcf unmap-route my-app-green example.com --hostname my-app-tempAltyapı:

Bu süreç, kesintiyi en aza indirir ve sürümleri ne zaman ve nasıl değiştireceğiniz üzerinde tam kontrol sağlar.

Bu iş akışını görsel boru hatları, manuel onaylar veya otomatik geri alma ile daha da geliştirmek isterseniz, Octopus Deploy, Codefresh veya Spinnaker sağlam seçeneklerdir. CI/CD boru hatlarıyla sorunsuz entegre olarak ekiplerin karmaşık dağıtım yaşam döngülerini otomatikleştirmesine olanak tanırlar.

En İyi Uygulamalar ve Optimizasyon Stratejileri

Blue-green dağıtım kulağa harika gelir ve çok yardımcı olabilir, ancak maliyeti, riski veya otomasyonu doğru yönetmezseniz hızla karmaşaya dönüşebilir. Aşırı karmaşık kurulumlardan veya beklenmedik köşe durumlarından mustarip ekipler gördüm. 

Bundan kaçınmak ve blue-green stratejinizi başarıya taşımak için neler yapmanız gerektiğine bakalım.

Maliyet yönetimi teknikleri

Ortamları çoğaltmak elbette ek maliyet getirir. 

Ancak aşağıdaki stratejilerle bunları en aza indirebilirsiniz:

• Otomatik ölçekleme: Gerçek iş yüküne uyum sağlamak ve israfı önlemek için yatay pod otomatik ölçekleyicileri veya bulut-yerel otomatik ölçeklemeyi kullanın.
• Spot instance’lar ve preemptible’lar: Sadece test yapıyorsanız (ve olası kesintileri tolere edebiliyorsanız) yeşil ortam için harikadır.
• Geçici sağlama: Yeşil ortamı gerektiğinden uzun süre çalışır halde tutmayın. CI/CD boru hattınızla başlatın ve sonrasında kapatın.
• Konteynerleştirme: Hafif, hızlı ve maliyet-etkindir; özellikle Kubernetes veya Azure Container Apps gibi platformlarda çalışırken.

Otomatik doğrulama çerçeveleri

Yeşil uygulamanızın beklendiği gibi çalıştığından tamamen emin olmadan asla trafiği çevirmemelisiniz. 

Anahtarı çevirmeden önce güven inşa etmek için şu test katmanlarını kullanın:

• Smoke testleri: Temel uç noktalar canlı ve sağlıklı mı?
• Entegrasyon testleri: Temel iş akışları (kimlik doğrulama, veri erişimi vb.) yeşil sürümde çalışıyor mu?
• Uçtan uca testler: Geçici yeşil rota üzerinden gerçek kullanıcı davranışını simüle edin (özellikle Cloud Foundry ve Azure’da yararlıdır).

Bunları CI/CD boru hattınıza entegre edin ki başarılı bir dağıtımdan sonra otomatik çalışsınlar.

Bu akışları kurmayı tazelemek mi istiyorsunuz? Makine Öğrenimi için CI/CD, otomatik doğrulamaların dağıtım yaşam döngünüze nasıl yerleştirileceğini kapsar.

Veritabanı geçiş metodolojileri

Bu kısım zorlu; uygulamanız iki ortamda çalışabilir ama veritabanınız genelde ikisi için de aynıdır. 

Güvenli şekilde geçiş yapmak için şunları yapın:

• Geriye dönük uyumlu şema değişiklikleri: Yeşil sürüm canlıya alındığında mavinin veritabanını hâlâ kullanabileceğini her zaman varsayın.
• Özellik anahtarları: Şemaya bağlı özellikleri yalnızca yeni şema dağıtıldıktan sonra devreye alın.
• Sürümlenmiş migrasyonlar: Değişikliklerin izlenebilir ve geri alınabilir kalması için Flyway, Alembic veya Liquibase gibi araçlar kullanın.
• Oturum/veri tutarlılığı: Oturum durumuna dayanıyorsanız, her iki ortamın da paylaşabileceği harici depolar (örn. Redis) kullanın.

Özellik bayrakları ve aşamalı teslimat

Blue-green’i özellik bayraklarıyla birleştirmek daha da fazla esneklik sağlar.

Bayraklarla şunları yapabilirsiniz:

• Yeşil ortam içinde yeni özellikleri kullanıcıların bir alt kümesine sunmak
• Özellikleri dağıtmak fakat gizli tutmak
• Tüm özellik setini açığa çıkarmadan uç durumları veya performans etkilerini güvenle test etmek

Kod değişikliği gerektirmeden yönetimi basitleştirmek için LaunchDarkly, ConfigCat veya Unleash gibi araçlardan yararlanın.

Sağlam izleme ve gözlemlenebilirlik

İzleme ve gözlemlenebilirlik, trafiği güvenle çevirmek için kritik önemdedir; yeşilin maviye dağıtılmak için güvenli olup olmadığını doğru değerlendirmenizi sağlar.

Şunlara sahip olmalısınız: 

• Sağlık kontrolleri: Kubernetes readinessProbes, Azure revizyon URL’leri vb.
• Günlükleme: Ortam bazında (mavi vs. yeşil) etiketlenmiş, merkezi ve aranabilir günlükler.
• Alarm: Eşikler belirleyin ve hata oranları artarsa bildirim alın.
• Trafik analizi: Mavi ve yeşil arasındaki davranışı karşılaştırın (örn. gecikme, hata oranı, throughput).

Yine de, sağlam izleme ve gözlemlenebilirlik, blue-green kullansanız da kullanmasanız da altyapınızın bir parçası olmalıdır.

Geri alma ve felaket kurtarma planlaması

Zaman zaman işler ters gidecektir. Amaç, bir hatadan kurtulmayı mümkün olduğunca kolay ve hızlı hale getirmektir. 

Bunu şöyle yapın:

• Anında geri alma: Yeşilin stabil olduğunu doğrulayıncaya kadar mavi ortamı her zaman ayakta tutun.
• Otomatik geri alma tetikleyicileri: Kilit metrikler başarısız olursa trafiği geri çevirmek için Argo Rollouts veya Spinnaker gibi araçları kullanın.
• Runbook ve playbook’lar: Ekip için önceden yazılmış adımlar; herkes ne yapacağını bilsin.

Daha fazla pratik DevOps otomasyon ipucu için Azure DevOps Eğitimine göz atın.

Güvenliğin güçlendirilmesi

İki ortamınız olması, iki potansiyel saldırı noktası olması demektir.

Uygun güvenliği sağlamak için bazı öneriler:

• Ortamları izole edin: İzolasyonu sağlamak için ayrı alt ağlar, ad alanları veya bulut kaynak grupları kullanın.
• Gizleri sık döndürün: Özellikle mavi ve yeşil arasında paylaşılan kimlik bilgileri kullanıyorsanız.
• Her iki ortamı da yamalayın: Canlı değil diye yeşilin güvenlik güncellemelerini geride bırakmayın.
• Denetim günlükleri: İzlenebilirlik için dağıtım olaylarını ve ortam geçişlerini yakalayın.

Sonuç

Blue-green dağıtım, yalnızca aşırı mühendislik ürünü süreçlerin kullandığı süslü bir dağıtım stratejisi değildir. Çalışma süresine, hızlı geri bildirime ve sakin gecelere öncelik veren ekipler için pratik ve güvenilir bir stratejidir.

Size şunları sağlar:

• Bir şeyler ters gittiğinde anında geri alma
• Gerçek kullanıcı riski olmadan üretim düzeyinde test
• Cuma günleri bile (şaka değil) daha temiz, daha özgüvenli yayınlar

Peki her durum için mükemmel midir? Bence hayır. Bu yolculuğu destekleyen araçlarla sağlam bir CI/CD kurulumuna sahip olmanız gerekir; aksi halde işler hızla karmaşıklaşabilir.

Ama bu, ondan kaçınmak için bir sebep değildir. Aksine dağıtım pratiklerinizi iyileştirmeniz gerektiğinin bir işaretidir.

Blue-green dağıtımları benimseyerek yayın akışımızı büyük ölçüde iyileştirdik ve sonrasında, Cuma günleri bile yayın yapacak kadar kendimize güven duyduğumuz, son derece sakin yayın günleri yaşadık.

Daha derine inmek isterseniz, DevOps Concepts veya MLOps Deployment and Life Cycling ile başlayın; blue-green’in üzerine kurulduğu temeli oluşturmanıza yardımcı olurlar.

Şimdi gidin ve uygulamanızı güvenle yayınlayın.