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
• Labelen
• Uitgebreide queries
• Batchgewijs 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 tijdens verzending en in rust. 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 specifiek implementatieslot. 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 functie kunt u snel een nieuwe App Configuration-store maken 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 naambeperkingen en abonnements- en servicelimieten voor een volledige lijst met limieten.

U bepaalt wie toegang heeft tot App Configuration op een niveau per winkel. Gebruik een aparte opslag voor elke omgeving waarvoor verschillende machtigingen vereist zijn. 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 vier prijscategorieën: Gratis, Developer, 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.

Hieronder vindt u aandachtspunten voor het kiezen van een niveau.

• Doel: De gratis laag is perfect voor het evalueren van de service in niet-productieomgevingen, zodat u de functies zonder kosten kunt verkennen.

  De developer-laag is kostenefficiënt voor gebruiksvoorbeelden met lage volumes en niet-productietoepassingen en wordt geleverd met functies en mogelijkheden die speciaal zijn afgestemd op ontwikkelings- en testbehoeften.

  De Standard-laag is ontworpen voor middelgrote productie- en niet-productiegebruiksscenario's 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 belastingen.

• Resources per abonnement: een resource bestaat uit één configuratiearchief. Elk abonnement is beperkt tot drie configuratiewinkels per regio in de Gratis-tier. Abonnementen kunnen een onbeperkt aantal configuratiearchieven hebben in de lagen Developer, Standard en Premium.

• Opslag per resource: In de gratis laag is elk configuratiearchief beperkt tot 10 MB aan normale opslag en 10 MB aan momentopnameopslag. In de developer-laag kan elk configuratiearchief maximaal 500 MB aan normale opslag en een extra 500 MB aan momentopnameopslag gebruiken. 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 lagen Gratis en Ontwikkelaars wordt deze geschiedenis zeven dagen opgeslagen. In de lagen Standard en Premium wordt deze geschiedenis 30 dagen opgeslagen.

• Aanvragenquotum: stores in de gratis laag hebben een limiet van 1.000 aanvragen per dag. Wanneer een winkel 1000 aanvragen bereikt, retourneert deze HTTP-statuscode 429 voor alle aanvragen tot middernacht UTC.

  Winkels in de ontwikkelaarslaag zijn beperkt tot 6.000 aanvragen per uur. Zodra het quotum per uur is uitgeput, retourneren aanvullende aanvragen een HTTP-statuscode 429, die te veel aanvragen aangeeft, tot het einde van het uur.

  Stores in de Standard-laag zijn beperkt tot maximaal 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.

  Stores in de Premium-laag hebben geen limiet voor het aantal aanvragen, waardoor de toegang tot de store nooit wordt geblokkeerd.

• Doorvoer: App Configuration-opslagruimten in alle lagen hebben een doorvoerlimiet. Aanvragen die deze vergoeding overschrijden, ontvangen een HTTP-statuscode 429-antwoord.

  Stores in de Free-laag en de Developer-laag hebben geen gegarandeerde doorvoercapaciteit.

  Stores in de Standard-laag ondersteunen een doorvoersnelheid† van maximaal 300 aanvragen per seconde (RPS) voor leesaanvragen en maximaal 60 RPS voor schrijdaanvragen.

  Stores in de Premium-laag ondersteunen een verwerkingssnelheid† tot 450 RPS voor leesverzoeken en tot 100 RPS voor schrijfverzoeken.

  †De verwerkingssnelheid wordt doorgaans gemeten als het gemiddelde aantal aanvragen dat een App Configuration-store zonder snelheidsbeperking verwerkt over een bepaalde periode.

• Service level agreement: de gratis laag en de developer-laag hebben 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 developer-laag bevat ook ondersteuning voor Private Link.

  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: Het gebruik van een store in de gratis laag is gratis.

  Developer-laagstores brengen dagelijkse gebruikskosten met zich mee, inclusief de eerste 3.000 aanvragen per dag. Voor aanvragen buiten deze dagelijkse toewijzing worden overschrijdingskosten in rekening gebracht.

  Voor stores in de Standard-laag worden dagelijks gebruikskosten in rekening gebracht, inclusief 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 origin-server en de eerste 800.000 aanvragen voor de replica-server per dag zijn inbegrepen in het dagelijkse tarief. Aanvragen die deze dagelijkse toewijzing overschrijden, brengen overschrijdingskosten in rekening.

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

U kunt een App Configuration-archief downgraden van de Premium-laag naar de Standard-laag, omdat beide lagen zijn ontworpen voor productiegebruik. Downgraden naar een niet-productielaag, zoals de gratis laag, wordt echter niet ondersteund. Hiervoor kunt u een nieuw archief maken in de gewenste laag en vervolgens configuratiegegevens importeren in dat archief.

Voordat u een App Configuration-archief van de Premium-laag naar de Standard-laag downgradet, moet u ervoor zorgen dat uw gebruik van normale opslag en momentopnameopslag onder de limieten van de Standard-laag ligt. U kunt uw huidige gebruik controleren via de metrische gegevens van Azure Monitor, het dagelijkse opslaggebruik en de opslaggrootte voor momentopnamen van uw App Configuration-archief in Azure Portal.

Klantgegevens die zijn opgeslagen in App Configuration bevinden zich in de regio waar de App Configuration-opslag van de klant is aangemaakt. 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 Azure-regio's met ondersteuning voor beschikbaarheidszones voor meer informatie.

App Configuration-stores hebben verschillende aanvraagquota, afhankelijk van hun laag. Winkels in de gratis laag zijn beperkt tot 1.000 aanvragen per dag, winkels in de Developer-laag tot 6.000 aanvragen per uur, 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-stores hebben een doorvoercapaciteit op basis van hun serviceniveau. Free tier- en Developer tier-stores hebben geen gegarandeerde doorvoersnelheid. Stores in de Standard-laag ondersteunen een verwerkingssnelheid van maximaal 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 aanvragen voor de sentinel-sleutel vaak voorkomen en meestal ongewijzigd blijven, de meeste ervan niet worden meegerekend bij de uurquotalimieten† voor een opslag in de Standard-laag.

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.

Tot slot brengen we alles samen. Aangenomen dat u de sentinel-sleutel binnen een uur twee keer hebt bijgewerkt, ontvangt uw App Configuration-store in dat uur dus in totaal 7.000 aanvragen (=6.000+500x2). Houd er rekening mee dat van deze aanvragen er slechts ongeveer 1.000 (=500x2) gebruikmaken van het beschikbare uurlimiet voor een store in de Standard-laag. 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.

*Functievlagmen gebruiken de sentinel-sleutel niet voor het bewaken van wijzigingen en worden afzonderlijk van de configuratie bewaakt. Het duurt één aanvraag om elke 100 functievlagmen per vernieuwingsinterval te controleren.

† 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.
• Overschrijding van het aanvraagquotum per uur voor een winkel in het Developer-niveau.
• Overschrijding van het quotum voor aanvragen per uur voor een winkel in het Standard-niveau.
• 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-opslag in Azure Monitor en waarschuwingen instellen voor de metriek Aanvraagquotumgebruik.

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 aanbieders, voeren ze automatisch nieuwe pogingen uit bij reacties met HTTP-statuscode 429 en andere tijdelijke fouten.
• Voeg herhalingslogica toe aan aangepaste clients als u geen App Configuration-providers 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.
• Beperk de retentie van revisies van sleutelwaarden als u frequente sleutelwaarde-updates uitvoert en u hoeft geen revisies te bewaren voor de maximale duur die is toegestaan door uw App Configuration-archief. Revisies tellen mee voor het totale opslaggebruik van uw winkel. Als het opslagquotum wordt overschreden, kunt u geen sleutelwaarden of functievlagmen meer maken of wijzigen.
• 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.

Bekijk de aanbevolen procedures voor clienttoepassingen in App Configuration

Alle App Configuration-stores in de Standard- en Premium-lagen hebben de functie soft-delete automatisch ingeschakeld. Wanneer een App Configuration-store van de Standard- of Premium-laag wordt verwijderd, wordt de naam gereserveerd voor de bewaarperiode. Als u een winkel met dezelfde naam opnieuw wilt aanmaken voordat de bewaartermijn verloopt, moet u eerst de soft-verwijderde winkel definitief verwijderen, mits voor de winkel geen beveiliging tegen definitief verwijderen is 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 resources voor 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-stores in de Standard- en Premium-lagen ondersteunen de soft-delete-functie, 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.

Gebruik activiteitenlogboeken om te zien wie de beheerlaag van uw App Configuration-opslag heeft geopend of gewijzigd. Gebruik resourcelogboeken om te bepalen wie toegang heeft tot het gegevensvlak.

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.

Het evalueren en consumeren van feature-flags in je applicatie vereist de App Configuration provider en feature management-bibliotheken, die beschikbaar zijn voor .NET, Java Spring, Python, JavaScript en Go. Zie Overzicht van functiebeheer 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.

Bijvoorbeeld maakt u met profielen dev en prod overeenkomstig sleutelwaardeparen aan met de volgende labels.

Wanneer het Spring-profiel is ingesteld op dev, is de waarde van config.messageHello from dev. Wanneer het Spring-profiel is ingesteld op prod, is de waarde van config.messageHello from prod.

Dit standaardgedrag kan worden overschreven door het labelfilter in te stellen in het eigenschappenbestand van uw toepassing. 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 gebruiken, zoals ',${spring.profiles.active}', waarmee alle sleutels zonder label en de sleutels die overeenkomen met uw Spring-profielen worden geselecteerd. 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 gedaan door het HttpContext via het singleton-IHttpContextAccessorpatroon te inspecteren. Dit patroon werkt echter niet voor Blazor-servertoepassingen waarbij in plaats daarvan scoped services moeten worden gebruikt. In dit geval moet de AddScopedFeatureManagement-methode worden gebruikt.

Abonneer u op onze GitHub-aankondigingsopslagplaats.

U kunt ons rechtstreeks op GitHub bereiken.

• Over Azure App Configuration