Vanliga frågor och svar om Azure App Configuration

Appkonfiguration hjälper utvecklare att hantera programinställningar och styra funktionstillgänglighet. Syftet är att förenkla många av uppgifterna att arbeta med komplexa konfigurationsdata.

AppKonfiguration stöder:

• Hierarkiska namnrymder
• Etikettera
• Omfattande frågor
• Batchhämtning
• Specialiserade hanteringsåtgärder
• Ett användargränssnitt för funktionshantering

Appkonfiguration kompletterar Key Vault och de två bör användas sida vid sida i de flesta programdistributioner.

Även om App Configuration ger förstärkt säkerhet är Key Vault fortfarande den bästa platsen för att lagra programhemligheter. Key Vault tillhandahåller kryptering på maskinvarunivå, detaljerade åtkomstprinciper och hanteringsåtgärder som certifikatrotation.

Du kan skapa nyckelvärden för appkonfiguration som refererar till hemligheter som lagras i Key Vault. Mer information finns i Använda Key Vault-referenser i en ASP.NET Core-app.

Ja. AppKonfiguration krypterar alltid alla data under överföring och i vila. All nätverkskommunikation sker via TLS 1.2 eller TLS 1.3. App Configuration stöder kryptering i vila med antingen Microsoft-hanterade nycklar eller kundhanterade nycklar.

Med Azure App Service kan du definiera appinställningar för varje App Service-instans. De här inställningarna skickas som miljövariabler till programkoden. Du kan associera en inställning med ett specifikt distributionsfack om du vill. Mer information finns i Konfigurera appinställningar.

Med Azure App Configuration kan du däremot definiera inställningar som kan delas mellan flera appar. Detta inkluderar appar som körs i App Service och andra plattformar. Programkoden kommer åt de här inställningarna via konfigurationsprovidrar för .NET och Java, via Azure SDK eller direkt via REST-API:er.

Du kan lägga till referenser till dina appkonfigurationsdata i App Service-inställningarna. Du kan också importera och exportera inställningar mellan App Service och App Configuration. Med den här funktionen kan du snabbt konfigurera ett nytt App Configuration Store baserat på befintliga App Service-inställningar. Du kan också dela konfigurationen med en befintlig app som förlitar sig på App Service-inställningar.

Det finns en gräns på 10 kB för ett enda nyckelvärde, inklusive attribut som etikett, innehållstyp, taggar och andra metadata. Det finns ingen gräns för antalet nycklar och etiketter så länge deras totala storlek ligger under lagringsgränsen.

Den här nyckelvärdesgränsen bör vara tillräcklig för en enda inställning i de flesta program. Om du upptäcker att din inställning är större än den här gränsen kan du överväga att lagra dina data någon annanstans och lägga till en referens för dessa data i App Configuration.

En fullständig lista över gränser finns i Azure-prenumerations - och tjänstgränser.

Du styr vem som har åtkomst till App Configuration på nivån per butik. Använd ett separat arkiv för varje miljö som kräver olika behörigheter. Den här metoden ger den bästa säkerhetsisoleringen.

Om du inte behöver säkerhetsisolering mellan miljöer kan du använda etiketter för att skilja mellan konfigurationsvärden. Använd etiketter för att aktivera olika konfigurationer för olika miljöer är ett fullständigt exempel.

Se metodtips.

Det finns tre prisnivåer: Kostnadsfri, Standard och Premium. Detaljerad prisinformation finns på sidan för appkonfigurationspriser .

Alla appkonfigurationsnivåer erbjuder kärnfunktioner, inklusive konfigurationsinställningar, funktionsflaggor, Key Vault-referenser, konfigurationsögonblicksbilder, grundläggande hanteringsåtgärder, mått och loggar.

Följande är överväganden för att välja en nivå.

• Syfte: Den kostnadsfria nivån är perfekt för att utvärdera tjänsten i icke-produktionsmiljöer, så att du kan utforska dess funktioner utan kostnad. Standardnivån är skräddarsydd för användningsfall för medelstora volymer, vilket ger en balans mellan prestanda och kostnadseffektivitet. För produktionsbehov på hög volym eller på företagsnivå erbjuder Premium-nivån högsta prestanda och skalbarhet, vilket säkerställer att dina program körs smidigt även under hög belastning.

• Resurser per prenumeration: En resurs består av ett enda konfigurationslager. Varje prenumeration är begränsad till ett konfigurationslager per region på den kostnadsfria nivån. Prenumerationer kan ha ett obegränsat antal konfigurationslager på standard- och Premium-nivåerna.

• Lagring per resurs: På den kostnadsfria nivån är varje konfigurationsarkiv begränsat till 10 MB vanlig lagring och 10 MB lagringsutrymme för ögonblicksbilder. På standardnivån kan varje konfigurationslager använda upp till 1 GB vanlig lagring och ytterligare 1 GB lagringsutrymme för ögonblicksbilder. På Premium-nivån kan varje konfigurationslager använda upp till 4 GB vanlig lagring och ytterligare 4 GB lagringsutrymme för ögonblicksbilder.

• Revisionshistorik: App Configuration lagrar en historik över alla ändringar som gjorts i nycklar. På den kostnadsfria nivån lagras den här historiken i sju dagar. På nivåerna Standard och Premium lagras den här historiken i 30 dagar.

• Kvot för begäranden: Butiker på den kostnadsfria nivån är begränsade till 1 000 begäranden per dag. När ett arkiv når 1 000 begäranden returneras HTTP-statuskod 429 för alla begäranden fram till midnatt UTC.

  Standardnivålager är begränsade till 30 000 begäranden per timme. När timkvoten är slut kan ytterligare begäranden returnera en HTTP-statuskod 429, som anger för många begäranden, till slutet av timmen. När fler begäranden skickas som ligger över kvoten kan en högre procentandel av dem returnera statuskod 429.

  Premium-nivålager har ingen kvotgräns för begäranden, vilket säkerställer att åtkomsten till butiken aldrig blockeras.

• Dataflöde: Appkonfigurationslager på alla nivåer har en dataflödesersättning. Begäranden som överskrider den här ersättningen får ett HTTP-statuskod 429-svar. Butiker på den kostnadsfria nivån har inget garanterat dataflöde.

  Butiker på standardnivån tillåter körningsfrekvens† upp till 300 begäranden per sekund (RPS) för läsbegäranden och upp till 60 RPS för skrivbegäranden.

  Butiker på Premium-nivån tillåter körningsfrekvens† upp till 450 RPS för läsbegäranden och upp till 100 RPS för skrivbegäranden.

  †Körningshastigheten mäts vanligtvis som det genomsnittliga antalet begäranden som hanteras av ett appkonfigurationsarkiv utan begränsning under en angiven period.

• Serviceavtal: Den kostnadsfria nivån har inget serviceavtal. Standardnivån har ett serviceavtal med 99,9 % tillgänglighet och 99,95 % tillgänglighet med geo-replikering aktiverat. Premium-nivån har ett serviceavtal med 99,9 % tillgänglighet och 99,99 % tillgänglighet med geo-replikering aktiverat.

• Funktioner: Alla nivåer omfattar funktioner, inklusive kryptering med Microsoft-hanterade nycklar, autentisering via åtkomstnyckel eller Microsoft Entra-ID, Rollbaserad åtkomstkontroll i Azure (RBAC), hanterad identitet, tjänsttaggar och redundans i tillgänglighetszonen. Nivåerna Standard och Premium erbjuder fler funktioner, inklusive Private Link-stöd, kryptering med kundhanterade nycklar, skydd mot mjuk borttagning och geo-replikering.

• Kostnad: Det kostar ingenting att använda en butik på den kostnadsfria nivån.

  Standardnivålager har en daglig användningsavgift, som inkluderar de första 200 000 begäranden varje dag. Begäranden utöver den här dagliga allokeringen medför en överförbrukningsavgift.

  Premium-nivålager har också en daglig användningsavgift och inkluderar en replik. De första 800 000 begäranden för ursprunget och de första 800 000 begäranden för repliken varje dag ingår i den dagliga avgiften. Begäranden som överskrider den här dagliga allokeringen medför en överförbrukningsavgift.

Du kan uppgradera ett appkonfigurationsarkiv när som helst, till exempel från den kostnadsfria nivån till standard- eller Premium-nivån, eller från standardnivån till Premium-nivån.

Du kan inte nedgradera ett appkonfigurationsarkiv, till exempel från Premium-nivån till standardnivån, eller från standardnivån till den kostnadsfria nivån. Du kan dock skapa ett nytt lager på önskad nivå och sedan importera konfigurationsdata till det lagret.

Kunddata som lagras i App Configuration finns i den region där kundens appkonfigurationsarkiv skapades. Kunddata replikeras endast till en annan region om kunden aktiverar geo-replikering för den regionen. Detta gäller för alla tillgängliga regioner. Kunder kan flytta, kopiera eller komma åt sina data från valfri plats globalt.

Azure App Configuration stöder geo-replikering för förbättrad återhämtning till regionala avbrott.

Azure App Configuration har stöd för Azure-tillgänglighetszoner för att skydda ditt program och dina data från enskilda datacenterfel. Alla tillgängliga zonaktiverade regioner består av minst tre tillgänglighetszoner, där var och en är ett fysiskt oberoende datacenter. För återhämtning är det här stödet i App Configuration aktiverat för alla kunder utan extra kostnad. Följande är regioner där App Configuration har aktiverat stöd för tillgänglighetszoner. Mer information finns i Azure-regioner med stöd för tillgänglighetszoner.

Följande är regioner där App Configuration har aktiverat stöd för tillgänglighetszoner.

AppKonfigurationslager har olika kvoter för begäranden baserat på deras nivå. Butiker på den kostnadsfria nivån är begränsade till 1 000 begäranden per dag, standardnivåbutiker till 30 000 begäranden per timme och Premium-nivåbutiker har inga begärandegränser, vilket garanterar oavbruten åtkomst.

App Configuration-butiker har dataflödesersättningar baserat på deras nivå. Butiker på den kostnadsfria nivån har inte garanterat dataflöde. Standardnivålager stöder körningsfrekvens på upp till 300 begäranden per sekund (RPS) för läsåtgärder och upp till 60 RPS för skrivåtgärder. Premium-nivålager stöder körningsfrekvens på upp till 450 RPS för läsåtgärder och upp till 100 RPS för skrivåtgärder.

Låt oss ta ett exempel och anta att du har ett program med 1 000 konfigurationsinställningar. Programmet läser in alla dessa inställningar från App Configuration vid start. Därefter söker den efter en sentinel-nyckel för konfigurationsändringar var 30:e sekund. Oavsett om du kör på Kubernetes, App Service eller virtuella datorer antar vi att du har 50 instanser av ditt program som körs samtidigt.

Först ska vi uppskatta begäranden för konfigurationsövervakning. Varje instans av ditt program skickar en begäran om sentinel-nyckeln till App Configuration var 30:e sekund, så den skickar 120 (=3600/30) begäranden på en timme. Eftersom du har 50 instanser av ditt program skickar programmet totalt 6 000 (=120 x 50) begäranden varje timme för konfigurationsövervakning. Observera att eftersom sentinel-nyckelbegäranden är frekventa och mestadels oförändrade räknas de flesta inte mot lagringsgränsen per timme† för ett standardnivålager.

För det andra ska vi uppskatta begäranden om inläsning/inläsning av konfigurationen. Programmet läser in alla inställningar vid start eller när en sentinel-nyckeländring identifieras. Varje begäran till App Configuration kan hämta upp till 100 nyckelvärden, så det krävs 10 (=1 000/100) begäranden för att läsa in alla inställningar. Eftersom du har 50 programinstanser skickar du totalt 500 (=10x50) begäranden när programmet startar om eller läser in konfigurationen igen.

Äntligen sätter vi ihop det. Förutsatt att du har uppdaterat sentinel-nyckeln två gånger inom en timme får appkonfigurationsarkivet därför 7 000 (=6 000+500 x 2) totala begäranden för den timmen. Observera att av dessa begäranden använder endast cirka 1 000 (=500 x 2) begäranden den tillgängliga timkvoten för ett standardnivåarkiv. Uppdatera siffrorna i det här exemplet så att de matchar din specifika konfiguration och design så att du har en tillräcklig buffert mot timkvotgränsen.

†Free-nivålager har inte frekventa, upprepade begäranden som utesluts från deras dagliga gräns.

Ditt program kan få ett HTTP-statuskod 429-svar under följande omständigheter:

• Överskrider den dagliga begärandekvoten för ett lager på den kostnadsfria nivån.
• Överskrider kvoten för begäranden varje timme för ett lager på standardnivån.
• Överskrider dataflödesersättningen för ett lager på valfri nivå.
• Överskrider bandbreddsersättningen för ett lager på valfri nivå.
• Försöker skapa eller ändra ett nyckelvärde när lagringskvoten överskrids.

Kontrollera brödtexten i 429-svaret av den specifika orsaken till att begäran misslyckades. Du kan också samla in loggar för appkonfigurationsarkivet i Azure Monitor och konfigurera aviseringar för måttet Kvotanvändning för begäran.

Att ta emot tillfällig HTTP-statuskod 429-svar orsakar vanligtvis ingen skada, eftersom App Configuration-klienter hanterar dem korrekt. Men om ditt program regelbundet får HTTP-statuskod 429-svar bör du överväga följande alternativ:

• Uppgradera din butik till Premium-nivån: Den här nivån har ingen kvotgräns för begäranden och har ökad lagringskvot och högre dataflödesersättning.
• Använd appkonfigurationsprovidrar: Leverantörerna har inbyggda funktioner för återförsök och cachelagring tillsammans med många andra återhämtningsfunktioner. Se till att uppdatera till den senaste versionen av providern för alla de senaste förbättringarna.
• Använd SDK:er för appkonfiguration om ditt program behöver skicka skrivbegäranden. Även om SDK:erna kanske inte är lika funktionsrika som providers, försöker de automatiskt igen med HTTP-statuskod 429-svar och andra tillfälliga fel.
• Inkludera logik för återförsök i anpassade klienter om du inte kan använda appkonfigurationsproviders eller SDK:er. Rubriken retry-after-ms i svaret ger en föreslagen väntetid (i millisekunder) innan begäran försöker igen.
• Distribuera begäranden över flera klientinstanser: Detta bidrar till att uppnå maximalt dataflöde från appkonfigurationsarkivet.
• Minska antalet begäranden som görs till App Configuration: Följ anvisningarna för att minimera antalet begäranden.
• Förbättra programmets återhämtning: Överväg att integrera geo-replikering för att tillåta redundans och belastningsutjämning. Kontrollera metodtipsen för att skapa mycket motståndskraftiga program.

Alla appkonfigurationslager på standard- och Premium-nivåerna har automatiskt aktiverat funktionen för mjuk borttagning . När ett appkonfigurationsarkiv på Standard- eller Premium-nivå tas bort reserveras dess namn för kvarhållningsperioden. Om du vill återskapa ett arkiv med samma namn innan kvarhållningsperioden upphör att gälla måste du först rensa det mjukt borttagna arkivet , förutsatt att arkivet inte har rensningsskydd aktiverat. Om rensningsskyddet är aktiverat måste du vänta tills kvarhållningsperioden har gått ut. Använd rensningsfunktionen eller ange en kortare kvarhållningsperiod om du ofta behöver återskapa ett arkiv med samma namn. Arbetsflöden som kräver återskapande av ett arkiv med samma namn bör ge en timme mellan att rensa ett konfigurationsarkiv och utföra den efterföljande skapande. Den här rekommendationen är på plats eftersom den faktiska rensningen av konfigurationsarkivresurser utförs asynkront när en rensning har begärts, vilket kräver lite extra tid för att slutföra. För att undvika att behöva vänta rekommenderas arbetsflöden som skapar tillfälliga konfigurationslager att använda unika namn.

Alla appkonfigurationslager på standard- och Premium-nivåerna stöder funktionen för mjuk borttagning , som inte kan inaktiveras. Du kan återställa ett borttaget arkiv inom kvarhållningsperioden. Följ de här anvisningarna för att återställa ett appkonfigurationsarkiv som tagits bort av misstag.

Ja. Du kan hantera funktionsflaggor och Key Vault-referenser i App Configuration via Azure Portal eller CLI, men du kan också skapa och uppdatera dem programmatiskt med hjälp av SDK:er för appkonfiguration. Därför kan du skriva din anpassade hanteringsportal eller hantera dem i DIN CI/CD programmatiskt. Funktionsflaggan och Key Vault-referens-API:er är tillgängliga i SDK:er för alla språk som stöds. Kolla in exempellänkarna för exempel på varje språk som stöds.

Utvärdering och användning av funktionsflaggor i ditt program kräver appkonfigurationsprovidern och funktionshanteringsbiblioteken, som är tillgängliga i .NET och Java Spring. Mer information finns i avsnittet Funktionshantering under Snabbstarter och Självstudier.

Spring-profiler är ett sätt att separera delar av ditt program, inklusive konfiguration, och göra det endast tillgängligt i vissa miljöer eller när specifika bibliotek används.

Du rekommenderas att ange etiketten för dina nyckelvärden så att den matchar dina Spring-profiler. Som standard läser App Configuration Spring-providerbiblioteket in nyckelvärdena med de etiketter som matchar de aktuella aktiva Spring-profilerna (${spring.profiles.active}) om etikettfiltret inte anges explicit. Om det inte finns någon aktiv Spring-profiluppsättning läses nyckelvärden utan etikett in.

Med profiler dev och prodskapar du till exempel nyckelvärden i enlighet med följande etiketter.

När Spring-profilen är inställd på devblir Hello from devvärdet config.message för . När Spring-profilen är inställd på prodblir Hello from prodvärdet config.message för .

Det här standardbeteendet kan åsidosättas genom att ange etikettfiltret i bootstrap-filen. Spring-providerbiblioteket läser in nyckelvärden med de angivna etiketterna oavsett den aktiva Spring-profilen.

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

Om du vill välja andra etiketter och dina Spring-profiler kan du använda ett etikettfilter som ',${spring.profiles.active}', som väljer alla nycklar utan etikett och de som matchar dina Spring-profiler. Etiketterna längst till höger prioriteras när dubbletter av nycklar hittas.

Från och med version 3.1.0 Microsoft.FeatureManagement tillåter biblioteket att funktionshanteringstjänster körs, inklusive funktionsfilter, som begränsade tjänster i beroendeinmatningsbaserade .NET-program. Om du vill dra nytta av den här funktionen kan du helt enkelt ersätta anropet AddFeatureManagement i koden med AddScopedFeatureManagement, som du ser i följande kodfragment:

services.AddScopedFeatureManagement();

Funktionsfilter kan utvärdera en funktionsflagga baserat på egenskaperna för en HTTP-begäran. Detta utförs vanligtvis genom att HttpContext granska genom singleton-mönstretIHttpContextAccessor. Det här mönstret fungerar dock inte för Blazor-serverprogram där begränsade tjänster ska användas i stället. I det här fallet AddScopedFeatureManagement ska metoden användas.

Prenumerera på vår Lagringsplats för GitHub-meddelanden.

Du kan nå oss direkt på GitHub.

• Om Azure App Configuration