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. Es gibt keine Beschränkung für die Anzahl der Schlüssel und Bezeichnungen, solange ihre Gesamtgröße unter dem Speichergrenzwert liegt.

Dieser Grenzwert für Schlüsselwerte 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.

Eine vollständige Liste der Grenzwerte finden Sie unter Grenzwerte für Azure-Abonnements und -Dienste.

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 drei Tarife: Free, Standard und Premium. Ausführliche Preisinformationen finden Sie auf der Seite App Configuration – Preise.

Alle App Configuration-Tarife 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.

• Zweck: Der Free-Tarif eignet sich perfekt für die Bewertung des Diensts in Nicht-Produktionsumgebungen, sodass Sie alle Features kostenlos erkunden können. Der Standard-Tarif ist auf mittelgroße Anwendungsfälle in der Produktion zugeschnitten und bietet eine gute Balance zwischen Leistung und Kosteneffizienz. Für umfangreiche Produktionsanforderungen oder solche auf Unternehmensniveau bietet Premium-Tarif das höchste Maß an Leistung und Skalierbarkeit, und er stellt sicher, dass Ihre Anwendungen auch unter hoher Last reibungslos ausgeführt werden.

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

• Speicher pro Ressource: Im Free-Tarif ist jeder Konfigurationsspeicher auf 10 MB regulären Speicher und 10 MB Momentaufnahmespeicher begrenzt. Im Standard-Tarif kann jeder Konfigurationsspeicher bis zu 1 GB regulären Speicher und zusätzlich 1 GB Momentaufnahmespeicher verwenden. Im Premium-Tarif kann jeder Konfigurationsspeicher bis zu 4 GB regulären Speicher und zusätzlich 4 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. In den Tarifen Standard und Premium 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öpfung des stündlichen Kontingents wird bis zum Ende der Stunde für alle weiteren Anforderungen der HTTP-Statuscode 429 (zu viele Anforderungen) zurückgegeben. Wenn mehr Anforderungen gesendet werden, die über dem Kontingent liegen, kann ein höherer Prozentsatz von ihnen den Statuscode 429 zurückgeben.

  Speicher mit Premium-Tarif haben keine Kontingentbegrenzung für Anfragen, sodass der Zugang zum Speicher nie blockiert wird.

• Durchsatz: App-Konfigurationsspeicher weisen in allen Tarifen eine Durchsatz-Allowance auf. Anforderungen, die diese Grenzwerte überschreiten, erhalten eine Antwort mit dem HTTP-Statuscode 429. Speicher im Free-Tarif haben keinen garantierten Durchsatz.

  Speicher im Standard-Tarif ermöglichen eine Ausführungsrate† von bis zu 300 Anforderungen pro Sekunde (RPS) für Leseanforderungen und bis zu 60 RPS für Schreibanforderungen.

  Speicher im Premium-Tarif ermöglichen eine Ausführungsrate† von bis zu 450 RPS für Leseanforderungen und bis zu 100 RPS für Schreibanforderungen.

  † Die Ausführungsrate wird in der Regel als durchschnittliche Anzahl von Anforderungen gemessen, die von einem App Configuration-Speicher ohne Einschränkung über einen bestimmten Zeitraum verarbeitet werden.

• Vereinbarung zum Servicelevel: Der Free-Tarif bietet keine SLA. Der Standard-Tarif hat eine SLA von 99,9 % Verfügbarkeit und 99,95 % Verfügbarkeit mit aktivierter Georeplikation. Die Premium-Tarif verfügt über eine SLA von 99,9 % Verfügbarkeit und 99,99 % Verfügbarkeit mit aktivierter Georeplikation.

• Features: Alle Tarife bieten Funktionen wie 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. Der Standard- und Premium-Tarif bieten weitere Funktionen, einschließlich Unterstützung für Private Link, Verschlüsselung mit kundenseitig verwalteten Schlüsseln, Schutz vor vorläufigem Löschen und Georeplikation.

• Kosten: Es fallen keine Kosten für die Nutzung eines Speichers im Free-Tarif an.

  Für Speicher im Standard-Tarif fällt eine tägliche Gebühr an, in der die ersten 200.000 Anforderungen bereits enthalten sind. Anforderungen über diese tägliche Zuteilung hinaus kosten eine Überschreitungsgebühr.

  Für Speicher im Premium-Tarif fällt ebenfalls eine tägliche Nutzungsgebühr an, die außerdem ein Replikat umfassen. Die ersten 800.000 Anforderungen für den Ursprung und die ersten 800.000 Anforderungen für das Replikat pro Tag sind in der täglichen Gebühr enthalten. Anforderungen über diese tägliche Zuteilung hinaus kosten eine Überschreitungsgebühr.

Sie können einen App Configuration-Speicher jederzeit upgraden, z. B. vom Free-Tarif auf Standard oder Premium oder vom Standard-Tarif auf Premium.

Das Downgraden eines App Configuration-Speichers, z. B. vom Premium-Tarif auf Standard oder vom Standardtarif auf Free, ist nicht möglich. Sie können jedoch einen neuen Speicher im gewünschten 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 die 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 Azure-Regionen mit Unterstützung für Verfügbarkeitszonen.

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

App Configuration-Speicher weisen je nach Tarif unterschiedliche Anforderungskontingente auf. Speicher im Free-Tarif sind auf 1.000 Anforderungen pro Tag und im Standard-Tarif auf 30.000 Anforderungen pro Stunde beschränkt; Speicher im Premium-Tarif haben keine Anforderungsbeschränkungen, wodurch ein unterbrechungsfreier Zugriff gewährleistet ist.

App Configuration-Speicher haben entsprechend ihres Tarif Durchsatz-Allowances. Speicher im Free-Tarif haben keinen garantierten Durchsatz. Speicher im Standard-Tarif unterstützen eine Ausführungsrate von bis zu 300 Anforderungen pro Sekunde (RPS) für Lesevorgänge und bis zu 60 RPS für Schreibvorgänge. Speicher im Premium-Tarif unterstützen eine Ausführungsrate von bis zu 450 RPS für Lesevorgänge und bis zu 100 RPS für Schreibvorgänge.

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, wird davon ausgegangen, 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 Anforderungen (=3.600 / 30) 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† im Standard-Tarif 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 Anforderungen (=1.000 / 100) 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 (=500 × 2) das verfügbare Stundenkontingent für einen Speicher im Standard-Tarif verwenden. Aktualisieren Sie die Zahlen in diesem Beispiel entsprechend Ihrem spezifischen Setup und Entwurf, damit Sie über einen ausreichenden Puffer zur stündlichen Kontingentgrenze verfügen.

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

Unter den folgenden Umständen erhält Ihre Anwendung möglicherweise eine Antwort mit dem HTTP-Statuscode 429:

• Überschreiten des täglichen Anforderungskontingents für einen Speicher im Free-Tarif.
• Überschreiten des stündlichen Anforderungskontingents für einen Speicher im Standardtarif.
• Überschreiten der Durchsatz-Allowance für einen Speicher in jedem Tarif.
• Überschreiten der Bandbreiten-Allowance für einen Speicher in jedem Tarif.
• Versuch, einen Schlüsselwert 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. Sie können auch Protokolle für Ihren App Configuration-Speicher in Azure Monitor sammeln und Warnungen für die Metrik Anforderungskontingentbedarf einrichten.

Das Empfangen von vorübergehenden Antworten mit dem HTTP-Statuscode 429 verursacht in der Regel keinen Schaden, da App Configuration-Clients sie ordnungsgemäß behandeln. Wenn Ihre Anwendung jedoch regelmäßig Antworten mit dem HTTP-Statuscode 429 erhält, sollten Sie die folgenden Optionen in Betracht ziehen:

• Upgraden Sie Ihren Speicher auf den Premium-Tarif: In diesem Tarif gelten keine Kontingentgrenzen für Anforderungen, und er bietet ein höheres Speicherkontingent und einen höheren Durchsatz.
• Verwenden von App Configuration-Anbietern: Die Anbieter verfügen über integrierte Wiederholungs- und Zwischenspeicherungsfunktionen sowie viele andere Resilienzfeatures. Aktualisieren Sie auf die neueste Version des Anbieters, um von allen neuen Verbesserungen zu profitieren.
• Verwenden von App Configuration-SDKs, wenn Ihre Anwendung Schreibanforderungen senden muss. Obwohl die SDKs möglicherweise nicht so viele Funktionen bieten wie Anbieter, wiederholen sie den Vorgang bei Antworten mit dem HTTP-Statuscode 429 und anderen temporären Fehlern automatisch.
• Fügen Sie Wiederholungslogik in benutzerdefinierte Clients ein, wenn Sie keine App Configuration-Anbieter oder SDKs verwenden können. Der retry-after-ms-Header in der Antwort gibt eine vorgeschlagene Wartezeit (in Millisekunden) vor der Wiederholung der Anforderung an.
• Verteilen von Anforderungen über mehrere Clientinstanzen: Dadurch wird der maximale Durchsatz aus Ihrem App Configuration-Speicher erreicht.
• Reduzieren von Anforderungen an App Configuration: Befolgen Sie die Anleitungen, um die Anzahl der Anforderungen zu minimieren.
• Verbessern der Anwendungsresilienz: Erwägen Sie die Integration der Georeplikation, um Failover und Lastenausgleich zu ermöglichen. Sehen Sie sich auch die bewährten Methoden für das Erstellen von Anwendungen mit hoher Resilienz an.

Für alle App Configuration-Speicher im Standard- und Premium-Tarif ist das Feature für das vorläufige Löschen automatisch aktiviert. Wenn ein App Configuration-Speicher im Standard- oder Premium-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- oder Premium-Tarif unterstützen das Feature vorläufiges Löschen, 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 Server-Anwendungen, 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