Azure Uygulaması Yapılandırması hakkında SSS

Uygulama Yapılandırması, geliştiricilerin uygulama ayarlarını yönetmelerine ve özellik kullanılabilirliğini denetlemelerine yardımcı olur. Karmaşık yapılandırma verileriyle çalışma görevlerinin çoğunu basitleştirmeyi amaçlar.

Uygulama Yapılandırması destekler:

• Hiyerarşik ad alanları
• Etiketleme
• Kapsamlı sorgular
• Toplu alma
• Özel yönetim işlemleri
• Özellik yönetimi kullanıcı arabirimi

Uygulama Yapılandırması Key Vault'a tamamlar ve bu ikisi çoğu uygulama dağıtımında yan yana kullanılmalıdır.

Uygulama Yapılandırması sağlamlaştırılmış güvenlik sağlasa da, Key Vault yine de uygulama gizli dizilerini depolamak için en iyi yerdir. Key Vault donanım düzeyinde şifreleme, ayrıntılı erişim ilkeleri ve sertifika döndürme gibi yönetim işlemleri sağlar.

Key Vault'ta depolanan gizli dizilere başvuran Uygulama Yapılandırması anahtar değerleri oluşturabilirsiniz. Daha fazla bilgi için bkz . ASP.NET Core uygulamasında Key Vault başvurularını kullanma.

Evet. Uygulama Yapılandırması aktarımdaki ve bekleyen tüm verileri her zaman şifreler. Tüm ağ iletişimi TLS 1.2 veya TLS 1.3 üzerinden yapılır. Uygulama Yapılandırması, bekleyen şifrelemeyi ikisiyle de desteklerMicrosoft tarafından yönetilen anahtarlar veya müşteri tarafından yönetilen anahtarlar.

Azure Uygulaması Hizmeti, her App Service örneği için uygulama ayarlarını tanımlamanıza olanak tanır. Bu ayarlar, uygulama koduna ortam değişkenleri olarak geçirilir. İsterseniz bir ayarı belirli bir dağıtım yuvasıyla ilişkilendirebilirsiniz. Daha fazla bilgi için bkz . Uygulama ayarlarını yapılandırma.

Buna karşılık, Azure Uygulaması Yapılandırması birden çok uygulama arasında paylaşılabilen ayarları tanımlamanıza olanak tanır. Buna App Service'te çalışan uygulamaların yanı sıra diğer platformlar da dahildir. Uygulama kodunuz bu ayarlara .NET ve Java yapılandırma sağlayıcıları aracılığıyla, Azure SDK aracılığıyla veya doğrudan REST API'leri aracılığıyla erişir.

App Service'inizin Uygulama ayarlarından Uygulama Yapılandırması verilerinize başvurular ekleyebilirsiniz. App Service ile Uygulama Yapılandırması arasında da ayarları içeri ve dışarı aktarabilirsiniz. Bu özellik, mevcut App Service ayarlarına göre hızlı bir şekilde yeni bir Uygulama Yapılandırması deposu ayarlamanıza olanak tanır. Yapılandırmayı App Service ayarlarına bağlı olan mevcut bir uygulamayla da paylaşabilirsiniz.

Etiket, içerik türü, etiketler ve diğer meta veriler gibi öznitelikler de dahil olmak üzere tek bir anahtar değeri için 10 KB sınırı vardır.

Bu sınır çoğu uygulamada tek bir ayar için yeterli olmalıdır. Ayarınızın bu sınırdan daha büyük olduğunu fark ederseniz verilerinizi başka bir yerde depolamayı ve bu verilerin başvurularını Uygulama Yapılandırması ekleyebilirsiniz.

Daha fazla bilgi için bkz . Azure aboneliği ve hizmet sınırları.

Uygulama Yapılandırması kimlerin mağaza düzeyinde erişebileceğini siz denetlersiniz. Farklı izinler gerektiren her ortam için ayrı bir depo kullanın. Bu yaklaşım en iyi güvenlik yalıtımını sağlar.

Ortamlar arasında güvenlik yalıtımına ihtiyacınız yoksa, yapılandırma değerlerini ayırt etmek için etiketleri kullanabilirsiniz. Farklı ortamlar için farklı yapılandırmaları etkinleştirmek için etiketleri kullanmak tam bir örnek sağlar.

En iyi yöntemlere bakın.

İki fiyatlandırma katmanı vardır:

• Ücretsiz katmanı
• Standart katmanı

Standart katmanın kullanıma sunulmasından önce bir mağaza oluşturduysanız, genel kullanıma sunulduğunda otomatik olarak Ücretsiz katmanına taşınır. Standart katmana yükseltmeyi veya Ücretsiz katmanında kalmayı seçebilirsiniz.

Bir mağazayı Standart katmandan Ücretsiz katmanına düşüremezsiniz. Ücretsiz katmanında yeni bir depo oluşturabilir ve ardından yapılandırma verilerini bu depoya aktarabilirsiniz.

Her iki Uygulama Yapılandırması katmanı da yapılandırma ayarları, özellik bayrakları, Key Vault başvuruları, yapılandırma anlık görüntüleri, temel yönetim işlemleri, ölçümler ve günlükler gibi temel işlevleri sunar.

Aşağıda katman seçmeyle ilgili dikkat edilmesi gerekenler yer alır.

• Abonelik başına kaynaklar: Kaynak tek bir yapılandırma deposundan oluşur. Her abonelik, ücretsiz katmandaki bölge başına bir yapılandırma deposuyla sınırlıdır. Aboneliklerin standart katmanda sınırsız sayıda yapılandırma deposu olabilir.

• Kaynak başına Depolama: Ücretsiz katmanda her yapılandırma deposu 10 MB normal depolama alanı ve 10 MB anlık görüntü depolama alanı ile sınırlıdır. Standart katmanda her yapılandırma deposu 1 GB'a kadar normal depolama alanı ve ek 1 GB anlık görüntü depolama alanı kullanabilir.

• Düzeltme geçmişi: Uygulama Yapılandırması anahtarlarda yapılan tüm değişikliklerin geçmişini depolar. Ücretsiz katmanda bu geçmiş yedi gün boyunca depolanır. Standart katmanda bu geçmiş 30 gün boyunca depolanır.

• İstek kotası: Ücretsiz katman depoları günde 1.000 istekle sınırlıdır. Bir mağaza 1.000 isteğe ulaştığında, UTC gece yarısına kadar tüm istekler için 429 HTTP durum kodunu döndürür.

  Standart katman depoları saatte 30.000 istekle sınırlıdır. Saatlik kota tükendiğinde, istekler saatin sonuna kadar çok fazla istek olduğunu belirten HTTP durum kodu 429 döndürebilir. Kotanın üzerinde olan daha fazla istek gönderildikçe, bunların daha yüksek bir yüzdesi durum kodu 429 döndürebilir.

• Hizmet düzeyi sözleşmesi: Standart katmanın SLA'sı %99,9 kullanılabilirlik ve %99,95 kullanılabilirlik ve coğrafi çoğaltma etkindir. Ücretsiz katmanın SLA'sı yoktur.

• Özellikler: Her iki katman da Microsoft tarafından yönetilen anahtarlarla şifreleme, erişim anahtarı veya Microsoft Entra Kimliği aracılığıyla kimlik doğrulaması, Azure rol tabanlı erişim denetimi (RBAC), yönetilen kimlik, hizmet etiketleri ve kullanılabilirlik alanı yedekliliği gibi işlevleri içerir. Standart katman, Özel Bağlantı desteği, müşteri tarafından yönetilen anahtarlarla şifreleme, geçici silme koruması ve coğrafi çoğaltma özelliği gibi daha fazla işlev sunar.

• Maliyet: Standart katman mağazalarının günlük kullanım ücreti vardır. Her gün ilk 200.000 istek günlük ücrete dahildir. Günlük ayırmayı aşan istekler için fazla kullanım ücreti de vardır. Ücretsiz katman mağazasını kullanmanın bir maliyeti yoktur.

İstediğiniz zaman Ücretsiz katmanından Standart katmana yükseltebilirsiniz.

Bir mağazayı Standart katmandan Ücretsiz katmanına düşüremezsiniz. Ücretsiz katmanında yeni bir depo oluşturabilir ve ardından yapılandırma verilerini bu depoya aktarabilirsiniz.

Uygulama Yapılandırması'de depolanan müşteri verileri, müşterinin Uygulama Yapılandırması deposunun oluşturulduğu bölgede yer alır. Müşteri verileri, yalnızca müşteri bu bölge için coğrafi çoğaltmayı etkinleştirirse başka bir bölgeye çoğaltılır . Bu, kullanılabilir tüm bölgeler için geçerlidir. Müşteriler verileri küresel olarak herhangi bir konumdan taşıyabilir, kopyalayabilir veya bu verilere erişebilir.

Azure Uygulaması Yapılandırması, bölgesel kesintilere karşı gelişmiş dayanıklılık için coğrafi çoğaltmayı destekler.

Azure Uygulaması Yapılandırması, uygulamanızı ve verilerinizi tek veri merkezi hatalarına karşı korumak için Azure kullanılabilirlik alanlarını destekler. Kullanılabilirlik alanının etkinleştirildiği tüm bölgeler, her birinin fiziksel olarak bağımsız bir veri merkezi olduğu en az 3 kullanılabilirlik bölgesinden oluşur. Dayanıklılık için, Uygulama Yapılandırması'deki bu destek ek ücret ödemeden tüm müşteriler için etkinleştirilir. Aşağıda, kullanılabilirlik alanı desteğini etkinleştirmiş Uygulama Yapılandırması bölgeler yer alır. Daha fazla bilgi için bkz. Azure'da bölgeler ve Kullanılabilirlik Alanları.

Aşağıda, Uygulama Yapılandırması kullanılabilirlik alanı desteğini etkinleştirdiği bölgeler yer alır.

Ücretsiz katmanındaki yapılandırma depoları günde 1.000 istekle sınırlıdır. Standart katmandaki yapılandırma depoları, istek hızı saatte 30.000 isteği aştığında geçici azaltmayla karşılaşabilir.

Bir mağaza standart katmanda sınırına ulaştığında, saatin sonuna kadar yapılan bazı istekler için HTTP durum kodu 429 döndürebilir. Yanıttaki retry-after-ms üst bilgi, isteği yeniden denemeden önce önerilen bir bekleme süresi (milisaniye) verir.

Uygulamanız düzenli olarak HTTP durum kodu 429 yanıtlarıyla karşılaşıyorsa, yapılan istek sayısını azaltmak için yeniden tasarlamayı göz önünde bulundurun. Daha fazla bilgi için bkz. Uygulama Yapılandırması yapılan istekleri azaltma.

Bu koşullar altında bir HTTP durum kodu 429 yanıtı alırsınız:

• Ücretsiz katmanındaki bir mağaza için günlük istek sınırını aşma.
• Standart katmandaki bir mağaza için saatlik istek sınırını aşma.
• Büyük bir istek patlaması nedeniyle anlık azaltma†.
• Aşırı bant genişliği kullanımı nedeniyle anlık azaltma†.
• Depolama kotası aşıldığında anahtar oluşturmaya veya değiştirmeye çalışma.

İsteğin başarısız olmasının belirli bir nedeni için 429 yanıtının gövdesini denetleyin.

†Bir yapılandırma deposu, büyük miktarda istek aldığında veya aşırı miktarda veri aktarırsa anlık azaltmayla karşılaşabilir. Azure SDK, yapılandırma sağlayıcısı kitaplıkları ve Azure Pipelines görevleri gibi istemciler Uygulama Yapılandırması kısıtlanmış isteklerde otomatik olarak yeniden deneyin. Bu istemcilerden birini veya kısıtlanmış istekleri yeniden deneyen özel bir istemciyi kullanan tüm uygulamalar için, bu anlık azaltmanın gerçekleşmesi durumunda fark edilmemesi gerekir.

Bir örnek alalım ve 1.000 yapılandırma ayarına sahip bir uygulamanız olduğunu varsayalım. Uygulamanız başlangıçta Uygulama Yapılandırması tüm bu ayarları yükler. Bundan sonra, her 30 saniyede bir yapılandırma değişiklikleri için bir sentinel anahtarı denetler. Kubernetes, App Service veya VM'lerde çalışıyor olun, uygulamanızın 50 örneğinin aynı anda çalıştığını varsayalım.

İlk olarak, yapılandırma izleme isteklerini tahmin edelim. Uygulamanızın her örneği sentinel anahtarı için her 30 saniyede bir Uygulama Yapılandırması bir istek gönderir, bu nedenle bir saat içinde 120 (=3600/30) istek gönderir. Uygulamanızın 50 örneği olduğu düşünüldüğünde, uygulamanız yapılandırma izleme için saatte bir 6.000 (=120x50) toplam istek gönderir. Sentinel anahtar istekleri sık ve çoğunlukla değişmediğinden, çoğu mağaza saatlik kota sınırlarına göre sayılmaz†.

İkinci olarak, yapılandırma yükleme/yeniden yükleme isteklerini tahmin edelim. Uygulamanız başlangıçta veya bir sentinel anahtarı değişikliği algılandığında tüm ayarları yükler. her Uygulama Yapılandırması isteği en fazla 100 anahtar değeri alabilir, bu nedenle tüm ayarları yüklemek için 10 (=1000/100) istek gerekir. 50 uygulama örneğiniz olduğu düşünüldüğünde, uygulamanız yapılandırmasını yeniden başlattığınızda veya yeniden yüklediğinde toplam 500 (=10x50) istek gönderirsiniz.

Son olarak, bir araya getirelim. Sentinel anahtarını bir saat içinde iki kez güncelleştirdiğiniz varsayıldığında, Uygulama Yapılandırması mağazanız bu saat için toplam 7.000 (=6.000+500x2) istek alır. Bu isteklerden yalnızca yaklaşık 1.000 (=500x2) isteğin kullanılabilir saatlik kotayı kullanacağını unutmayın. Saatlik azaltma sınırına karşı yeterli bir arabelleğe sahip olmak için bu örnekteki sayıları, belirli kurulum ve tasarımınızla eşleşecek şekilde güncelleştirin. Daha fazla bilgi için bkz. Uygulama Yapılandırması yapılan istekleri azaltma.

†Free katman depolarında sık sık yinelenen istekler günlük sınırlarından dışlanmaz.

Standart katmandaki tüm Uygulama Yapılandırması depoları geçici silme özelliğini otomatik olarak etkinleştirdi. Standart katman Uygulama Yapılandırması deposu silindiğinde, bu katmanın adı saklama süresi için ayrılır. Saklama süresi dolmadan önce aynı ada sahip bir depoyu yeniden oluşturmak için , mağazada temizleme koruması etkinleştirilmemişse önce geçici olarak silinen depoyu temizlemeniz gerekir. Temizleme koruması etkinse saklama süresinin geçmesini beklemeniz gerekir. Aynı ada sahip bir mağazayı yeniden oluşturmanız gerekirse temizleme işlevini kullanın veya daha kısa bir saklama süresi ayarlayın. Aynı ada sahip bir deponun yeniden oluşturulmasını gerektiren iş akışları, yapılandırma depolarını temizleme ve sonraki oluşturma işlemini gerçekleştirme arasında bir saat izin vermelidir. Temizleme istendikten sonra yapılandırma deposu kaynaklarının gerçek temizliği zaman uyumsuz olarak gerçekleştirildiğinden ve sonlandırmak için biraz ek süre gerektirdiğinden bu öneri uygulanır. Bekleme gereksinimini önlemek için kısa ömürlü yapılandırma depoları oluşturan iş akışlarının benzersiz adlar kullanması önerilir.

Standart katmandaki tüm Uygulama Yapılandırması depoları geçici silme özelliğini destekler ve bu özellik devre dışı bırakılamaz. Silinen depoları saklama süresi içinde kurtarabilirsiniz. Yanlışlıkla silinen Uygulama Yapılandırması depolarını kurtarmak için bu yönergeleri izleyin.

Evet. Azure portalı veya CLI aracılığıyla Uygulama Yapılandırması'de özellik bayraklarını ve Key Vault başvurularını yönetebilirsiniz ancak Uygulama Yapılandırması SDK'ları kullanarak bunları program aracılığıyla da oluşturabilir ve güncelleştirebilirsiniz. Bu nedenle, özelleştirilmiş yönetim portalınızı yazabilir veya bunları program aracılığıyla CI/CD'nizde yönetebilirsiniz. Özellik bayrağı ve Key Vault başvuru API'leri desteklenen tüm dillerin SDK'larında kullanılabilir. Desteklenen her dildeki örnekler için örnek bağlantılara göz atın.

Uygulamanızda özellik bayraklarının değerlendirilmesi ve tüketilmesi için .NET ve Java Spring'de kullanılabilen Uygulama Yapılandırması sağlayıcısı ve özellik yönetimi kitaplıkları gerekir. Daha fazla bilgi için Hızlı Başlangıçlar ve Öğreticiler altındaki Özellik yönetimi bölümüne göz atın.

Spring profilleri, yapılandırma dahil olmak üzere uygulamanızın bölümlerini ayırmak ve yalnızca belirli ortamlarda veya belirli kitaplıklar kullanıldığında kullanılabilir hale getirmek için bir yol sağlar.

Anahtar-değerlerinizin etiketini Spring profillerinizle eşleşecek şekilde ayarlamanız önerilir. Varsayılan olarak, Uygulama Yapılandırması Spring sağlayıcı kitaplığı, etiket filtresi açıkça ayarlanmazsa geçerli etkin Spring profilleriyle (${spring.profiles.active}) eşleşen etiketlerle anahtar değerlerini yükler. Etkin Spring profil kümesi yoksa, "etiketsiz" anahtar değerleri yüklenir.

Örneğin, profiller dev ve prodile aşağıdaki etiketlere göre anahtar-değerler oluşturursunuz.

Spring profili olarak devayarlandığında değeri config.message olur Hello from dev. Spring profili olarak prodayarlandığında değeri config.message olur Hello from prod.

Bu varsayılan davranış, bootstrap dosyanızda etiket filtresi ayarlanarak geçersiz kılınabilir. Spring sağlayıcı kitaplığı, etkin Spring profilinden bağımsız olarak belirtilen etiketlere sahip anahtar değerlerini yükler.

spring.cloud.azure.appconfiguration.stores[0].selects[0].label-filter: my-label

Diğer etiketleri ve Spring profillerinizi seçmek için, etiketi olmayan tüm anahtarları ve Spring profillerinizle eşleşenleri seçen gibi ',${spring.profiles.active}'bir etiket filtresi kullanabilirsiniz. Yinelenen anahtarlar bulunduğunda en sağdaki etiketler öncelik alır.

Sürüm 3.1.0'dan başlayarak kitaplık, Microsoft.FeatureManagement bağımlılık ekleme tabanlı .NET uygulamalarında kapsamlı hizmetler olarak özellik filtreleri de dahil olmak üzere özellik yönetim hizmetlerinin çalıştırılmasına olanak tanır. Bu özelliğin avantajlarından yararlanmak için, aşağıdaki kod parçacığında gösterildiği gibi kodunuzdaki çağrıyı ile AddScopedFeatureManagementdeğiştirmeniz AddFeatureManagement yeterlidir:

services.AddScopedFeatureManagement();

Özellik filtreleri, http isteğinin özelliklerine göre bir özellik bayrağını değerlendirebilir. Bu genellikle tekil IHttpContextAccessordesen üzerinden incelenerek HttpContext gerçekleştirilir. Ancak bu düzen, kapsamlı hizmetlerin kullanılması gereken Blazor sunucu uygulamalarında çalışmaz. Bu durumda yöntemi AddScopedFeatureManagement kullanılmalıdır.

GitHub duyuruları depomuza abone olun.

Doğrudan GitHub'dan bize ulaşabilirsiniz.

• Azure Uygulaması Yapılandırması Hakkında