Häufig gestellte Fragen zu Azure App Configuration

App Configuration hilft Entwicklern dabei, Anwendungseinstellungen zu verwalten und die Verfügbarkeit von Funktionen zu steuern. Es zielt darauf ab, viele der Aufgaben, aus denen die Arbeit mit komplexen Konfigurationsdaten besteht, zu vereinfachen.

App Configuration unterstützt Folgendes:

• Hierarchische Namespaces
• Bezeichnungen
• Umfangreiche Abfragen
• Batchabruf
• Spezielle Verwaltungsvorgänge
• Eine Benutzeroberfläche zur Featureverwaltung

App Configuration ergänzt Key Vault, und die beiden sollten in den meisten Anwendungsbereitstellungen nebeneinander verwendet werden.

App Configuration bietet zwar verstärkte Sicherheit, aber Key Vault ist weiterhin der beste Ort zum Speichern von Anwendungsgeheimnissen. Key Vault bietet Verschlüsselung auf Hardwareebene, granulare Zugriffsrichtlinien und Verwaltungsvorgänge wie die Zertifikatsrotation.

Sie können App Configuration-Schlüsselwerte erstellen, die auf in Key Vault gespeicherte Geheimnisse verweisen. Weitere Informationen finden Sie unter Verwenden von Key Vault-Verweisen in einer ASP.NET Core-App.

Ja. App Configuration verschlüsselt immer alle Daten während der Übertragung und alle ruhenden Daten. Die gesamte Netzwerkkommunikation erfolgt über TLS 1.2 oder TLS 1.3. App Configuration unterstützt die Verschlüsselung ruhender Daten mit von Microsoft verwalteten Schlüsseln oder mit kundenseitig verwalteten Schlüsseln.

Azure App Service gestattet es Ihnen, App-Einstellungen für jede App Service-Instanz zu definieren. Diese Einstellungen werden als Umgebungsvariablen an den Anwendungscode übergeben. Wenn gewünscht, können Sie einem bestimmten Bereitstellungsslot eine Einstellung zuordnen. Weitere Informationen finden Sie unter Konfigurieren von App-Einstellungen.

Im Gegensatz dazu gestattet Ihnen Azure App Configuration das Definieren von Einstellungen, die von mehreren Apps gemeinsam genutzt werden können. Dies gilt auch für Apps, die sowohl in App Service als auch auf anderen Plattformen ausgeführt werden. Ihr Anwendungscode greift über die Konfigurationsanbieter für .NET und Java, über das Azure SDK oder direkt über REST-APIs auf diese Einstellungen zu.

Sie können in den Anwendungseinstellungen Ihrer App Service-Instanz Verweise auf Ihre App Configuration-Daten hinzufügen. Sie können Einstellungen auch zwischen App Service und App Configuration importieren und exportieren. Diese Funktion ermöglicht Ihnen, schnell einen neuen App Configuration-Speicher auf Basis vorhandener App Service-Einstellungen einzurichten. Sie können die Konfiguration auch für eine vorhandene App freigeben, die auf App Service-Einstellungen basiert.

Für ein einzelnes Schlüssel-Wert-Element, einschließlich Attributen wie Bezeichnung, Inhaltstyp, Tags und weiteren Metadaten, gilt eine Beschränkung von 10 KB.

Dieser Grenzwert sollte für eine einzelne Einstellung in den meisten Anwendungen ausreichen. Wenn Sie feststellen, dass Ihre Einstellung diesen Grenzwert überschreitet, können Sie Ihre Daten ggf. an anderer Stelle speichern und in App Configuration einen Verweis auf diese Daten hinzufügen.

Weitere Informationen finden Sie unter Einschränkungen für Azure-Abonnements und Dienste, Kontingente und Einschränkungen.

Sie kontrollieren auf Speicherebene (also pro Speicher), wer Zugriff auf App Configuration hat. Verwenden Sie für jede Umgebung, die andere Berechtigungen erfordert, einen separaten Speicher. Dieser Ansatz bietet Ihnen die beste Sicherheitsisolierung.

Wenn Sie keine Sicherheitsisolation zwischen Umgebungen benötigen, können Sie Bezeichnungen verwenden, um zwischen Konfigurationswerten zu unterscheiden. Unter Verwenden von Bezeichnungen zum Aktivieren verschiedener Konfigurationen für verschiedene Umgebungen finden Sie ein vollständiges Beispiel.

Siehe unter Bewährte Methoden.

Es gibt zwei Tarife:

• Free-Tarif
• Standard-Tarif

Wenn Sie vor der Einführung des Standard-Tarifs einen Speicher erstellt haben, wird er bei allgemeiner Verfügbarkeit automatisch in den Free-Tarif verschoben. Sie können ein Upgrade auf den Standard-Tarif durchführen, oder im Free-Tarif verbleiben.

Ein Downgrade vom Standard-Tarif in den Free-Tarif ist nicht möglich. Sie können einen neuen Speicher im Free-Tarif erstellen und dann Konfigurationsdaten in diesen Speicher importieren.

Beide App Configuration-Ebenen bieten Kernfunktionen inklusive Konfigurationseinstellungen, Featureflags, Key Vault-Verweise, Konfigurationsmomentaufnahmen, grundlegende Verwaltungsvorgänge, Metriken und Protokolle.

Nachfolgend sind verschiedene Aspekte aufgeführt, die Ihnen bei der Auswahl eines Tarifs helfen können.

• Ressourcen pro Abonnement: Eine Ressource besteht aus einem einzelnen Konfigurationsspeicher. Jedes Abonnement ist auf einen Konfigurationsspeicher pro Region in der Free-Ebene beschränkt. Abonnements können über eine unbegrenzte Anzahl von Konfigurationsspeichern im Standard-Tarif verfügen.

• Speicher pro Ressource: In der Free-Ebene ist jeder Konfigurationsspeicher auf 10 MB regulären Speicher und 10 MB Momentaufnahmespeicher begrenzt. In der Standardebene kann jeder Konfigurationsspeicher bis zu 1 GB regulären Speicher und einen zusätzlichen 1 GB Momentaufnahmespeicher verwenden.

• Revisionsverlauf: App Configuration speichert den Verlauf aller an den Schlüsseln vorgenommenen Änderungen. Im Free-Tarif wird dieser Verlauf sieben Tage lang gespeichert. Im Standard-Tarif wird dieser Verlauf 30 Tage lang gespeichert.

• Anforderungskontingent: Speicher im Free-Tarif sind auf 1.000 Anforderungen pro Tag beschränkt. Wenn ein Speicher 1.000 Anforderungen erreicht, wird bis Mitternacht (UTC) für alle Anforderungen der HTTP-Statuscode 429 zurückgegeben.

  Speicher im Standard-Tarif sind auf 30.000 Anforderungen pro Stunde beschränkt. Nach Ausschöpfen des stündlichen Kontingents können Anforderungen den HTTP-Statuscode 429, der zu viele Anforderungen anzeigt, bis zum Ende der Stunde zurückgeben. Wenn mehr Anforderungen gesendet werden, die über dem Kontingent liegen, kann ein höherer Prozentsatz von ihnen den Statuscode 429 zurückgeben.

• Vereinbarung zum Servicelevel: Die Standardebene hat ein SLA von 99,9 % Verfügbarkeit und 99,95 % Verfügbarkeit mit aktivierter Georeplikation. Für den Free-Tarif gibt es keine SLA.

• Features: Beide Ebenen umfassen Funktionen, einschließlich Verschlüsselung mit von Microsoft verwalteten Schlüsseln, Authentifizierung über Zugriffsschlüssel oder Microsoft Entra ID, rollenbasierte Zugriffssteuerung (RBAC) in Azure, verwaltete Identität, Diensttags und Verfügbarkeitszonenredundanz. Die Standardebene bietet weitere Funktionen, einschließlich Unterstützung für Private Link, Verschlüsselung mit kundenseitig verwalteten Schlüsseln, Schutz vor vorläufigem Löschen und Georeplikationsfunktionen.

• Kosten: Für Speicher im Standard-Tarif fällt eine tägliche Nutzungsgebühr an. Die ersten 200.000 Anforderungen täglich sind in der täglichen Gebühr enthalten. Es gibt auch eine Überschreitungsgebühr für Anforderungen, die über die tägliche Zuordnung hinausgehen. Es fallen keine Kosten für die Nutzung eines Speichers im Free-Tarif an.

Ein Upgrade vom Free-Tarif in den Standard-Tarif ist jederzeit möglich.

Ein Downgrade vom Standard-Tarif in den Free-Tarif ist nicht möglich. Sie können einen neuen Speicher im Free-Tarif erstellen und dann Konfigurationsdaten in diesen Speicher importieren.

In App Configuration gespeicherte Kundendaten befinden sich in der Region, in der der App Configuration-Speicher des Kunden erstellt wurde. Kundendaten werden nur in eine andere Region repliziert, wenn der Kunde Georeplikation für diese Region aktiviert. Dies gilt für alle verfügbaren Regionen. Kunden können ihre Daten von jedem Standort weltweit verschieben, kopieren oder darauf zugreifen.

Azure App Configuration unterstützt Georeplikation für erhöhte Resilienz gegenüber regionalen Ausfällen.

Azure App Configuration unterstützt Azure-Verfügbarkeitszonen, um Ihre Anwendung und Ihre Daten vor Ausfällen einzelner Rechenzentren zu schützen. Alle Regionen, für die Verfügbarkeitszonen aktiviert sind, bestehen aus mindestens drei Verfügbarkeitszonen, wobei jede ein physisch unabhängiges Rechenzentrum ist. Mit Blick auf Resilienz wird diese Unterstützung in App Configuration für alle Kunden ohne zusätzliche Kosten aktiviert. Im Folgenden finden Sie Regionen, für die App Configuration Verfügbarkeitszonenunterstützung aktiviert hat. Weitere Informationen finden Sie unter Regionen und Verfügbarkeitszonen in Azure.

Im Folgenden finden Sie Regionen, in denen für App Configuration die Unterstützung von Verfügbarkeitszonen aktiviert ist.

Konfigurationsspeicher im Free-Tarif sind auf 1.000 Anforderungen pro Tag beschränkt. Für Konfigurationsspeicher im Standard-Tarif kann eine temporäre Drosselung auftreten, wenn die Anforderungsrate 30.000 Anforderungen pro Stunde überschreitet.

Wenn ein Speicher seinen Grenzwert im Standard-Tarif erreicht, gibt er möglicherweise bis zum Ende der Stunde den HTTP-Statuscode 429 für einige gestellte Anforderungen zurück. Der retry-after-ms-Header in der Antwort gibt eine vorgeschlagene Wartezeit (in Millisekunden) vor der Wiederholung der Anforderung an.

Wenn Ihre Anwendung regelmäßig Antworten mit dem HTTP-Statuscode 429 erhält, sollten Sie sie so umgestalten, dass die Anzahl der vorgenommenen Anforderungen verringert wird. Weitere Informationen finden Sie unter Verringern der Anzahl der Anforderungen an App Configuration.

Unter den folgenden Umständen erhalten Sie eine Antwort mit dem HTTP-Statuscode 429:

• Überschreiten des täglichen Anforderungslimits für einen Speicher im Free-Tarif.
• Überschreiten des stündlichen Anforderungslimits für einen Speicher in der Standardebene
• Vorübergehende Drosselung aufgrund zahlreicher Anforderungen†
• Kurzzeitige Drosselung aufgrund übermäßiger Bandbreitennutzung†.
• Versuch, einen Schlüssel zu erstellen oder zu ändern, wenn das Speicherkontingent überschritten wird

Überprüfen Sie den Text der 429-Antwort, um den genauen Grund zu ermitteln, warum die Anforderung fehlgeschlagen ist.

†Ein Konfigurationsspeicher kann vorübergehende Drosselung erfahren, wenn er einen großen Burst von Anforderungen empfängt oder eine übermäßige Datenmenge überträgt. Für App Configuration-Clients, etwa das Azure SDK, Konfigurationsanbieterbibliotheken und Azure Pipeline-Aufgaben, werden bei gedrosselten Anforderungen automatisch Wiederholungsversuche durchgeführt. Bei allen Anwendungen, die einen dieser Clients oder einen benutzerdefinierten Client nutzen, der bei gedrosselten Anfragen eine Wiederholung durchführt, sollte diese vorübergehende Drosselung unbemerkt bleiben.

Nehmen wir als Beispiel an, dass Sie über eine Anwendung mit 1.000 Konfigurationseinstellungen verfügen. Ihre Anwendung lädt alle diese Einstellungen beim Start aus App Configuration. Danach wird alle 30 Sekunden ein Sentinel-Schlüssel auf Konfigurationsänderungen überprüft. Unabhängig davon, ob Sie auf Kubernetes, App Service oder VMs ausführen, nehmen wir an, dass 50 Instanzen Ihrer Anwendung gleichzeitig ausgeführt werden.

Zunächst schätzen wir die Anforderungen für die Konfigurationsüberwachung. Jede Instanz Ihrer Anwendung sendet alle 30 Sekunden eine Anforderung für den Sentinel-Schlüssel an App Configuration, sodass 120 (=3600/30) Anforderungen in einer Stunde gesendet werden. Wenn Sie über 50 Instanzen Ihrer Anwendung verfügen, sendet Ihre Anwendung stündlich insgesamt 6.000 (=120x50) Anforderungen für die Konfigurationsüberwachung. Beachten Sie, dass die überwiegende Mehrheit der Sentinel-Schlüsselanforderungen, da sie häufig und größtenteils unverändert sind, nicht auf die Grenzwerte für stündliche Speicherkontingente angerechnet werden.

Als Zweitens schätzen wir die Anforderungen für das Laden/erneute Laden von Konfigurationen. Ihre Anwendung lädt alle Einstellungen beim Start oder immer dann, wenn eine Sentinel-Schlüsseländerung erkannt wird. Jede Anforderung an App Configuration kann bis zu 100 Schlüssel-Wert-Paare abrufen, sodass 10 (=1000/100) Anforderungen erforderlich sind, um alle Einstellungen zu laden. Wenn Sie über 50 Anwendungsinstanzen verfügen, senden Sie insgesamt 500 (=10x50) Anforderungen, wenn Ihre Anwendung neu gestartet wird, oder sie ihre Konfiguration neu lädt.

Zum Schluss fügen wir es zusammen. Wenn Sie den Sentinel-Schlüssel zweimal innerhalb einer Stunde aktualisiert haben, empfängt Ihr App Configuration-Speicher somit insgesamt 7.000 (=6.000+500x2) Anforderungen für diese Stunde. Beachten Sie, dass von diesen Anforderungen nur etwa 1.000 Anforderungen (=500x2) das verfügbare Stundenkontingent verwenden. Aktualisieren Sie die Zahlen in diesem Beispiel entsprechend Ihrem spezifischen Setup und Entwurf, damit Sie über einen ausreichenden Puffer zum Grenzwert für die stündliche Drosselung verfügen. Weitere Informationen finden Sie unter Verringern der Anzahl der Anforderungen an App Configuration.

†Speicher mit Free-Tarif verfügen nicht über häufige, wiederholte Anforderungen, die von ihrem täglichen Grenzwert ausgeschlossen sind.

Für alle App Configuration-Speicher im Standard-Tarif ist das Feature für das vorläufige Löschen (soft-delete) automatisch aktiviert. Wenn ein App Configuration-Speicher im Standard-Tarif gelöscht wird, bleibt sein Name für den Aufbewahrungszeitraum reserviert. Um einen Speicher mit demselben Namen vor Ablauf des Aufbewahrungszeitraums neu zu erstellen, müssen Sie zuerst den vorläufig gelöschten Speicher bereinigen, sofern für den Speicher kein Bereinigungsschutz aktiviert ist. Wenn der Bereinigungsschutz aktiviert ist, müssen Sie warten, bis der Aufbewahrungszeitraum abgelaufen ist. Verwenden Sie die Bereinigungsfunktion, oder legen Sie einen kürzeren Aufbewahrungszeitraum fest, wenn Sie einen Speicher mit demselben Namen häufig neu erstellen müssen. Bei Workflows, die die Neuerstellung eines Speichers mit demselben Namen erfordern, sollte eine Stunde zwischen dem Bereinigen eines Konfigurationsspeichers und dem anschließenden Erstellungsvorgang vergehen. Diese Empfehlung wurde ausgesprochen, da nach Anforderung einer Bereinigung die eigentliche Bereinigung der Ressourcen im Konfigurationsspeicher asynchron erfolgt und daher etwas mehr Zeit bis zum Abschluss benötigt wird. Um Wartezeiten zu vermeiden, wird empfohlen, dass Workflows, bei denen kurzlebige Konfigurationsspeicher erstellt werden, eindeutige Namen erhalten.

Alle App Configuration-Speicher im Standard-Tarif unterstützen das Feature vorläufiges Löschen (soft-delete), das nicht deaktiviert werden kann. Sie können einen gelöschten Speicher während des Aufbewahrungszeitraums wiederherstellen. Befolgen Sie diese Anweisungen, um einen fälschlicherweise gelöschten App Configuration-Speicher wiederherzustellen.

Ja. Sie können Featurekennzeichen und Key Vault-Verweise in App Configuration über das Azure-Portal oder die CLI verwalten, können sie aber auch programmgesteuert mithilfe von App Configuration SDKs erstellen und aktualisieren. Daher können Sie Ihr angepasstes Verwaltungsportal schreiben oder diese Elemente programmgesteuert in Ihrer CI/CD-Pipeline verwalten. Die APIs für Featurekennzeichen und Key Vault-Verweise sind in SDKs aller unterstützten Sprachen verfügbar. Unter den Beispiellinks finden Sie Beispiele in jeder unterstützten Sprache.

Das Auswerten und Verwenden von Featurekennzeichen in Ihrer Anwendung erfordert den App Configuration-Anbieter und die Featureverwaltungsbibliotheken, die in .NET und Java Spring verfügbar sind. Weitere Informationen finden Sie unter Schnellstarts und Tutorials im Abschnitt Featureverwaltung.

Spring-Profile bieten eine Möglichkeit, Teile Ihrer Anwendung, einschließlich der Konfiguration, zu trennen und sie nur in bestimmten Umgebungen oder bei Verwendung bestimmter Bibliotheken verfügbar zu machen.

Es wird empfohlen, die Bezeichnungen Ihrer Schlüssel-Wert-Paare so festzulegen, dass sie Ihren Spring-Profilen entsprechen. Standardmäßig lädt die App Configuration Spring-Anbieterbibliothek die Schlüsselwerte mit den Bezeichnungen, die den aktuellen aktiven Spring-Profilen (${spring.profiles.active}) entsprechen, wenn der Bezeichnungsfilter nicht explizit festgelegt ist. Wenn kein aktives Spring-Profil festgelegt ist, werden Schlüssel-Wert-Paare mit „no label“ (keine Bezeichnung) geladen.

Bei den Profilen dev und prod erstellen Sie z. B. entsprechende Schlüsselwerte mit den folgenden Bezeichnungen.

Wenn das Spring-Profil auf dev festgelegt ist, ist der Wert von config.messageHello from dev. Wenn das Spring-Profil auf prod festgelegt ist, ist der Wert von config.messageHello from prod.

Dieses Standardverhalten kann außer Kraft gesetzt werden, indem Sie den Bezeichnungsfilter in Ihrer Bootstrapdatei festlegen. Die Spring-Anbieterbibliothek lädt Schlüsselwerte mit den angegebenen Bezeichnungen, unabhängig vom aktiven Spring-Profil.

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

Um andere Bezeichnungen und Ihre Spring-Profile auszuwählen, können Sie einen Bezeichnungsfilter wie ',${spring.profiles.active}' verwenden, wodurch alle Schlüssel ohne eine Bezeichnung und diejenigen ausgewählt werden, die Ihren Spring-Profilen entsprechen. Die Bezeichnungen ganz rechts haben Priorität, wenn doppelte Schlüssel gefunden werden.

Ab Version 3.1.0 ermöglicht die Microsoft.FeatureManagement-Bibliothek das Ausführen von Featureverwaltungsdiensten (einschließlich Featurefiltern) als bereichsbezogene Dienste in auf Abhängigkeitsinjektionen basierenden .NET-Anwendungen. Um dieses Feature nutzen zu können, ersetzen Sie einfach den AddFeatureManagement-Aufruf in Ihrem Code durch AddScopedFeatureManagement, wie im folgenden Codeschnipsel gezeigt:

services.AddScopedFeatureManagement();

Featurefilter können ein Featureflag basierend auf den Eigenschaften einer HTTP-Anforderung auswerten. Dazu wird in der Regel der HttpContext über das Singleton-IHttpContextAccessor-Muster untersucht. Dieses Muster funktioniert jedoch nicht bei Blazor-Serveranwendungen, bei denen stattdessen bereichsbezogene Dienste verwendet werden sollten. In diesem Fall sollte die AddScopedFeatureManagement-Methode verwendet werden.

Abonnieren Sie das GitHub-Ankündigungsrepository.

Sie erreichen uns direkt auf GitHub.

• Informationen zu Azure App Configuration