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

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 desen genellikle mavi-yeşil dağıtım 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, bayrağını trueolarak ayarlayarak UseStagingDeployment bu şekilde dağıtabilirsiniz.

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 sonraki sürümü olan sürümünü v4hazırlama dağıtımına deployment2dağıtır.

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

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

Şimdi, deployment1 hazırlama dağıtımıdır. Bu nedenle dağıtım işlem hattının sonraki çalıştırması üzerine deployment1dağıtılır.

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

Son olarak, tüm beklentilerinizi karşıladıktan sonrav5, tüm üretim trafiğini almak için v5 bir kez daha üretim dağıtımı olarak ayarlarsınızdeployment1.

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ı hazırlama 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, hazırlama dağıtımında bir sürüm (v6) el ile onay beklerken dağıtım işlem hattının yeniden çalıştırılması ve daha yeni bir sürümle (v7) üzerine yazılmasının riskini oluşturur. Ardından, için v6 onay verildiğinde, dağıtılan v6 işlem hattı hazırlama dağıtımını üretim olarak ayarlar. Ancak artık bu dağıtımda dağıtılan ve trafiği alan onaylanmamış olan onaylanmamış , onaylanan v7v6değil olacaktı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, sürümü v5 dağıtımında deployment-v5ç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 dağıtım yoktur. Ş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, dağıtımını v6 düzenleyen işlem hattı yalnızca üretim dağıtımı olarak ayarlamayı deployment-v6 dener.

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 dezavantajları

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

• Onay yarış durumunu engeller.
• Kullanımda olmadığında hazırlama dağıtımını silerek kaynak tüketimini azaltır.

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

Dağıtım işlem hattı 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