Azure Spring Apps'te mavi-yeşil dağıtım stratejileri

Not

Temel, Standardve Enterprise planları 17 Mart 2025'te kullanımdan kaldırma dönemine girdi. Daha fazla bilgi için bkz . Azure Spring Apps kullanımdan kaldırma duyurusu.

Standart tüketim ve ayrılmış planı 30 Eylül 2024'te emeklilik dönemine girdi ve Mart 2025 sonuna kadar tamamen kapatılacak. Daha fazla bilgi için, Azure Spring Apps Standart tüketim ve ayrılmış planını Azure Container Apps'e geçirme bölümüne bakın.

Bu makale şunlar için geçerlidir:✅ Temel/Standart ✅ Kurumsal

Bu makalede Azure Spring Apps'teki mavi-yeşil dağıtım desteği açıklanmaktadır.

Azure Spring Apps (Standart plan ve üzeri), her uygulama için yalnızca biri üretim trafiği alan iki dağıtıma izin verir. Bu model genellikle mavi-yeşil dağıtım stratejisi olarak bilinir. Azure Spring Apps'in sürekli teslim (CD) işlem hattı ve sıkı otomatikleştirilmiş testlerle birlikte mavi-yeşil dağıtım desteği, yüksek güvenle çevik uygulama dağıtımlarına olanak tanır.

Alternatif dağıtımlar

Azure Spring Apps ile mavi-yeşil dağıtım uygulamanın en basit yolu iki sabit dağıtım oluşturmak ve her zaman üretim trafiği almayan dağıtıma dağıtmaktır. Azure Pipelines için Azure Spring Apps göreviyle, UseStagingDeployment bayrağını true olarak ayarlayarak bu şekilde dağıtım yapabilirsiniz.

Alternatif dağıtımlar yaklaşımı şu şekilde çalışır:

Uygulamanızın iki dağıtımı olduğunu varsayalım: deployment1 ve deployment2. deployment1 Şu anda üretim dağıtımı olarak ayarlanmıştır ve uygulamanın sürümünü v3 çalıştırıyordur.

Bu, hazırlama dağıtımını yapar deployment2 . Bu nedenle, Sürekli Teslim (CD) işlem hattı çalışmaya hazır olduğunda, uygulamanın v4 sürümü olan bir sonraki versiyonu ara dağıtım ortamına deployment2 dağıtır.

başlatıldıktan sonra v4 üzerinde deployment2, tüm beklentileri karşıladığından emin olmak için v4 üzerinden özel bir test uç noktası aracılığıyla buna karşı otomatik ve manuel testler çalıştırabilirsiniz.

v4'a güvendiğinizde, deployment2'i tüm üretim trafiğini alması için üretim ortamı olarak ayarlayabilirsiniz. v3 geri döndürme gerektiren kritik bir sorunu bulmanız halinde deployment1 çalışmaya devam eder.

Şimdi deployment1 hazırlık dağıtımıdır. Bu nedenle, dağıtım işlem hattının bir sonraki çalışması, deployment1 üzerine dağıtılır.

Artık V5deployment1'nin özel test uç noktasında test edebilirsiniz.

Son olarak, v5 tüm beklentilerinizi karşıladıktan sonra, deployment1'i tekrar üretim dağıtımı olarak ayarlarsınız, böylece v5 tüm üretim trafiğini alır.

Değişen dağıtımlar yaklaşımının dezavantajları

Değişen dağıtımlar yaklaşımı, yeni dağıtımların oluşturulmasını gerektirmediğinden basit ve hızlıdır. Ancak, aşağıdaki bölümlerde açıklandığı gibi çeşitli dezavantajlar sunar.

Kalıcı ön hazırlık dağıtımı

Hazırlama dağıtımı her zaman çalışır durumda kalır ve bu nedenle Azure Spring Apps örneğinin kaynaklarını kullanır. Bu, Azure Spring Apps'te her uygulamanın kaynak gereksinimlerini ikiye katlar.

Onay yarış durumu

Yukarıdaki uygulamada, uygulamanın her yeni sürümünün üretim trafiğini alabilmesi için yayın işlem hattının el ile onay gerektirdiğini varsayalım. Bu durum, hazırlama dağıtımında bir sürüm (v6) manuel onay beklerken, dağıtım işlem hattının yeniden çalıştırılarak, daha yeni bir sürümle (v7) üzerine yazılması riskini doğurur. Ardından, v6 için onay verildiğinde, v6 dağıtan işlem hattı, hazırlık dağıtımını üretim olarak ayarlar. Ancak artık bu dağıtımda, trafiği alacak olan, onaylanmış v6 değil, onaylanmamış v7 dağıtılacaktır.

Önceki tüm sürümler için dağıtım akışı tamamlanana veya durdurulana kadar bir sürüm için dağıtım akışının başlayamayacağından emin olarak yarış durumunu önleyebilirsiniz. Onay yarış koşulunu önlemenin bir diğer yolu da aşağıda açıklanan Adlandırılmış Dağıtımlar yaklaşımını kullanmaktır.

Adlandırılmış dağıtımlar

Adlandırılmış dağıtımlar yaklaşımında, dağıtılan uygulamanın her yeni sürümü için yeni bir dağıtım oluşturulur. Uygulama, kendi hazır dağıtımında test edildikten sonra, bu dağıtım üretim dağıtımı olarak ayarlanır. Önceki sürümü içeren dağıtımın geri alma gerekmeyeceğinden emin olacak kadar uzun süre kalıcı olmasına izin verilebiliyor.

Aşağıdaki çizimde, deployment-v5 dağıtımında v5 sürümü çalıştırılıyor. Dağıtım, özel olarak bu sürüm için oluşturulduğundan dağıtım adı artık sürümü içeriyor. Başlangıçta başka bir dağıtım yok. Şimdi sürümü v6dağıtmak için dağıtım işlem hattı yeni bir dağıtım deployment-v6 oluşturur ve uygulama sürümünü v6 orada dağıtır.

Başka bir sürümün paralel olarak dağıtılması riski yoktur. İlk olarak Azure Spring Apps, iki dağıtım mevcutken üçüncü bir dağıtımın oluşturulmasına izin vermez. İkincisi, ikiden fazla dağıtıma sahip olmak mümkün olsa bile, her dağıtım içerdiği uygulamanın sürümüyle tanımlanır. Bu nedenle, v6 dağıtımını koordine eden işlem hattı, yalnızca deployment-v6'i üretim dağıtımı olarak ayarlamaya çalışır.

Yeni sürüm için oluşturulan dağıtım üretim trafiğini aldıktan sonra, gelecekteki dağıtımlara yer açmak için önceki sürümü içeren dağıtımı kaldırmanız gerekir. Yeni sürümde kritik bir sorun bulursanız önceki sürüme geri dönebilmek için birkaç dakika veya saat ertelemek isteyebilirsiniz.

Adlandırılmış dağıtımlar yaklaşımının ödünleri

Adlandırılmış dağıtımlar yaklaşımının aşağıdaki avantajları vardır:

• Onay yarış koşulunu önler.
• Kullanımda olmadığında geçici dağıtımı silerek kaynak tüketimini azaltır.

Ancak, aşağıdaki bölümde açıklandığı gibi dezavantajları da vardır.

Dağıtım hattındaki hatalar

Dağıtımın başlamasıyla hazırlama dağıtımının silinmesi arasında dağıtım işlem hattını çalıştırmaya yönelik ek girişimler başarısız olur. İşlem hattı yeni bir dağıtım oluşturmaya çalışır ve bu da Azure Spring Apps'te uygulama başına yalnızca iki dağıtıma izin verildiğinden hataya neden olur.

Bu nedenle, dağıtım düzenlemesinin başarısız bir dağıtım işlemini daha sonra yeniden deneme araçlarına veya önceki tüm sürümler için akış tamamlanana kadar her sürüm için dağıtım akışlarının kuyruğa alınmış durumda kalmasını sağlama araçlarına sahip olması gerekir.

Sonraki adımlar

• Azure Spring Apps'e uygulama dağıtımlarını otomatikleştirme