Azure App Service Linux’ta Deferred Kudu Recycle ile
Azure App Service for Linux, dağıtım sırasında yapılan yapılandırma değişikliklerinin sürecin ortasında kesintiye yol açmasını azaltmak için Deferred Kudu Recycle adında bir platform iyileştirmesi devreye aldı. Bu değişiklikle uygulama ayarları (app settings) veya bağlantı dizeleri (connection strings) güncellendiğinde Kudu anında yeniden başlatılmıyor; uygun durumlarda bu işlem erteleniyor.
Bu yazıda özelliğin nasıl çalıştığını, hangi ayarların hala anlık yeniden başlatmayı tetiklediğini ve kendi derleme sürecinize özel ayarları nasıl “deployment-critical” olarak işaretleyebileceğinizi kaynaktaki bilgiler çerçevesinde ele alıyoruz.
Sorun: dağıtım sırasında beklenmedik Kudu yeniden başlatmaları
Daha önce, Linux üzerinde çalışan App Service uygulamalarında app settings veya connection strings üzerinde yapılan herhangi bir değişiklik Kudu (SCM) sitesinin anında geri dönüştürülmesine (recycle) neden olabiliyordu. O anda asenkron bir dağıtım çalışıyorsa bu davranış süreci yarıda kesebiliyor, başarısız dağıtımlara veya yeniden denemelere yol açabiliyordu.
Deferred Kudu Recycle, dağıtımla doğrudan ilgisi olmayan yapılandırma değişikliklerinin bu şekilde kesintiye yol açmasını engellemeyi amaçlıyor. Derleme veya dağıtım hattını etkileyen kritik ayarların anında devreye girmesi ise güvence altında.
Deferred Kudu Recycle nasıl çalışıyor?
Linux App Service üzerinde Kudu; ZIP deploy, Git tabanlı dağıtımlar ve Oryx üzerinden yapılan derlemeler gibi dağıtım iş akışlarını yürütüyor. App settings veya connection strings değiştiğinde, güncellenmiş ortamın kullanılabilir hale gelmesi için Kudu’nun yeniden başlatılması gerekiyor.
Yeni davranışta işleyiş şöyle:
- Değişen ayar dağıtım açısından kritik değilse, Kudu’nun yeniden başlatılması devam eden asenkron dağıtım tamamlanana kadar erteleniyor.
- Değişen ayar dağıtım açısından kritikse, Kudu anında yeniden başlatılıyor; böylece dağıtım hattı doğru yapılandırmayı kullanıyor.
- Ayar değişikliğinden sonra başlatılan yeni dağıtımlar her koşulda güncellenmiş ortamı kullanıyor.
- Bu davranış yalnızca asenkron dağıtımlar için geçerli; senkron dağıtımlar bu düzenlemeden etkilenmiyor.
Ertelemenin bir üst sınırı var: pencere en fazla 40 dakika. Dağıtım bu süre içinde tamamlanmazsa Kudu yeniden başlatma işlemi yine de gerçekleşiyor ve devam eden dağıtım kesintiye uğrayabiliyor.
Hangi ayarlar “deployment-critical” sayılıyor?
Bazı ayarlar uygulamanın derlenme veya dağıtılma biçimini doğrudan etkiliyor. Bu tür ayarlardaki değişiklikler, önceki davranışta olduğu gibi anlık Kudu yeniden başlatmasını tetiklemeye devam ediyor.
Kaynakta belirtilen kritik ayar ve önek örnekleri şunlar:
| Ayar veya önek | Örnek |
|---|---|
| KUDU_* | KUDU_SYNC_CMD |
| ORYX_* | ORYX_BUILD_FLAGS |
| ENABLE_ORYX_BUILD | ENABLE_ORYX_BUILD |
| PRE_BUILD_* | PRE_BUILD_COMMAND |
| POST_BUILD_* | POST_BUILD_COMMAND |
| SCM_* | SCM_DO_BUILD_DURING_DEPLOYMENT |
| WEBSITE_SCM_* | — |
| WEBSITE_RUN_FROM_PACKAGE | WEBSITE_RUN_FROM_PACKAGE |
| WEBSITE_SWAP_SLOTNAME | WEBSITE_SWAP_SLOTNAME |
| WEBSITE_ELASTIC_SCALING_ENABLED | WEBSITE_ELASTIC_SCALING_ENABLED |
| MSBUILD_CONFIGURATION | MSBUILD_CONFIGURATION |
Bu ayarlar Kudu, Oryx ve SCM tarafındaki derleme ve dağıtım davranışını doğrudan biçimlendirdiği için değişiklik sırasında yapılan anlık yeniden başlatma, dağıtım hattının doğru yapılandırmayla çalışmasını garantiliyor.
Özel deployment-critical ayarları tanımlamak
Çoğu senaryoda ek bir yapılandırmaya gerek yok; varsayılan liste yaygın Kudu ve Oryx dağıtım ayarlarını kapsıyor. Derleme veya dağıtım süreciniz kendi tanımladığınız özel app settings üzerinde çalışıyorsa bu ayarları da kritik olarak işaretleyebilirsiniz.
Bunun için şu app setting kullanılıyor:
WEBSITE_DEPLOYMENT_CRITICAL_APPSETTINGSDeğer, noktalı virgülle ayrılmış ayar isimleri veya önekler listesi olarak veriliyor. Kaynakta verilen örnek şöyle:
WEBSITE_DEPLOYMENT_CRITICAL_APPSETTINGS=NODE_VERSION;MY_BUILD_FLAGBu yapılandırmanın ardından NODE_VERSION veya MY_BUILD_FLAG ayarlarındaki değişiklikler ertelenmek yerine anında Kudu yeniden başlatmayı tetikliyor.
Önerilen yaklaşım, bu listeyi olabildiğince dar tutmak. Yalnızca derleme veya dağıtım sürecinizin gerçekten bağlı olduğu ayarları eklemek, devam eden asenkron dağıtımların gereksiz yere kesintiye uğrama olasılığını düşük tutuyor.
Kullanıcı açısından ne değişiyor?
Deferred Kudu Recycle, dağıtım süreciyle ilgisi olmayan yapılandırma değişikliklerinden kaynaklanan kesintileri azaltarak dağıtım dayanıklılığını artırıyor. Kaynakta verilen örneğe göre, derleme sürecine etki etmeyen bir Application Insights instrumentation key veya özel bir çalışma zamanı ayarının değiştirilmesi, halihazırda devam eden asenkron bir dağıtımı artık yarıda kesmiyor.
Dağıtım için kritik olan ayarlar değiştiğinde ise App Service, Kudu’yu anında yeniden başlatmaya devam ediyor. Böylece derleme ve dağıtım iş akışları her zaman doğru yapılandırmayla çalışıyor.
Çoğu uygulama için ek aksiyon gerekmiyor
Bu iyileştirme platform tarafında etkinleştirildiği için çoğu uygulamada herhangi bir değişiklik yapmak gerekmiyor. Varsayılan davranış, ek yapılandırma yapmadan da dağıtım dayanıklılığında iyileşme sağlıyor.
WEBSITE_DEPLOYMENT_CRITICAL_APPSETTINGS ayarını yalnızca derleme veya dağıtım süreciniz üzerinde doğrudan etkisi olan özel app settings tanımlarınız varsa kullanmak öneriliyor. Aksi halde varsayılan liste, ek bir kurulum gerektirmeden beklenen iyileşmeyi sunuyor.
Kaynaklar ve İleri Okuma
- Improving Deployment Resiliency on Azure App Service for Linux with Deferred Kudu Recycle — Azure App Service Blog
- Kudu’da Log Görüntüleme: Linux App Service için Yeni Sayfa
- Azure App Service Linux’ta Startup Log Komutları
- Azure App Service Slot Deployment azd ile Kolaylaştı
- Azure App Service Slot Swap: Tek Komutla Değişim
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
Yorum gönder