best practices voor Azure-app configuratie

  • Artikel

In dit artikel worden veelvoorkomende patronen en aanbevolen procedures besproken wanneer u Azure-app Configuratie gebruikt.

Sleutelgroeperingen

App Configuration biedt twee opties voor het ordenen van sleutels:

  • Sleutelvoorvoegsels
  • Etiketten

U kunt een of beide opties gebruiken om uw sleutels te groeperen.

Sleutelvoorvoegsels zijn de beginonderdelen van sleutels. U kunt een set sleutels logisch groeperen met hetzelfde voorvoegsel in hun namen. Voorvoegsels kunnen meerdere onderdelen bevatten die zijn verbonden met een scheidingsteken, zoals , vergelijkbaar /met een URL-pad, om een naamruimte te vormen. Dergelijke hiërarchieën zijn handig wanneer u sleutels opslaat voor veel toepassingen en microservices in één App Configuration-archief.

Een belangrijk punt om rekening mee te houden is dat sleutels zijn waarnaar uw toepassingscode verwijst om de waarden van de bijbehorende instellingen op te halen. Sleutels mogen niet worden gewijzigd, anders moet u uw code telkens wijzigen wanneer dat gebeurt.

Labels zijn een kenmerk voor sleutels. Ze worden gebruikt om varianten van een sleutel te maken. U kunt bijvoorbeeld labels toewijzen aan meerdere versies van een sleutel. Een versie kan een iteratie, een omgeving of andere contextuele informatie zijn. Uw toepassing kan een volledig andere set sleutelwaarden aanvragen door een ander label op te geven. Als gevolg hiervan blijven alle sleutelverwijzingen ongewijzigd in uw code.

Sleutel-waardesamenstellingen

App Configuration behandelt alle sleutels die ermee zijn opgeslagen als onafhankelijke entiteiten. App Configuration probeert geen relatie tussen sleutels af te stellen of sleutelwaarden over te nemen op basis van hun hiërarchie. U kunt echter meerdere sets sleutels aggregeren door labels te gebruiken in combinatie met de juiste configuratiestacking in uw toepassingscode.

We kijken naar een voorbeeld. Stel dat u een instelling met de naam Asset1 hebt, waarvan de waarde kan variëren op basis van de ontwikkelomgeving. U maakt een sleutel met de naam Asset1 met een leeg label en een label met de naam 'Ontwikkeling'. In het eerste label plaatst u de standaardwaarde voor Asset1 en plaatst u een specifieke waarde voor 'Ontwikkeling' in de laatste.

In uw code haalt u eerst de sleutelwaarden op zonder labels en vervolgens haalt u dezelfde set sleutelwaarden een tweede keer op met het label Ontwikkeling. Wanneer u de waarden de tweede keer ophaalt, worden de vorige waarden van de sleutels overschreven. Met het .NET-configuratiesysteem kunt u meerdere sets configuratiegegevens op elkaar stapelen. Als een sleutel in meer dan één set bestaat, wordt de laatste set gebruikt die deze bevat. Met een modern programmeerframework, zoals .NET, krijgt u deze stacking-mogelijkheid gratis als u een systeemeigen configuratieprovider gebruikt voor toegang tot App Configuration. In het volgende codefragment ziet u hoe u stacking in een .NET-toepassing kunt implementeren:

// Augment the ConfigurationBuilder with Azure App Configuration
// Pull the connection string from an environment variable
configBuilder.AddAzureAppConfiguration(options => {
    options.Connect(configuration["connection_string"])
           .Select(KeyFilter.Any, LabelFilter.Null)
           .Select(KeyFilter.Any, "Development");
});

Labels gebruiken om verschillende configuraties voor verschillende omgevingen in te schakelen, biedt een volledig voorbeeld.

Verwijzingen naar externe gegevens

App Configuration is ontworpen om configuratiegegevens op te slaan die u normaal gesproken opslaat in configuratiebestanden of omgevingsvariabelen. Sommige typen gegevens zijn echter mogelijk beter geschikt om zich in andere bronnen te bevinden. Sla bijvoorbeeld geheimen op in Key Vault, bestanden in Azure Storage, lidmaatschapsgegevens in Microsoft Entra-groepen of klantlijsten in een database.

U kunt nog steeds profiteren van App Configuration door een verwijzing naar externe gegevens op te slaan in een sleutelwaarde. U kunt inhoudstype gebruiken om elke gegevensbron te onderscheiden. Wanneer uw toepassing een verwijzing leest, worden de werkelijke gegevens uit de bron waarnaar wordt verwezen geladen, ervan uitgaande dat deze over de benodigde machtiging voor de bron beschikt. Als u de locatie van uw externe gegevens wijzigt, hoeft u de verwijzing alleen bij te werken in App Configuration in plaats van uw hele toepassing bij te werken en opnieuw te implementeren.

De referentiefunctie voor App Configuration Key Vault is een voorbeeld in dit geval. Hiermee kunnen de geheimen die vereist zijn voor een toepassing zo nodig worden bijgewerkt, terwijl de onderliggende geheimen zelf in Key Vault blijven.

Bootstrap voor App Configuration

Voor toegang tot een App Configuration-archief kunt u de bijbehorende verbindingsreeks gebruiken. Deze is beschikbaar in Azure Portal. Omdat verbindingsreeks referentiegegevens bevatten, worden ze beschouwd als geheimen. Deze geheimen moeten worden opgeslagen in Azure Key Vault en uw code moet worden geverifieerd bij Key Vault om ze op te halen.

Een betere optie is het gebruik van de functie beheerde identiteiten in Microsoft Entra ID. Met beheerde identiteiten hebt u alleen de URL van het App Configuration-eindpunt nodig om de toegang tot uw App Configuration-archief te bootstrapen. U kunt de URL insluiten in uw toepassingscode (bijvoorbeeld in het bestand appsettings.json ). Zie Beheerde identiteiten gebruiken voor toegang tot App Configuration voor meer informatie.

Azure Kubernetes Service-toegang tot App Configuration

De volgende opties zijn beschikbaar voor workloads die worden gehost in Azure Kubernetes Service (AKS) voor toegang tot Azure-app-configuratie. Deze opties zijn ook van toepassing op Kubernetes in het algemeen.

  • Voeg Azure-app Kubernetes-provider voor configuratie toe aan uw AKS-cluster. De Kubernetes-provider wordt uitgevoerd als een pod in het cluster. Het kan configuratie Kaarten en geheimen maken op basis van sleutelwaarden en Key Vault-verwijzingen in uw App Configuration-archief. De ConfigMap en Secret kunnen worden gebruikt als omgevingsvariabelen of gekoppelde bestanden zonder dat er wijzigingen in uw toepassingscode nodig zijn. Als u meerdere toepassingen in hetzelfde AKS-cluster uitvoert, hebben ze allemaal toegang tot de gegenereerde configuratie Kaarten en geheimen, waardoor afzonderlijke aanvragen voor App Configuration niet meer nodig zijn. De Kubernetes-provider ondersteunt ook dynamische configuratie-updates. Dit is de aanbevolen optie indien haalbaar voor u.

  • Werk uw toepassing bij om Azure-app configuratieproviderbibliotheken te gebruiken. De providerbibliotheken zijn beschikbaar in veel frameworks en talen, zoals ASP.NET, .NET, Java Spring, JavaScript/Node.js en Python. Deze benadering biedt u volledige toegang tot de functionaliteiten van App Configuration, waaronder dynamisch configuratie- en functiebeheer. U hebt gedetailleerde controle over welke gegevens u wilt laden en van welk App Configuration-archief voor elke toepassing.

  • Integreren met Kubernetes-implementatie met behulp van Helm. Als u uw toepassing niet wilt bijwerken of een nieuwe pod wilt toevoegen aan uw AKS-cluster, hebt u de mogelijkheid om gegevens van App Configuration naar uw Kubernetes-cluster te brengen met behulp van Helm via implementatie. Met deze methode kan uw toepassing toegang blijven krijgen tot de configuratie vanuit Kubernetes-variabelen en -geheimen. U kunt helm-upgrade uitvoeren wanneer u wilt dat uw toepassing nieuwe configuratiewijzigingen bevat.

App Service- of Azure Functions-toegang tot App Configuration

Gebruik de App Configuration-provider of SDK-bibliotheken om rechtstreeks in uw toepassing toegang te krijgen tot App Configuration. Deze benadering biedt u volledige toegang tot de functionaliteiten van App Configuration, waaronder dynamisch configuratie- en functiebeheer. Uw toepassing die wordt uitgevoerd op App Service of Azure Functions, kan toegang krijgen tot uw App Configuration-archief via een van de volgende methoden:

U kunt uw App Configuration-gegevens ook toegankelijk maken voor uw toepassing als toepassingsinstellingen of omgevingsvariabelen. Met deze methode kunt u voorkomen dat u de toepassingscode wijzigt.

Aanvragen voor App Configuration verminderen

Overmatige aanvragen voor App Configuration kunnen leiden tot bandbreedtebeperking of overschrijdingskosten. Het aantal aanvragen beperken:

  • Verhoog de time-out voor vernieuwen, met name als uw configuratiewaarden niet regelmatig veranderen. Geef een nieuwe time-out voor vernieuwen op met behulp van de SetCacheExpiration methode.

  • Bekijk één sentinel-sleutel in plaats van afzonderlijke sleutels te bekijken. Vernieuw alle configuratie alleen als de sentinel-sleutel wordt gewijzigd. Zie Dynamische configuratie gebruiken in een ASP.NET Core-app voor een voorbeeld.

  • Gebruik Azure Event Grid om meldingen te ontvangen wanneer de configuratie verandert, in plaats van voortdurend te peilen naar wijzigingen. Zie Event Grid gebruiken voor wijzigingsmeldingen voor App Configuration-gegevens voor meer informatie.

  • Schakel geo-replicatie van uw App Configuration-archief in en verspreid uw aanvragen over meerdere replica's. Gebruik bijvoorbeeld een andere replica dan elke geografische regio voor een wereldwijd geïmplementeerde toepassing. Elke App Configuration-replica heeft het afzonderlijke aanvraagquotum. Deze installatie biedt u een model voor schaalbaarheid en verbeterde tolerantie tegen tijdelijke en regionale storingen.

Configuratiegegevens importeren in App Configuration

App Configuration biedt de mogelijkheid om uw configuratie-instellingen bulksgewijs te importeren uit uw huidige configuratiebestanden met behulp van Azure Portal of CLI. U kunt ook dezelfde opties gebruiken om sleutelwaarden uit App Configuration te exporteren, bijvoorbeeld tussen gerelateerde winkels. Als u een doorlopende synchronisatie wilt instellen met uw opslagplaats in GitHub of Azure DevOps, kunt u onze GitHub Action - of Azure Pipeline-pushtaak gebruiken, zodat u uw bestaande procedures voor broncodebeheer kunt blijven gebruiken terwijl u de voordelen van App Configuration krijgt.

Implementatie met meerdere regio's in App Configuration

Als uw toepassing in meerdere regio's is geïmplementeerd, raden we u aan geo-replicatie van uw App Configuration-archief in te schakelen. U kunt uw toepassing voornamelijk verbinding laten maken met de replica die overeenkomt met de regio waar exemplaren van uw toepassing worden geïmplementeerd en toestaan dat er een failover naar replica's in andere regio's wordt uitgevoerd. Met deze installatie wordt de latentie tussen uw toepassing en App Configuration geminimaliseerd, wordt de belasting verdeeld, omdat elke replica afzonderlijke beperkingsquota heeft en de tolerantie van uw toepassing verbetert tegen tijdelijke en regionale storingen. Zie Tolerantie en herstel na noodgevallen voor meer informatie.

Toepassingen bouwen met hoge tolerantie

Toepassingen zijn vaak afhankelijk van de configuratie om te beginnen, waardoor Azure-app configuratie essentieel is voor hoge beschikbaarheid. Voor verbeterde tolerantie moeten toepassingen gebruikmaken van de betrouwbaarheidsfuncties van App Configuration en overwegen de volgende maatregelen te nemen op basis van uw specifieke vereisten.

  • Inrichten in regio's met ondersteuning voor azure-beschikbaarheidszones. Met beschikbaarheidszones kunnen toepassingen bestand zijn tegen storingen in datacenters. App Configuration biedt zoneredundantie voor alle klanten zonder extra kosten. Het maken van uw App Configuration-archief in regio's met ondersteuning voor beschikbaarheidszones wordt aanbevolen. U vindt een lijst met regio's waarvoor ondersteuning voor de beschikbaarheidszone door App Configuration is ingeschakeld.
  • Schakel geo-replicatie in en laat uw toepassing failover uitvoeren tussen replica's. Deze installatie biedt u een model voor schaalbaarheid en verbeterde tolerantie tegen tijdelijke storingen en regionale storingen. Zie Tolerantie en herstel na noodgevallen voor meer informatie.
  • Implementeer configuratie met veilige implementatieprocedures. Onjuiste of onbedoelde configuratiewijzigingen kunnen vaak uitvaltijd van toepassingen veroorzaken. U moet voorkomen dat u configuratiewijzigingen aanbrengt die rechtstreeks van invloed zijn op de productie vanuit azure Portal, bijvoorbeeld wanneer dat mogelijk is. In veilige implementatieprocedures (SDP) gebruikt u een progressief implementatiemodel voor blootstelling om de potentiële straal van door de implementatie veroorzaakte problemen te minimaliseren. Als u SDP gebruikt, kunt u een momentopname van een configuratie bouwen en testen voordat u deze implementeert in productie. Tijdens de implementatie kunt u exemplaren van uw toepassing bijwerken om de nieuwe momentopname geleidelijk op te halen. Als er problemen worden gedetecteerd, kunt u de wijziging terugdraaien door de laatst bekende goede momentopname (LKG) opnieuw te implementeren. De momentopname is onveranderbaar en garandeert consistentie in alle implementaties. U kunt momentopnamen samen met dynamische configuratie gebruiken. Gebruik een momentopname voor uw basisconfiguratie en dynamische configuratie voor onderdrukkingen en functievlagmen voor noodgevallen.
  • Neem de configuratie op met uw toepassing. Als u ervoor wilt zorgen dat uw toepassing altijd toegang heeft tot een kopie van de configuratie, of als u liever een runtime-afhankelijkheid van App Configuration vermijdt, kunt u de configuratie ophalen uit App Configuration tijdens de build- of releasetijd en deze opnemen in uw toepassing. Bekijk voor meer informatie voorbeelden van het integreren van App Configuration met uw CI/CD-pijplijn of Kubernetes-implementatie.
  • App Configuration-providers gebruiken. Toepassingen spelen een belangrijke rol bij het bereiken van hoge tolerantie, omdat ze rekening kunnen houden met problemen die zich voordoen tijdens hun runtime, zoals netwerkproblemen, en sneller kunnen reageren op fouten. De App Configuration-providers bieden een reeks ingebouwde tolerantiefuncties, waaronder automatische replicadetectie, replicafailover, opstartherhalingen met aanpasbare time-outs, configuratiecaching en adaptieve strategieën voor betrouwbare configuratievernieuwing. Het wordt ten zeerste aanbevolen om App Configuration-providers te gebruiken om te profiteren van deze functies. Als dit geen optie is, moet u overwegen vergelijkbare functies in uw aangepaste oplossing te implementeren om het hoogste tolerantieniveau te bereiken.

Clienttoepassingen in App Configuration

Wanneer u App Configuration gebruikt in clienttoepassingen, moet u rekening houden met twee belangrijke factoren. Als u eerst de verbindingsreeks in een clienttoepassing gebruikt, riskeert u dat de toegangssleutel van uw App Configuration-archief openbaar wordt gemaakt voor het publiek. Ten tweede kan de typische schaal van een clienttoepassing overmatige aanvragen voor uw App Configuration-archief veroorzaken, wat kan leiden tot overschrijdingskosten of beperking. Zie de veelgestelde vragen voor meer informatie over beperking.

Om deze problemen op te lossen, raden we u aan een proxyservice te gebruiken tussen uw clienttoepassingen en uw App Configuration-archief. De proxyservice kan veilig worden geverifieerd met uw App Configuration-archief zonder dat er beveiligingsprobleem is met het lekken van verificatiegegevens. U kunt een proxyservice bouwen met behulp van een van de App Configuration-providerbibliotheken, zodat u kunt profiteren van ingebouwde caching- en vernieuwingsmogelijkheden voor het optimaliseren van het aantal aanvragen dat naar App Configuration wordt verzonden. Zie de artikelen in quickstarts en zelfstudies voor meer informatie over het gebruik van App Configuration-providers. De proxyservice dient de configuratie van de cache naar uw clienttoepassingen en u voorkomt de twee mogelijke problemen die in deze sectie worden besproken.

Multitenant-toepassingen in App Configuration

Een multitenant-toepassing is gebouwd op een architectuur waarin een gedeeld exemplaar van uw toepassing meerdere klanten of tenants bedient. U hebt bijvoorbeeld een e-mailservice die uw gebruikers afzonderlijke accounts en aangepaste ervaringen biedt. Uw toepassing beheert meestal verschillende configuraties voor elke tenant. Hier volgen enkele architecturale overwegingen voor het gebruik van App Configuration in een multitenant-toepassing.

Configuratie als code

Configuratie als code is een praktijk van het beheren van configuratiebestanden onder uw broncodebeheersysteem, bijvoorbeeld een Git-opslagplaats. Het biedt u voordelen, zoals traceerbaarheid en goedkeuringsproces voor eventuele configuratiewijzigingen. Als u configuratie als code gebruikt, beschikt App Configuration over hulpprogramma's om u te helpen bij het beheren van uw configuratiegegevens in bestanden en het implementeren ervan als onderdeel van uw build-, release- of CI/CD-proces. Op deze manier hebben uw toepassingen toegang tot de meest recente gegevens uit uw App Configuration-archief(en).

  • Voor GitHub kunt u de GitHub-actie app-configuratiesynchronisatie inschakelen voor uw opslagplaats. Wijzigingen in configuratiebestanden worden automatisch gesynchroniseerd met App Configuration wanneer een pull-aanvraag wordt samengevoegd.
  • Voor Azure DevOps kunt u de Azure-app Configuratiepush, een Azure-pijplijntaak, opnemen in uw build- of release-pijplijnen voor gegevenssynchronisatie.
  • U kunt ook configuratiebestanden importeren in App Configuration met behulp van Azure CLI als onderdeel van uw CI/CD-systeem. Zie az appconfig kv import voor meer informatie.

Met dit model kunt u validatie- en teststappen opnemen voordat u gegevens doorvoert in App Configuration. Als u meerdere App Configuration-archieven gebruikt, kunt u de configuratiegegevens ook incrementeel of allemaal tegelijk naar deze opslag pushen.

Volgende stappen