Bearbeiten

Freigeben über


Muster mit externem Konfigurationsspeicher

Azure App Configuration
Azure Blob Storage

Konfigurationsinformationen aus dem Anwendungsbereitstellungspaket an einen zentralen Speicherort verschieben Dies kann das Verwalten und Steuern von Konfigurationsdaten und das gemeinsame Verwenden von Konfigurationsdaten in allen Anwendungen und Anwendungsinstanzen erleichtern.

Kontext und Problem

Die meisten Anwendungslaufzeitumgebungen enthalten Konfigurationsinformationen, die in Dateien gespeichert sind, welche mit der Anwendung bereitgestellt werden. In einigen Fällen können diese Dateien bearbeitet werden, um das Verhalten der Anwendung zu ändern, nachdem sie bereitgestellt wurde. Nach Änderungen an der Konfiguration muss die Anwendung jedoch neu bereitgestellt werden, was häufig zu inakzeptablen Ausfallzeiten und sonstigem Verwaltungsaufwand führt.

Lokale Konfigurationsdateien beschränken ferner die Konfiguration auf eine einzelne Anwendung, gelegentlich wäre es jedoch sinnvoll, Konfigurationseinstellungen für mehrere Anwendungen freizugeben. Beispiele: Datenbankverbindungszeichenfolgen, UI-Designinformationen, die URLs von Warteschlangen und durch eine zusammengehörige Gruppe von Anwendungen verwendeter Speicher.

Es ist nicht einfach, Änderungen an lokalen Konfigurationen über mehrere ausgeführte Instanzen der Anwendung, insbesondere in einem cloudgehosteten Szenario, zu verwalten. Dies kann dazu führen, dass Instanzen andere Konfigurationseinstellungen verwenden, während das Update bereitgestellt wird.

Darüber hinaus erfordern Updates von Anwendungen und Komponenten möglicherweise Änderungen an den Konfigurationsschemas. Viele Konfigurationssysteme unterstützen keine verschiedenen Versionen von Konfigurationsinformationen.

Lösung

Speichern Sie die Konfigurationsinformationen in einem externen Speicher, und stellen Sie eine Schnittstelle bereit, über die Konfigurationseinstellungen schnell und effizient gelesen und aktualisiert werden können. Der Typ des externen Speichers hängt von der Hosting- und Laufzeitumgebung der Anwendung ab. In einem cloudgehosteten Szenario handelt es sich in der Regel um einen cloudbasierten Speicherdienst oder einen dedizierten Konfiguratonsdienst, es könnte sich aber auch um eine gehostete Datenbank oder ein anderes System handeln.

Der Sicherungsspeicher, den Sie für Konfigurationsinformationen auswählen, sollte über eine Schnittstelle verfügen, die einen konsistenten, benutzerfreundlichen Zugriff erlaubt. Sie sollten die Informationen in einem ordnungsgemäß typisierten und strukturierten Format verfügbar machen. Die Implementierung muss möglicherweise auch den Benutzerzugriff autorisieren, um Konfigurationsdaten zu schützen, und so flexibel sein, das Speichern mehrerer Versionen der Konfiguration (wie Entwicklungs-, Staging- und Produktionsversionen, jeweils einschließlich mehrerer Releases) zu ermöglichen.

Viele integrierte Konfigurationssysteme lesen die Daten beim Start der Anwendung und speichern die Daten im Speicher zwischen, um einen schnellen Zugriff zu ermöglichen und Auswirkungen auf die Anwendungsleistung zu minimieren. Je nach Art des verwendeten Sicherungsspeichers und der Latenz dieses Speichers kann es sinnvoll sein, einen Zwischenspeichermechanismus im externen Konfigurationsspeicher zu implementieren. Weitere Informationen finden Sie unter Leitfaden Zwischenspeichern. Die Abbildung zeigt einen Überblick über das Muster des externen Konfigurationsspeichers mit einem optionalen lokalen Cache.

Die Abbildung zeigt einen Überblick über das Muster des externen Konfigurationsspeichers mit einem optionalen lokalen Cache.

Probleme und Überlegungen

Beachten Sie die folgenden Punkte bei der Entscheidung, wie dieses Muster implementiert werden soll:

Wählen Sie einen Sicherungsspeicher aus, der eine akzeptable Leistung, Hochverfügbarkeit und Stabilität bietet und im Rahmen der Anwendungswartung und -verwaltung gesichert werden kann. In einer cloudgehosteten Anwendung ist die Verwendung eines Cloudspeichermechanismus oder eines dedizierten Konfigurationsplattformdiensts in der Regel eine gute Wahl, um diese Anforderungen zu erfüllen.

Gestalten Sie das Schema des Sicherungsspeichers so, dass der Speicher hinsichtlich der Informationsarten, die er speichern kann, flexibel ist. Stellen Sie sicher, dass er für alle Konfigurationsanforderungen wie typisierte Daten, Sammlungen von Einstellungen, mehrere Versionen von Einstellungen und andere Funktionen geeignet ist, die die Anwendungen erfordern, die den Speicher verwenden. Das Schema sollte sich leicht erweitern lassen, um zusätzliche Einstellungen zu unterstützen, wenn sich die Anforderungen ändern.

Berücksichtigen Sie die physischen Möglichkeiten des Sicherungsspeichers, welchen Bezug sie zu der Art der Speicherung der Konfigurationsinformationen haben und welche Auswirkungen auf die Leistung sich hieraus ergeben. Für das Speichern eines XML-Dokuments, das Konfigurationsinformationen enthält, benötigen Sie beispielsweise entweder die Konfigurationsschnittstelle oder die Anwendung, um das Dokument zu analysieren und so einzelne Einstellungen zu lesen. Das Aktualisieren einer Einstellung wird dadurch komplizierter, wenngleich eine Zwischenspeicherung der Einstellungen dazu beitragen kann, eine langsamere Leseleistung zu kompensieren.

Berücksichtigen Sie, in welcher Weise die Konfigurationsschnittstelle eine Kontrolle über den Bereich und die Vererbung von Konfigurationseinstellungen zulässt. Möglicherweise kann es erforderlich sein, Konfigurationseinstellungen auf Organisations-, Anwendungs- oder Computerebene zu betrachten. Es kann erforderlich sein, eine Delegierung der Zugriffsteuerung auf verschiedene Bereiche zu unterstützen und zu verhindern bzw. zuzulassen, dass einzelne Anwendungen Einstellungen außer Kraft setzen.

Stellen Sie sicher, dass die Konfigurationsschnittstelle die Konfigurationsdaten in den erforderlichen Formaten wie typisierte Werte, Sammlungen, Schlüssel-/Wertpaare oder Eigenschaftensammlungen bereitstellen kann.

Berücksichtigen Sie das Verhalten der Konfigurationsschnittstelle, wenn Einstellungen Fehler enthalten oder nicht im Sicherungsspeicher vorhanden sind. Es kann zweckmäßig sein, Standardeinstellungen und Fehlerprotokolle zurückzugeben. Berücksichtigen Sie auch Aspekte wie die Groß-/Kleinschreibung von Konfigurationseinstellungsschlüsseln oder -namen, die Speicherung und Handhabung binärer Daten sowie die Handhabung von Nullwerten oder leeren Werten.

Überlegen Sie, wie die Konfigurationsdaten geschützt werden können, sodass nur angemessenen Benutzern und Anwendungen Zugriff gewährt wird. Hierbei handelt es sich wahrscheinlich um eine Funktion der Konfigurationsspeicherschnittstelle, aber es muss auch sichergestellt werden, dass direkt ohne entsprechende Berechtigung auf die Daten im Sicherungsspeicher zugegriffen werden kann. Stellen Sie eine strikte Trennung zwischen den Berechtigungen sicher, die für das Lesen und das Schreiben von Konfigurationsdaten erforderlich sind. Überlegen Sie auch, ob Sie einige oder alle Konfigurationseinstellungen verschlüsseln müssen und wie dies in der Konfigurationsspeicher-Schnittstelle implementiert werden muss.

Zentral gespeicherte Konfigurationen, die das Verhalten der Anwendung während der Laufzeit ändern, sind sehr wichtig und sollten mit denselben Mechanismen bereitgestellt, aktualisiert und verwaltet werden, die auch für das Bereitstellen von Anwendungscode verwendet werden. Änderungen, die beispielsweise mehrere Anwendungen betreffen können, müssen mithilfe eines umfassenden Test- und Stagingbereitstellungsansatzes durchgeführt werden, um sicherzustellen, dass sich die Änderung für alle Anwendungen eignet, die diese Konfiguration verwenden. Wenn ein Administrator eine Einstellung bearbeitet, sodass eine Anwendung aktualisiert wird, kann sich dies negativ auf die übrigen Anwendungen auswirken, die dieselbe Einstellung verwenden.

Wenn eine Anwendung die Konfigurationsinformationen zwischenspeichert, muss die Anwendung benachrichtigt werden, wenn sich die Konfiguration ändert. Unter Umständen ist es möglich, eine Ablaufrichtlinie über zwischengespeicherte Konfigurationsdaten zu implementieren, sodass diese Informationen automatisch in regelmäßigen Abständen aktualisiert werden und alle Änderungen übernommen (und verarbeitet) werden.

Das Zwischenspeichern von Konfigurationsdaten kann zwar dazu beitragen, vorübergehende Konnektivitätsprobleme mit dem externen Konfigurationsspeicher zur Anwendungslaufzeit zu beheben, doch dies löst das Problem normalerweise nicht, wenn der externe Speicher beim ersten Start der Anwendung heruntergefahren ist. Stellen Sie sicher, dass Ihre Anwendungsbereitstellungspipeline den letzten bekannten Satz von Konfigurationswerten in einer Konfigurationsdatei als Fallback bereitstellen kann, wenn Ihre Anwendung beim Start keine Livewerte abrufen kann.

Verwendung dieses Musters

Dieses Muster ist hilfreich:

  • Für Konfigurationseinstellungen, die von verschiedenen Anwendungen und Anwendungsinstanzen gemeinsam genutzt werden, oder bei denen eine Standardkonfiguration zwischen mehreren Anwendungen und Anwendungsinstanzen erzwungen werden muss.

  • Für ein Standardkonfigurationssystem, das nicht alle erforderlichen Konfigurationseinstellungen wie die Speicherung von Bildern oder komplexen Datentypen unterstützt.

  • Als ergänzender Speicher für einige der Anwendungseinstellungen, wobei möglicherweise Anwendungen gestattet wird, einige oder alle der zentral gespeicherten Einstellungen außer Kraft zu setzen.

  • Als Methode, um die Verwaltung mehrerer Anwendungen zu vereinfachen und optional die Verwendung von Konfigurationseinstellungen zu überwachen, indem einige oder alle Zugriffsarten auf den Konfigurationsspeicher protokolliert werden.

Workloadentwurf

Ein Architekt sollte evaluieren, wie das External Configuration Store-Pattern im Design seines Workloads verwendet werden kann, um die Ziele und Prinzipien zu erreichen, die in den Azure Well-Architected Framework-Säulen behandelt werden. Zum Beispiel:

Säule So unterstützt dieses Muster die Säulenziele
Operational Excellence unterstützt die Workloadqualität durch standardisierte Prozesse und Teamzusammenhalt. Diese Trennung der Anwendungskonfiguration vom Anwendungscode unterstützt die umgebungsspezifische Konfiguration und wendet Versionierung auf Konfigurationswerte an. Externe Konfigurationsspeicher sind auch ein häufiger Ort zum Verwalten von Featurekennzeichnungen, um sichere Bereitstellungsmethoden zu ermöglichen.

- OE:10 Automatisierungsdesign
- OE:11 Sichere Bereitstellungsmethoden

Berücksichtigen Sie wie bei jeder Designentscheidung alle Kompromisse im Hinblick auf die Ziele der anderen Säulen, die mit diesem Muster eingeführt werden könnten.

Beispiel für einen benutzerdefinierten Sicherungsspeicher

In einer gehosteten Microsoft Azure-Anwendung besteht eine mögliche Methode für die externe Speicherung von Konfigurationsdaten darin, Azure Storage zu verwenden. Azure Storage ist stabil, bietet eine hohe Leistung und wird für Hochverfügbarkeit dreimal repliziert (mit automatischem Failover). Azure Table Storage bietet einen Schlüssel/Wert-Speicher mit der Möglichkeit, ein flexibles Schema für die Werte zu verwenden. Azure Blob Storage bietet einen hierarchisch strukturierten, containerbasierten Speicher, der beliebige Datentypen in einzeln benannten Blobs aufnehmen kann.

Bei der Implementierung dieses Musters wären Sie dafür verantwortlich, Azure Blob Storage zu abstrahieren und Ihre Einstellungen innerhalb Ihrer Anwendungen verfügbar zu machen, einschließlich der Überprüfung auf Updates zur Laufzeit und der Behandlung entsprechender Reaktion darauf.

Das folgende Beispiel zeigt, wie ein vereinfachter Konfigurationsspeicher über Blob Storage geplant werden könnte, um Konfigurationsinformationen zu speichern und verfügbar zu machen. Eine BlobSettingsStore-Klasse könnte Blob Storage für die Speicherung von Konfigurationsinformationen abstrahieren, und eine einfache ISettingsStore-Schnittstelle implementieren.

public interface ISettingsStore
{
    Task<ETag> GetVersionAsync();
    Task<Dictionary<string, string>> FindAllAsync();
}

Diese Schnittstelle definiert Methoden zum Abrufen von Konfigurationseinstellungen, die im Konfigurationsspeicher gespeichert werden, und enthält eine Versionsnummer, die verwendet werden kann, um festzustellen, ob Konfigurationseinstellungen kürzlich geändert wurden. Eine BlobSettingsStore-Klasse könnte die ETag-Eigenschaft des Blobs zum Implementieren einer Versionsverwaltung verwenden. Die ETag-Eigenschaft wird automatisch jedes Mal aktualisiert, wenn in ein Blob geschrieben wird.

Standardmäßig macht diese einfache Illustration alle Konfigurationseinstellungen als Zeichenfolgenwerte anstelle typisierter Werten verfügbar.

Eine ExternalConfigurationManager-Klasse könnte dann einen Wrapper um eine BlobSettingsStore-Instanz herum bereitstellen. Eine Anwendung kann diese Klasse zum Abrufen von Konfigurationsinformationen verwenden. Diese Klasse könnte etwas wie Microsoft Reactive Extensions verwenden, um alle Änderungen an der Konfiguration zu veröffentlichen, die während der Ausführung des Systems vorgenommen werden. Sie wäre außerdem für die Implementierung des Cache-Aside-Musters (cachefremd) für Einstellungen verantwortlich, um zusätzliche Resilienz und Leistung bereitzustellen.

Die Verwendung könnte in etwa wie folgt aussehen.

static void Main(string[] args)
{
    // Start monitoring configuration changes.
    ExternalConfiguration.Instance.StartMonitor();

    // Get a setting.
    var setting = ExternalConfiguration.Instance.GetAppSetting("someSettingKey");
    …
}

Verwenden von Azure App Configuration

Zwar könnte das Erstellen eines benutzerdefinierten Konfigurationsspeichers in einigen Situationen erforderlich sein, doch können viele Anwendungen stattdessen Azure App Configuration verwenden. Azure App Configuration unterstützt Schlüssel-Wert-Paare, die mit Namespaces verwendet werden können. Die Schlüssel sind typisiert und einzeln versioniert. Azure App Configuration unterstützt außerdem Zeitpunkt-Momentaufnahmen der Konfiguration, sodass Sie problemlos frühere Konfigurationswerte überprüfen oder sogar auf diese zurücksetzen können. Konfigurationswerte können so exportiert werden, dass eine Kopie der Konfiguration zusammen mit Ihrer Anwendung übermittelt werden kann, falls der Dienst beim Starten der Anwendung nicht erreichbar ist.

Clientbibliotheken

Viele dieser Features werden über Clientbibliotheken verfügbar gemacht, die in die Anwendungslaufzeit integriert werden, um das Abrufen und Zwischenspeichern von Werten, das Aktualisieren von Werten bei Änderungen und sogar das Behandeln vorübergehender Ausfälle von App Configuration Service zu erleichtern.

Typ Clientbibliothek Notizen Schnellstart
.NET Microsoft.Extensions.Configuration.AzureAppConfiguration Anbieter für Microsoft.Extensions.Configuration Schnellstart
ASP.NET Microsoft.Azure.AppConfiguration.AspNetCore Anbieter für Microsoft.Extensions.Configuration Schnellstart
Azure Functions in .NET Microsoft.Extensions.Configuration.AzureAppConfiguration Wird mit Azure Functions-Erweiterungen zur Unterstützung der Konfiguration in Startup.cs verwendet. Schnellstart
.NET Framework Microsoft.Configuration.ConfigurationBuilders.AzureAppConfiguration Konfigurations-Generator für System.Configuration Schnellstart
Java Spring com.azure.spring > azure-spring-cloud-appconfiguration-config Unterstützt Spring Framework-Zugriff über ConfigurationProperties. Schnellstart
Python azure.appconfiguration Stellt einen AzureAppConfigurationClient bereit. Schnellstart
JavaScript/Node.js @azure/app-configuration Stellt einen AppConfigurationClient bereit. Schnellstart

Zusätzlich zu Clientbibliotheken gibt es auch eine GitHub Action Azure App Configuration Sync sowie die Azure DevOps-Aufgaben Azure App Configuration Pull und Azure App Configuration Push, um Konfigurationsschritte in Ihren Buildprozess zu integrieren.

Nächste Schritte