Veelgestelde vragen over Azure-app configuratie

Met App Configuration kunnen ontwikkelaars toepassingsinstellingen beheren en de beschikbaarheid van functies beheren. Het is erop gericht om veel van de taken van het werken met complexe configuratiegegevens te vereenvoudigen.

App Configuration ondersteunt:

• Hiërarchische naamruimten
• Labels
• Uitgebreide query's
• Bulksgewijs ophalen
• Gespecialiseerde beheerbewerkingen
• Een gebruikersinterface voor functiebeheer

App Configuration vormt een aanvulling op Key Vault en de twee moeten naast elkaar worden gebruikt in de meeste toepassingsimplementaties.

Hoewel App Configuration beveiliging biedt, is Key Vault nog steeds de beste plek voor het opslaan van toepassingsgeheimen. Key Vault biedt versleuteling op hardwareniveau, gedetailleerd toegangsbeleid en beheerbewerkingen zoals certificaatrotatie.

U kunt sleutelwaarden voor App Configuration maken die verwijzen naar geheimen die zijn opgeslagen in Key Vault. Zie Key Vault-verwijzingen gebruiken in een ASP.NET Core-app voor meer informatie.

Ja. App Configuration versleutelt altijd alle gegevens die worden verzonden en at-rest. Alle netwerkcommunicatie verloopt via TLS 1.2 of TLS 1.3. App Configuration ondersteunt versleuteling-at-rest met door Microsoft beheerde sleutels of door de klant beheerde sleutels.

Azure-app Service kunt u app-instellingen definiëren voor elk App Service-exemplaar. Deze instellingen worden doorgegeven als omgevingsvariabelen aan de toepassingscode. U kunt desgewenst een instelling koppelen aan een specifieke implementatiesite. Zie App-instellingen configureren voor meer informatie.

Met Azure-app Configuration kunt u daarentegen instellingen definiëren die kunnen worden gedeeld tussen meerdere apps. Dit omvat apps die worden uitgevoerd in App Service, evenals andere platforms. Uw toepassingscode heeft toegang tot deze instellingen via de configuratieproviders voor .NET en Java, via de Azure SDK of rechtstreeks via REST API's.

U kunt verwijzingen toevoegen naar uw App Configuration-gegevens in de toepassingsinstellingen van uw App Service. U kunt ook instellingen importeren en exporteren tussen App Service en App Configuration. Met deze mogelijkheid kunt u snel een nieuw App Configuration-archief instellen op basis van bestaande App Service-instellingen. U kunt ook configuratie delen met een bestaande app die afhankelijk is van App Service-instellingen.

Er geldt een limiet van 10 kB voor één sleutelwaarde, waaronder kenmerken zoals label, inhoudstype, tags en andere metagegevens. Er is geen limiet voor het aantal sleutels en labels, zolang de totale grootte lager is dan de opslaglimiet.

Deze sleutelwaardelimiet moet voldoende zijn voor één instelling in de meeste toepassingen. Als u merkt dat uw instelling groter is dan deze limiet, kunt u overwegen uw gegevens ergens anders op te slaan en een verwijzing naar die gegevens toe te voegen in App Configuration.

Zie Azure-abonnements- en servicelimieten voor een volledige lijst met limieten.

U bepaalt wie toegang heeft tot App Configuration op een niveau per winkel. Gebruik een afzonderlijk archief voor elke omgeving waarvoor verschillende machtigingen zijn vereist. Deze benadering biedt de beste beveiligingsisolatie.

Als u geen beveiligingsisolatie tussen omgevingen nodig hebt, kunt u labels gebruiken om onderscheid te maken tussen configuratiewaarden. Labels gebruiken om verschillende configuraties voor verschillende omgevingen in te schakelen, biedt een volledig voorbeeld.

Bekijk best practices.

Er zijn drie prijscategorieën: Gratis, Standard en Premium. Raadpleeg de pagina met prijzen van App Configuration voor gedetailleerde informatie over prijzen .

Alle App Configuration-lagen bieden kernfunctionaliteit, waaronder configuratie-instellingen, functievlagmen, Key Vault-verwijzingen, configuratiemomentopnamen, basisbeheerbewerkingen, metrische gegevens en logboeken.

Hier volgen overwegingen voor het kiezen van een laag.

• Doel: De gratis laag is perfect voor het evalueren van de service in niet-productieomgevingen, zodat u de functies zonder kosten kunt verkennen. De Standard-laag is afgestemd op gebruiksscenario's voor middelgrote volumes en biedt een balans tussen prestaties en kostenefficiëntie. Voor productiebehoeften op hoog volume- of bedrijfsniveau biedt de Premium-laag het hoogste niveau van prestaties en schaalbaarheid, zodat uw toepassingen soepel worden uitgevoerd, zelfs onder zware belasting.

• Resources per abonnement: een resource bestaat uit één configuratiearchief. Elk abonnement is beperkt tot één configuratiearchief per regio in de gratis laag. Abonnementen kunnen een onbeperkt aantal configuratiearchieven hebben in de Standard- en Premium-lagen.

• Opslag per resource: In de gratis laag is elk configuratiearchief beperkt tot 10 MB aan normale opslag en 10 MB aan momentopnameopslag. In de Standard-laag kan elk configuratiearchief maximaal 1 GB aan normale opslag en nog eens 1 GB aan momentopnameopslag gebruiken. In de Premium-laag kan elk configuratiearchief maximaal 4 GB aan normale opslag en nog eens 4 GB aan momentopnameopslag gebruiken.

• Revisiegeschiedenis: App Configuration slaat een geschiedenis op van alle wijzigingen die zijn aangebracht in sleutels. In de gratis laag wordt deze geschiedenis zeven dagen opgeslagen. In de lagen Standard en Premium wordt deze geschiedenis 30 dagen opgeslagen.

• Quotum aanvragen: winkels in de gratis laag zijn beperkt tot 1000 aanvragen per dag. Wanneer een winkel 1000 aanvragen bereikt, retourneert deze HTTP-statuscode 429 voor alle aanvragen tot middernacht UTC.

  Winkels in de Standard-laag zijn beperkt tot 30.000 aanvragen per uur. Zodra het quotum per uur is uitgeput, kunnen extra aanvragen een HTTP-statuscode 429 retourneren, wat te veel aanvragen aangeeft, tot het einde van het uur. Naarmate er meer aanvragen worden verzonden die boven het quotum liggen, kan een hoger percentage van deze aanvragen statuscode 429 retourneren.

  Opslag in Premium-lagen heeft geen quotumlimiet voor aanvragen, zodat de toegang tot de store nooit wordt geblokkeerd.

• Doorvoer: App Configuration-archieven in alle lagen hebben een doorvoervergoeding. Aanvragen die deze vergoeding overschrijden, ontvangen een HTTP-statuscode 429-antwoord. Winkels in de gratis laag hebben geen gegarandeerde doorvoer.

  Winkels in de Standard-laag staan de uitvoeringssnelheid toe† maximaal 300 aanvragen per seconde (RPS) voor leesaanvragen en maximaal 60 RPS voor schrijfaanvragen.

  Winkels in de Premium-laag staan de uitvoeringssnelheid toe† maximaal 450 RPS voor leesaanvragen en maximaal 100 RPS voor schrijfaanvragen.

  †De uitvoeringssnelheid wordt doorgaans gemeten als het gemiddelde aantal aanvragen dat wordt verwerkt door een App Configuration-archief zonder beperking gedurende een opgegeven periode.

• Service level agreement: De gratis laag heeft geen SLA. De Standard-laag heeft een SLA van 99,9% beschikbaarheid en 99,95% beschikbaarheid met geo-replicatie ingeschakeld. De Premium-laag heeft een SLA van 99,9% beschikbaarheid en 99,99% beschikbaarheid met geo-replicatie ingeschakeld.

• Functies: Alle lagen omvatten functies, waaronder versleuteling met door Microsoft beheerde sleutels, verificatie via toegangssleutel of Microsoft Entra-id, op rollen gebaseerd toegangsbeheer van Azure (RBAC), beheerde identiteit, servicetags en redundantie van beschikbaarheidszones. De Standard- en Premium-lagen bieden meer functionaliteiten, waaronder Private Link-ondersteuning, versleuteling met door de klant beheerde sleutels, beveiliging tegen voorlopig verwijderen en mogelijkheden voor geo-replicatie.

• Kosten: Er zijn geen kosten verbonden aan het gebruik van een gratis opslaglaag.

  Winkels in de Standard-laag hebben een dagelijkse gebruikskosten, waaronder de eerste 200.000 aanvragen per dag. Voor aanvragen buiten deze dagelijkse toewijzing worden overschrijdingskosten in rekening gebracht.

  Premium-opslaglagen hebben ook kosten voor dagelijks gebruik en bevatten een replica. De eerste 800.000 aanvragen voor de oorsprong en de eerste 800.000 aanvragen voor de replica worden elke dag opgenomen in de dagelijkse kosten. Aanvragen die deze dagelijkse toewijzing overschrijden, brengen overschrijdingskosten in rekening.

U kunt een App Configuration-archief op elk gewenst moment upgraden, bijvoorbeeld van de gratis laag naar de Standard- of Premium-laag, of van de Standard-laag naar de Premium-laag.

U kunt een App Configuration-archief niet downgraden, bijvoorbeeld van de Premium-laag naar de Standard-laag, of van de Standard-laag naar de gratis laag. U kunt echter een nieuw archief maken in de gewenste laag en vervolgens configuratiegegevens importeren in dat archief.

Klantgegevens die zijn opgeslagen in App Configuration, bevinden zich in de regio waar het App Configuration-archief van de klant is gemaakt. Klantgegevens worden alleen gerepliceerd naar een andere regio als de klant geo-replicatie voor die regio inschakelt. Dit geldt voor alle beschikbare regio's. Klanten kunnen hun gegevens verplaatsen, kopiëren of openen vanaf elke locatie wereldwijd.

Azure-app Configuration ondersteunt geo-replicatie voor verbeterde tolerantie voor regionale storingen.

Azure-app Configuration ondersteunt Azure-beschikbaarheidszones om uw toepassing en gegevens te beschermen tegen storingen in één datacenter. Alle regio's voor beschikbaarheidszones bestaan uit minimaal drie beschikbaarheidszones, waarbij elk een fysiek onafhankelijk datacenter is. Voor tolerantie is deze ondersteuning in App Configuration zonder extra kosten ingeschakeld voor alle klanten. Hier volgen regio's waarvoor ondersteuning voor de beschikbaarheidszone is ingeschakeld in App Configuration. Zie Regio's die beschikbaarheidszones ondersteunen in Azure voor meer informatie

Hieronder ziet u regio's waar ondersteuning voor de beschikbaarheidszone is ingeschakeld voor App Configuration.

App Configuration-archieven hebben verschillende aanvraagquota op basis van hun laag. Winkels in de gratis laag zijn beperkt tot 1.000 aanvragen per dag, winkels in de Standard-laag tot 30.000 aanvragen per uur en winkels in Premium-lagen hebben geen aanvraaglimieten, waardoor ononderbroken toegang wordt gegarandeerd.

App Configuration-archieven hebben doorvoervergoedingen op basis van hun laag. Winkels in de gratis laag hebben geen gegarandeerde doorvoer. Standard-laag stores bieden ondersteuning voor uitvoeringssnelheid tot 300 aanvragen per seconde (RPS) voor leesbewerkingen en maximaal 60 RPS voor schrijfbewerkingen. Premium Tier Stores bieden ondersteuning voor uitvoeringssnelheid tot 450 RPS voor leesbewerkingen en maximaal 100 RPS voor schrijfbewerkingen.

Laten we een voorbeeld nemen en ervan uitgaan dat u een toepassing hebt met 1000 configuratie-instellingen. Bij het opstarten worden al deze instellingen vanuit App Configuration geladen. Daarna wordt elke 30 seconden gecontroleerd op een sentinel-sleutel voor configuratiewijzigingen. Of u nu op Kubernetes, App Service of VM's werkt, laten we aannemen dat er 50 exemplaren van uw toepassing tegelijk worden uitgevoerd.

Laten we eerst een schatting maken van de aanvragen voor configuratiebewaking. Elk exemplaar van uw toepassing verzendt elke 30 seconden één aanvraag voor de sentinel-sleutel naar App Configuration, zodat er binnen een uur 120 aanvragen (=3600/30) worden verzonden. Aangezien u 50 exemplaren van uw toepassing hebt, verzendt uw toepassing elk uur 6.000 (=120x50) totale aanvragen voor configuratiebewaking. Houd er rekening mee dat omdat de sentinel-sleutelaanvragen regelmatig en meestal ongewijzigd zijn, het merendeel ervan niet telt tegen de quotumlimieten per uur† voor een Standard-laagarchief.

Ten tweede gaan we een schatting maken van de aanvragen voor het laden/opnieuw laden van de configuratie. Uw toepassing laadt alle instellingen bij het opstarten of wanneer een sentinel-sleutelwijziging wordt gedetecteerd. Elke aanvraag voor App Configuration kan maximaal 100 sleutelwaarden ophalen, dus het duurt 10 (=1000/100) aanvragen om alle instellingen te laden. Aangezien u 50 toepassingsexemplaren hebt, verzendt u 500 (=10x50) totale aanvragen wanneer uw toepassing opnieuw wordt opgestart of de configuratie opnieuw laadt.

Ten slotte gaan we het samenbrengen. Ervan uitgaande dat u de sentinel-sleutel twee keer binnen een uur hebt bijgewerkt, ontvangt uw App Configuration-archief dus 7.000 (=6.000+500x2) voor dat uur. Houd er rekening mee dat uit deze aanvragen slechts ongeveer 1.000 (=500x2) aanvragen het beschikbare quotum per uur gebruiken voor een Standard-laagarchief. Werk de getallen in dit voorbeeld bij zodat deze overeenkomen met uw specifieke installatie en ontwerp, zodat u voldoende buffer hebt ten opzichte van de quotumlimiet per uur.

† Winkels in de gratis laag hebben geen frequente, herhaalde aanvragen die zijn uitgesloten van hun dagelijkse limiet.

Uw toepassing ontvangt mogelijk een HTTP-statuscode 429-antwoord onder de volgende omstandigheden:

• Het dagelijkse aanvraagquotum voor een winkel in de gratis laag overschrijden.
• Het quotum voor aanvragen per uur voor een winkel in de Standard-laag overschrijdt.
• Het overschrijden van de doorvoerlimiet voor een winkel in een willekeurige laag.
• De bandbreedtelimiet voor een winkel in een willekeurige laag overschrijden.
• Er wordt geprobeerd een sleutelwaarde te maken of te wijzigen wanneer het opslagquotum wordt overschreden.

Controleer de hoofdtekst van het 429-antwoord op de specifieke reden waarom de aanvraag is mislukt. U kunt ook logboeken verzamelen voor uw App Configuration-archief in Azure Monitor en waarschuwingen instellen voor de metrische gegevens over quotumgebruik aanvragen.

Het ontvangen van tijdelijke HTTP-statuscode 429-antwoorden veroorzaakt meestal geen kwaad, omdat App Configuration-clients deze probleemloos verwerken. Als uw toepassing echter regelmatig HTTP-statuscode 429-antwoorden ondervindt, kunt u de volgende opties overwegen:

• Upgrade uw winkel naar de Premium-laag: deze laag heeft geen quotumlimiet voor aanvragen en heeft een hoger opslagquotum en een hogere doorvoerlimiet.
• App Configuration-providers gebruiken: de providers hebben ingebouwde mogelijkheden voor opnieuw proberen en opslaan in cache, samen met vele andere tolerantiefuncties. Zorg ervoor dat u bijwerkt naar de nieuwste versie van de provider voor alle nieuwste verbeteringen.
• Gebruik App Configuration SDK's als uw toepassing schrijfaanvragen moet verzenden. Hoewel de SDK's mogelijk niet zo uitgebreid zijn als providers, proberen ze automatisch opnieuw op HTTP-statuscode 429-antwoorden en andere tijdelijke fouten.
• Neem logica voor opnieuw proberen op in aangepaste clients als u geen app-configuratieproviders of SDK's kunt gebruiken. De retry-after-ms header in het antwoord biedt een voorgestelde wachttijd (in milliseconden) voordat u de aanvraag opnieuw probeert.
• Aanvragen distribueren over meerdere clientexemplaren: dit helpt de maximale doorvoer te bereiken vanuit uw App Configuration-archief.
• Verminder aanvragen voor App Configuration: volg de richtlijnen om het aantal aanvragen te minimaliseren.
• Verbeter de tolerantie van uw toepassing: overweeg om geo-replicatie te integreren om failover en taakverdeling toe te staan. Controleer de aanbevolen procedures voor het bouwen van uiterst flexibele toepassingen.

Alle App Configuration-archieven in de Standard- en Premium-lagen hebben automatisch de functie voor voorlopig verwijderen ingeschakeld. Wanneer een App Configuration-archief in de Standard- of Premium-laag wordt verwijderd, wordt de naam ervan gereserveerd voor de bewaarperiode. Als u een winkel opnieuw wilt maken met dezelfde naam voordat de bewaarperiode verloopt, moet u eerst de voorlopig verwijderde winkel leegmaken, mits de opslag geen beveiliging tegen opschonen heeft ingeschakeld. Als de beveiliging tegen opschonen is ingeschakeld, moet u wachten tot de bewaarperiode is verstreken. Gebruik de functie opschonen of stel een kortere bewaarperiode in als u vaak een winkel met dezelfde naam opnieuw moet maken. Werkstromen waarvoor het opnieuw maken van een archief met dezelfde naam is vereist, moeten een uur duren tussen het opschonen van een configuratiearchief en het uitvoeren van de volgende create. Deze aanbeveling is aanwezig omdat zodra een opschoning is aangevraagd, de werkelijke opschoonbewerking van de resources van het configuratiearchief asynchroon wordt uitgevoerd, waardoor een beetje extra tijd nodig is om te voltooien. Om te voorkomen dat u hoeft te wachten, worden werkstromen die tijdelijke configuratiearchieven maken aanbevolen om unieke namen te gebruiken.

Alle App Configuration-archieven in de Standard- en Premium-lagen ondersteunen de functie voor voorlopig verwijderen , die niet kan worden uitgeschakeld. U kunt een verwijderd archief binnen de bewaarperiode herstellen. Volg deze instructies om een per ongeluk verwijderd App Configuration-archief te herstellen.

Ja. Hoewel u functievlagmen en Key Vault-verwijzingen in App Configuration kunt beheren via Azure Portal of CLI, kunt u ze ook programmatisch maken en bijwerken met behulp van App Configuration SDK's. Daarom kunt u uw aangepaste beheerportal schrijven of beheren in uw CI/CD programmatisch. De functievlag en Key Vault-referentie-API's zijn beschikbaar in SDK's van alle ondersteunde talen. Bekijk de voorbeeldkoppelingen voor voorbeelden in elke ondersteunde taal.

Voor het evalueren en gebruiken van functievlagmen in uw toepassing zijn de App Configuration-provider en functiebeheerbibliotheken vereist, die beschikbaar zijn in .NET en Java Spring. Bekijk de sectie Functiebeheer onder Quickstarts en zelfstudies voor meer informatie.

Spring-profielen bieden een manier om onderdelen van uw toepassing te scheiden, inclusief configuratie, en deze alleen beschikbaar te maken in bepaalde omgevingen of wanneer specifieke bibliotheken worden gebruikt.

U wordt aangeraden het label van uw sleutelwaarden in te stellen zodat deze overeenkomen met uw Spring-profielen. De Bibliotheek van de App Configuration Spring-provider laadt standaard de sleutelwaarden met de labels die overeenkomen met de huidige actieve Spring-profiel(en) (${spring.profiles.active}) als het labelfilter niet expliciet is ingesteld. Als er geen actieve Spring-profielset is ingesteld, worden sleutelwaarden zonder label geladen.

Met profielen dev en prodmaakt u bijvoorbeeld sleutelwaarden dienovereenkomstig met de volgende labels.

Wanneer het Spring-profiel is ingesteld op dev, is Hello from devde waarde van config.message . Wanneer het Spring-profiel is ingesteld op prod, is Hello from prodde waarde van config.message .

Dit standaardgedrag kan worden overschreven door het labelfilter in te stellen in uw bootstrap-bestand. De Spring-providerbibliotheek laadt sleutelwaarden met de opgegeven labels, ongeacht het actieve Spring-profiel.

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

Als u andere labels en uw Spring-profiel(en) wilt selecteren, kunt u een labelfilter zoals ',${spring.profiles.active}', waarmee alle sleutels worden geselecteerd zonder een label en de sleutels die overeenkomen met uw Spring-profielen. De meest rechtse labels hebben prioriteit wanneer dubbele sleutels worden gevonden.

Vanaf versie 3.1.0 kunt u met de Microsoft.FeatureManagement bibliotheek functiesbeheerservices uitvoeren, waaronder functiefilters, als scoped services in .NET-toepassingen op basis van afhankelijkheidsinjectie. Als u van deze functie gebruik wilt maken, kunt u de AddFeatureManagement aanroep in uw code gewoon vervangen door AddScopedFeatureManagement, zoals wordt weergegeven in het volgende codefragment:

services.AddScopedFeatureManagement();

Functiefilters kunnen een functievlag evalueren op basis van de eigenschappen van een HTTP-aanvraag. Dit wordt meestal uitgevoerd door het HttpContext door het singleton-patroon IHttpContextAccessor te inspecteren. Dit patroon werkt echter niet voor Blazor-servertoepassingen waarbij in plaats daarvan scoped services moeten worden gebruikt. In dit geval AddScopedFeatureManagement moet de methode worden gebruikt.

Abonneer u op onze GitHub-aankondigingsopslagplaats.

U kunt ons rechtstreeks op GitHub bereiken.

• Over Azure-app configuratie