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.

Den här grä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.

Mer information finns i Azure-prenumerations - och tjänstbegränsningar.

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 två prisnivåer:

• Kostnadsfri nivå
• Standard-nivå

Om du skapade ett lager innan standardnivån introducerades flyttades den automatiskt till den kostnadsfria nivån vid allmän tillgänglighet. Du kan välja att uppgradera till standardnivån eller stanna kvar på den kostnadsfria nivån.

Du kan inte nedgradera en butik från standardnivån till den kostnadsfria nivån. Du kan skapa ett nytt lager på den kostnadsfria nivån och sedan importera konfigurationsdata till det lagret.

Båda appkonfigurationsnivåerna 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å.

• 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å standardnivån.

• Lagring per resurs: På den kostnadsfria nivån är varje konfigurationslager 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.

• 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å standardnivån 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 begäranden returnera 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.

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

• Funktioner: Båda nivåerna 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. Standardnivån erbjuder fler funktioner, inklusive Private Link-stöd, kryptering med kundhanterade nycklar, skydd mot mjuk borttagning och geo-replikering.

• Kostnad: Standardnivålager har en daglig användningsavgift. De första 200 000 förfrågningarna varje dag ingår i den dagliga avgiften. Det finns också en överförbrukningsavgift för begäranden efter den dagliga allokeringen. Det kostar ingenting att använda en butik på den kostnadsfria nivån.

Du kan när som helst uppgradera från den kostnadsfria nivån till standardnivån.

Du kan inte nedgradera en butik från standardnivån till den kostnadsfria nivån. Du kan skapa ett nytt lager på den kostnadsfria nivån 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 3 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 Regioner och Tillgänglighetszoner i Azure.

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

Konfigurationslager på den kostnadsfria nivån är begränsade till 1 000 begäranden per dag. Konfigurationslager på Standard-nivån kan uppleva tillfälliga begränsningar när begärandefrekvensen överskrider 30 000 begäranden per timme.

När ett arkiv når sin gräns på standardnivån kan det returnera HTTP-statuskod 429 för vissa begäranden som görs till slutet av timmen. Rubriken retry-after-ms i svaret ger en föreslagen väntetid (i millisekunder) innan begäran försök igen.

Om ditt program regelbundet får HTTP-statuskod 429-svar kan du överväga att göra om det för att minska antalet begäranden som görs. Mer information finns i hur du minskar antalet begäranden som görs i App Configuration.

Du får ett HTTP-statuskod 429-svar under dessa omständigheter:

• Överskrider gränsen för daglig begäran för ett lager på den kostnadsfria nivån.
• Överskrider gränsen för begäranden varje timme för ett lager på standardnivån.
• Tillfällig begränsning på grund av en stor mängd begäranden†.
• Tillfällig begränsning på grund av överdriven bandbreddsanvändning†.
• Försöker skapa eller ändra en nyckel när lagringskvoten överskrids.

Kontrollera brödtexten i 429-svaret av den specifika orsaken till att begäran misslyckades.

†En konfigurationslager kan uppleva tillfällig begränsning om den tar emot en stor mängd begäranden eller överför en överdriven mängd data. AppKonfigurationsklienter, till exempel Azure SDK, konfigurationsproviderbibliotek och Azure Pipelines-uppgifter, försöker automatiskt igen på begränsade begäranden. För program som använder någon av dessa klienter, eller en anpassad klient som försöker igen på begränsade begäranden, bör den här momentära begränsningen gå obemärkt förbi, om det skulle inträffa.

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 om 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 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. 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 begränsningsgränsen per timme. Mer information finns i hur du minskar antalet begäranden som görs i App Configuration.

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

Alla appkonfigurationslager på standardnivån har automatiskt aktiverat funktionen för mjuk borttagning . När ett appkonfigurationsarkiv på standardnivå 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å standardnivån 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-portalen 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