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.

Deze limiet 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 meer informatie.

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 twee prijscategorieën:

• Gratis laag
• Standaardlaag

Als u vóór de introductie van de Standard-laag een winkel hebt gemaakt, wordt deze automatisch naar de gratis laag verplaatst na algemene beschikbaarheid. U kunt ervoor kiezen om een upgrade uit te voeren naar de Standard-laag of om in de gratis laag te blijven.

U kunt een winkel niet downgraden van de Standard-laag naar de gratis laag. U kunt een nieuwe winkel maken in de gratis laag en vervolgens configuratiegegevens importeren in dat archief.

Beide 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.

• 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-laag.

• 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.

• 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 standard-laag 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. Wanneer het quotum per uur is uitgeput, kunnen aanvragen HTTP-statuscode 429 retourneren die 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.

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

• Functies: Beide lagen omvatten functionaliteiten, 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-laag biedt meer functionaliteiten, waaronder Private Link-ondersteuning, versleuteling met door de klant beheerde sleutels, beveiliging tegen voorlopig verwijderen en mogelijkheden voor geo-replicatie.

• Kosten: Winkels in de Standard-laag hebben een dagelijkse gebruikskosten. De eerste 200.000 aanvragen per dag zijn inbegrepen in de dagelijkse kosten. Er zijn ook overschrijdingskosten voor aanvragen ouder dan de dagelijkse toewijzing. Er zijn geen kosten verbonden aan het gebruik van een winkel met een gratis laag.

U kunt op elk gewenst moment upgraden van de gratis laag naar de Standard-laag.

U kunt een winkel niet downgraden van de Standard-laag naar de gratis laag. U kunt een nieuwe winkel maken in de gratis 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 3 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.

Configuratiearchieven in de gratis laag zijn beperkt tot 1000 aanvragen per dag. Configuratiearchieven in de Standard-laag kunnen tijdelijke beperking ondervinden wanneer de aanvraagsnelheid groter is dan 30.000 aanvragen per uur.

Wanneer een winkel de limiet bereikt in de standard-laag, kan de HTTP-statuscode 429 worden geretourneerd voor sommige aanvragen die zijn gedaan tot het einde van het uur. De retry-after-ms header in het antwoord geeft een voorgestelde wachttijd (in milliseconden) voordat u de aanvraag opnieuw probeert.

Als uw toepassing regelmatig HTTP-statuscode 429-antwoorden ondervindt, kunt u overwegen deze opnieuw te ontwerpen om het aantal aanvragen te verminderen. Zie voor meer informatie hoe u aanvragen voor App Configuration vermindert.

U ontvangt een HTTP-statuscode 429-antwoord onder deze omstandigheden:

• Het overschrijden van de dagelijkse aanvraaglimiet voor een winkel in de gratis laag.
• Het overschrijden van de aanvraaglimiet per uur voor een winkel in de standard-laag.
• Tijdelijke beperking vanwege een grote burst van aanvragen†.
• Tijdelijke beperking vanwege overmatig bandbreedtegebruik†.
• Er wordt geprobeerd een sleutel 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.

†A-configuratiearchief kan tijdelijke beperking ondervinden als er een grote burst van aanvragen wordt ontvangen of een overmatige hoeveelheid gegevens wordt overgedragen. App Configuration-clients, zoals de Azure SDK, configuratieproviderbibliotheken en Azure Pipelines-taken, proberen automatisch opnieuw bij vertraagde aanvragen. Voor toepassingen die gebruikmaken van een van deze clients of een aangepaste client die nieuwe pogingen uitvoert voor beperkte aanvragen, moet deze tijdelijke beperking onopgemerkt worden, mocht dit gebeuren.

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 meetelt tegen de quotumlimieten per uur†.

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 bij deze aanvragen slechts ongeveer 1.000 (=500x2) aanvragen het beschikbare quotum per uur gebruiken. Werk de getallen in dit voorbeeld bij zodat deze overeenkomen met uw specifieke installatie en ontwerp, zodat u een voldoende buffer hebt ten opzichte van de beperkingslimiet per uur. Zie voor meer informatie hoe u aanvragen voor App Configuration vermindert.

†Vrije opslaglagen hebben geen frequente, herhaalde aanvragen die zijn uitgesloten van hun dagelijkse limiet.

Alle App Configuration-archieven in de standard-laag hebben automatisch de functie voor voorlopig verwijderen ingeschakeld. Wanneer een App Configuration-archief in de standard-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-laag 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 IHttpContextAccessorte 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