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. App Configuration krypterar alltid all data under överföring och lagring. 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 koppla en inställning till en specifik distributionsplats, 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 SDKs 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 namngivningsbegränsningar och prenumerations- och tjänstgränser.

Du styr vem som har åtkomst till App Configuration på nivån per butik. Använd en separat lagringsplats 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 fyra prisnivåer: Kostnadsfri, Utvecklare, 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.

  Utvecklarnivån är kostnadseffektiv för användningsfall med låg volym och icke-produktion och är utrustad med funktioner som är särskilt anpassade för utvecklings- och testningsbehov.

  Standardnivån är utformad för medelstora produktions- och icke-produktionsanvändningsfall, 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 tunga belastningar.

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

• 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å nivån Utvecklare kan varje konfigurationslager använda upp till 500 MB vanlig lagring och ytterligare 500 MB ögonblicksbildslagring. 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å nivåerna Kostnadsfri och Utvecklare 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 en butik når 1 000 begäranden returnerar den HTTP-statuskod 429 för alla begäranden fram till midnatt UTC.

  Butiker på utvecklarnivå är begränsade till 6 000 begäranden per timme. När timkvoten är slut returnerar ytterligare begäranden en HTTP-statuskod 429, som anger för många begäranden, till slutet av timmen.

  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: App Configuration-lager på samtliga nivåer har en gräns för dataflöde. Begäranden som överskrider den här ersättningen får ett HTTP-statuskod 429-svar.

  Butiker på kostnadsfri nivå och utvecklarnivå har ingen garanterad kapacitet.

  Lagringskonton på Standard-nivån har en genomströmning† på upp till 300 begäranden per sekund (RPS) för läsbegäranden och upp till 60 RPS för skrivbegäranden.

  Databaser på Premium-nivån stöder en genomströmning† på 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 och utvecklarnivå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ån Developer innehåller även stöd för Private Link.

  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.

  Butiker på utvecklarnivå har en daglig användningsavgift, som innehåller de första 3 000 begärandena varje dag. Begäranden utöver den här dagliga allokeringen medför en överförbrukningsavgift.

  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 nivån Developer, Standard eller Premium, eller från nivån Developer, Standard till Premium-nivån.

Du kan nedgradera ett appkonfigurationsarkiv från Premium-nivån till standardnivån eftersom båda nivåerna är utformade för produktionsanvändning. Nedgradering till en icke-produktionsnivå, till exempel den kostnadsfria nivån, stöds dock inte. För att uppnå detta kan du skapa ett nytt lager på önskad nivå och sedan importera konfigurationsdata till det lagret.

Innan du nedgraderar ett appkonfigurationsarkiv från Premium-nivån till Standard-nivån kontrollerar du att din användning av vanlig lagring och ögonblicksbildslagring ligger under standardnivåns gränser. Du kan verifiera din aktuella användning via Azure Monitor-måtten, Daglig lagringsanvändning och Lagringsstorlek för ögonblicksbilder för din appkonfigurationsbutik i Azure-portalen.

Kunddata som lagras i App Configuration finns i den region där kundens App Configuration-butik 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.

App Configuration-butiker har olika begärandekvoter beroende på nivå. Butiker på den kostnadsfria nivån är begränsade till 1 000 begäranden per dag, utvecklarnivåbutiker till 6 000 begäranden per timme, Standardnivålager till 30 000 begäranden per timme och Premium-nivåbutiker har inga begärandegränser, vilket garanterar oavbruten åtkomst.

App Configuration-resurser har dataflödesgränser beroende på nivå. Butiker i den kostnadsfria nivån och utvecklarnivån har ingen garanterad kapacitet. 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, låt oss uppskatta förfrågningarna för inläsning/omlä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 förfrågningar är det bara cirka 1 000 (=500 x 2) som använder den tillgängliga timkvoten för ett lagringskonto på standardnivå. 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.

*Funktionsflaggor använder inte sentinel-nyckeln för att övervaka ändringar och övervakas separat från konfigurationen. Det krävs en begäran om att övervaka var 100:e funktionsflaggor per uppdateringsintervall.

†Butiker på gratisnivån har inte frekventa, upprepade förfrågningar som undantas från den dagliga gränsen.

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

• Överskrider den dagliga kvoten för antal begäranden för en butik i gratisnivån.
• Överskridande av timkvoten för förfrågningar för en butik på utvecklarnivå.
• Överskridande av den timvisa kvoten för begäranden för en butik i Standard-nivån.
• Överskridande av genomströmningsgränsen för en lagringsresurs på någon 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 svarstexten i 429-svaret för den specifika anledningen till att förfrågan misslyckades. Du kan också samla in loggar för ditt App Configuration-lager i Azure Monitor och ställa in aviseringar för måttet Användning av begärandekvot.

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 leverantörerna gör de automatiska omförsök vid svar med HTTP-statuskod 429 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.
• Minska kvarhållningen av nyckel/värde-ändringshistorik om du gör frekventa uppdateringar av nyckel/värde och inte behöver behålla ändringshistorik under den maximala varaktighet som tillåts av din App Configuration store. Revisioner räknas mot butikens totala lagringsanvändning. Om lagringskvoten överskrids kan du inte längre skapa eller ändra nyckelvärden eller funktionsflaggor.
• 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.

Se metodtips för klientprogram i App Configuration

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 lagringsperiod om du ofta behöver återskapa ett lager med samma namn. Arbetsflöden som kräver att en lagringsplats återskapas med samma namn bör tillåta att det går en timme mellan att rensa bort en konfigurationslagringsplats och att skapa den igen. 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.

Använd aktivitetsloggar för att se vem som har använt eller ändrat kontrollpanelen i din konfigurationstjänst för appar. Använd Resursloggar för att identifiera vem som använde dataplanet.

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 skapa en anpassad hanteringsportal eller hantera dem programmatiskt i din CI/CD-miljö. 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.

Att utvärdera och konsumera funktionsflaggor i din applikation kräver App Configuration-leverantören och funktionshanteringsbibliotek, som finns tillgängliga för .NET, Java Spring, Python, JavaScript och Go. Mer information finns i Översikt för funktionshantering.

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å dev kommer värdet på config.message att vara Hello from dev. När Spring-profilen är inställd på prod kommer värdet på config.message att vara Hello from prod.

Det här standardbeteendet kan åsidosättas genom att ange etikettfiltret i filen för programegenskaper. 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 inspektera HttpContext via singleton-IHttpContextAccessormönstret. 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