Freigeben über

Unterstützung der App-Konfiguration

In diesem Artikel wird die Spring Cloud Azure-App Konfigurationsbibliothek beschrieben. Diese Bibliothek lädt Konfigurationen und Featurekennzeichnungen aus dem Azure-App-Konfigurationsdienst. Die Bibliothek generiert PropertySource Abstraktionen, die den bereits von der Spring-Umgebung generierten Abstraktionen entsprechen, wie z. B. Umgebungsvariablen, Befehlszeilenkonfigurationen, lokale Konfigurationsdateien usw.

Spring ist ein von VMware entwickeltes Open-Source-Anwendungsframework, das ein vereinfachtes, modulares Verfahren für die Erstellung von Java-Anwendungen bereitstellt. Spring Cloud Azure ist ein Open-Source-Projekt, das eine nahtlose Spring-Integration mit Azure-Diensten ermöglicht.

Voraussetzungen

Einrichten Ihres App Configuration Store

Verwenden Sie den folgenden Befehl, um Ihren Azure-App Konfigurationsspeicher zu erstellen:

az appconfig create \
    --resource-group <your-resource-group> \
    --name <name-of-your-new-store> \
    --sku Standard

Mit diesem Befehl wird ein neuer, leerer Konfigurationsspeicher erstellt. Sie können Ihre Konfigurationen mithilfe des folgenden Importbefehls hochladen:

az appconfig kv import \
    --name <name-of-your-new-store> \
    --source file \
    --path <location-of-your-properties-file> \
    --format properties \
    --prefix /application/

Bestätigen Sie Ihre Konfigurationen, bevor Sie sie laden. Sie können YAML-Dateien hochladen, indem Sie das Format in YAML ändern. Das Präfixfeld ist wichtig, da es sich um das Standardpräfix handelt, das von der Clientbibliothek geladen wird.

Bibliotheksnutzung

Um das Feature in einer Anwendung zu verwenden, können Sie es als Spring Boot-Anwendung erstellen. Die bequemste Möglichkeit, die Abhängigkeit hinzuzufügen, ist mit dem Spring Boot Starter com.azure.spring:spring-cloud-azure-starter-appconfiguration-config. Im folgenden Beispiel für die Datei pom.xml wird Azure-App Configuration verwendet.

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>{spring-boot-version}</version>
    <relativePath />
</parent>

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>com.azure.spring</groupId>
      <artifactId>spring-cloud-azure-dependencies</artifactId>
      <version>6.0.0</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <dependency>
        <groupId>com.azure.spring</groupId>
        <artifactId>spring-cloud-azure-starter-appconfiguration-config</artifactId>
    </dependency>
</dependencies>
<build>
    <plugins>
           <plugin>
               <groupId>org.springframework.boot</groupId>
               <artifactId>spring-boot-maven-plugin</artifactId>
           </plugin>
    </plugins>
</build>

Das folgende Beispiel zeigt eine einfache Spring Boot-Anwendung mithilfe der App-Konfiguration:

@SpringBootApplication
@RestController
public class Application {

    @RequestMapping("/")
    public String home() {
        return "Hello World!";
    }

    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

In diesem Beispiel enthält die Datei "application.properties " die folgende Zeile:

spring.config.import=azureAppConfiguration
spring.cloud.azure.appconfiguration.stores[0].endpoint=${CONFIG_STORE_ENDPOINT}

CONFIG_STORE_ENDPOINT ist eine Umgebungsvariable mit der Endpunkt-URL zu Ihrem Azure App Configuration Store.

Hinweis

Microsoft empfiehlt, immer den sichersten Authentifizierungsflow zu verwenden, der verfügbar ist. Der in diesem Verfahren beschriebene Authentifizierungsfluss, z. B. für Datenbanken, Caches, Nachrichten oder KI-Dienste, erfordert ein sehr hohes Vertrauen in die Anwendung und trägt Risiken, die in anderen Flüssen nicht vorhanden sind. Verwenden Sie diesen Fluss nur, wenn sicherere Optionen wie verwaltete Identitäten für kennwortlose oder schlüssellose Verbindungen nicht geeignet sind. Bei Vorgängen des lokalen Computers bevorzugen Sie Benutzeridentitäten für kennwortlose oder schlüssellose Verbindungen.

Falls keine Konfigurationen festgelegt sind, werden die Konfigurationen, die mit /application/ beginnen, standardmäßig mit (No Label) geladen, es sei denn, ein Spring Profile ist festgelegt. In diesem Fall entspricht die Standardbezeichnung Ihrem Spring Profile.

Eine benannte /application/https://<name-of-your-store>.azconfig.io/ Eigenschaftsquelle wird erstellt, die die Eigenschaften dieses Speichers enthält. Die in der Anfrage verwendete Bezeichnung wird an das Ende des Namens angehängt. Wenn keine Beschriftung festgelegt ist, ist das Zeichen \0 als leeres Leerzeichen vorhanden.

Konfiguration laden

Die Bibliothek unterstützt das Laden eines oder mehrerer App-Konfigurationsspeicher. In der Situation, in der ein Schlüssel in mehreren Stores dupliziert wird, gewinnt der letzte.

spring.cloud.azure.appconfiguration.stores[0].endpoint=[first-store-endpoint]
spring.cloud.azure.appconfiguration.stores[1].endpoint=[second-store-endpoint]

Wenn in diesem Beispiel beide Speicher denselben Konfigurationsschlüssel aufweisen, hat die Konfiguration im zweiten Speicher die höchste Priorität.

Hinweis

Sie können Azure App-Konfigurationseinstellungen wie jede andere Spring-Konfiguration verwenden. Weitere Informationen finden Sie in Core Features der Dokumentation zum Spring Boot oder Schnellstart: Erstellen einer Java Spring-App mit Azure App Configuration.

Auswählen von Konfigurationen

Die Bibliothek lädt Konfigurationen mit dem Schlüssel und der Bezeichnung. Standardmäßig werden die Konfigurationen geladen, die mit dem Schlüssel /application/ beginnen. Die Standardbezeichnung lautet \0, die wie (No Label) im Azure-Portal angezeigt wird. Wenn ein Federprofil festgelegt ist und keine Beschriftung angegeben wird, ist die Standardbezeichnung Ihr Federprofil, das heißt ${spring.profiles.active}.

Sie können konfigurieren, welche Konfigurationen geladen werden, indem Sie verschiedene Schlüssel- und Bezeichnungsfilter auswählen:

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

Die key-filter Eigenschaft unterstützt die folgenden Filter:

Schlüsselfilter Wirkung
* Entspricht einem beliebigen Schlüssel.
abc Entspricht einem Schlüssel mit dem Namen abc.
abc* Schlüsselbezeichnungen, die mit abc beginnen, abgleichen.
abc,xyz Entspricht den Schlüsselnamen abc oder xyz. Auf fünf kommagetrennte Werte beschränkt.

Die label-filter Eigenschaft unterstützt die folgenden Filter:

Etikett Beschreibung
* Entspricht jeder Bezeichnung, einschließlich \0.
\0 Passt zu null -Etiketten, die im Azure-Portal als (No Label) erscheinen.
1.0.0 Exakte Übereinstimmung mit der Bezeichnung 1.0.0.
1.0.* Entspricht Bezeichnungen, die mit 1.0.* beginnen.
,1.0.0 Entspricht Bezeichnungen null und 1.0.0. Auf fünf kommagetrennte Werte beschränkt.

Wenn Sie YAML mit Bezeichnungsfiltern verwenden und Konfigurationen ohne Bezeichnung und mehr Konfigurationen mit anderen Bezeichnungen laden möchten, müssen Sie eine leere ,. Beispiel: ,dev Übereinstimmungen \0 und dev. Geben Sie in diesem Fall den Beschriftungsfilter in einfache Anführungszeichen ein. Mit diesem Wert können Sie die Konfiguration ohne Bezeichnung zuerst laden, gefolgt von Konfigurationen mit bestimmten Bezeichnungen im selben Filter:

spring:
  cloud:
    azure:
      appconfiguration:
        stores:
        - selects:
          - label-filter: ',1.0.0'

Hinweis

Sie können * nicht mit , in Filtern kombinieren. In diesem Fall müssen Sie einen zusätzlichen Auswahlwert verwenden.

Wenn Sie im Bezeichnungsfilter verwenden * und mehrere Konfigurationen mit demselben Schlüssel geladen werden, werden sie in alphabetischer Reihenfolge geladen, und die Beschriftung wird in alphabetischer Reihenfolge verwendet.

Spring-Profile

Standardmäßig wird spring.profiles.active als label-filter für alle ausgewählten Konfigurationen festgelegt. Sie können diese Funktion mithilfe von label-filter überschreiben. Sie können die Spring-Profile im label-filter mit ${spring.profiles.active} verwenden, wie im folgenden Beispiel gezeigt:

spring.cloud.azure.appconfiguration.stores[0].selects[0].label-filter=,${spring.profiles.active}
spring.cloud.azure.appconfiguration.stores[0].selects[1].label-filter=${spring.profiles.active}_local

Im ersten label-filterLädt die Bibliothek zunächst alle Konfigurationen mit der \0 Bezeichnung, gefolgt von allen Konfigurationen, die den Federprofilen entsprechen. Spring-Profile haben Vorrang vor den \0 Konfigurationen, da sie am Ende stehen.

Im zweiten label-filterWird die Zeichenfolge _local an das Ende der Federprofile angefügt, jedoch nur an das letzte Federprofil, wenn mehrere vorhanden sind.

Deaktivierte Geschäfte

Mit der Konfiguration spring.cloud.azure.appconfiguration.enabledkönnen Sie das Laden für alle Konfigurationsspeicher deaktivieren. Mit der spring.cloud.azure.appconfiguration.stores[0].enabled Konfiguration können Sie einen einzelnen Speicher deaktivieren.

Hinweis

Wenn Sie Gesundheitsmetriken verwenden, werden Ihre Stores weiterhin aufgelistet, aber mit dem Wert NOT LOADED. Wenn Sie geladene Eigenschaftenquellen überprüfen, werden sie weiterhin aufgelistet, enthalten aber keine Werte. Dieses Verhalten ist darauf zurückzuführen, dass die Eigenschaft spring.config.import festgelegt ist. Wenn azureAppConfiguration nicht für spring.config.import festgelegt ist, werden keine Werte angezeigt.

Authentifizierung

Die Bibliothek unterstützt alle Formen der Identität, die von der Azure Identity Library unterstützt werden. Sie können die Authentifizierung über die Konfiguration von Verbindungszeichenfolgen und verwalteten Identitäten durchführen.

Hinweis

Microsoft empfiehlt, immer den sichersten Authentifizierungsflow zu verwenden, der verfügbar ist. Der in diesem Verfahren beschriebene Authentifizierungsfluss, z. B. für Datenbanken, Caches, Nachrichten oder KI-Dienste, erfordert ein sehr hohes Vertrauen in die Anwendung und trägt Risiken, die in anderen Flüssen nicht vorhanden sind. Verwenden Sie diesen Fluss nur, wenn sicherere Optionen wie verwaltete Identitäten für kennwortlose oder schlüssellose Verbindungen nicht geeignet sind. Bei Vorgängen des lokalen Computers bevorzugen Sie Benutzeridentitäten für kennwortlose oder schlüssellose Verbindungen.

Die Authentifizierung über eine Verbindungszeichenfolge ist die einfachste Form der Einrichtung, wird jedoch nicht empfohlen. Sie können auf die Verbindungszeichenfolge eines Stores zugreifen, indem Sie den folgenden Befehl verwenden:

az appconfig credential list --name <name-of-your-store>

Anschließend können Sie die Eigenschaft spring.cloud.azure.appconfiguration.stores[0].connection-string auf die Verbindungszeichenfolge festlegen. Bei Verwendung dieses Ansatzes wird dringend empfohlen, die Verbindungszeichenfolge in der lokalen Konfigurationsdatei auf einen Platzhalterwert festzulegen, der einer Umgebungsvariablen zugeordnet ist. Mit diesem Ansatz können Sie das Hinzufügen der Verbindungszeichenfolge zur Quellcodeverwaltung vermeiden.

Spring Cloud Azure Konfiguration

Sie können die Spring Cloud Azure-Konfiguration verwenden, um die Bibliothek zu konfigurieren. Zum Konfigurieren der Bibliothek können Sie die folgenden Eigenschaften verwenden:

spring.cloud.azure.appconfiguration.stores[0].endpoint= <URI-of-your-configuration-store>

Wenn nur der Endpunkt festgelegt ist, verwendet die Clientbibliothek die DefaultAzureCredential zum Authentifizieren.

Sie müssen die Identität zuweisen, die zum Lesen von Konfigurationen verwendet wird. Sie können diese Aufgabe mithilfe des folgenden Befehls erstellen:

az role assignment create \
    --role "App Configuration Data Reader" \
    --assignee <your-client-ID> \
    --scope /subscriptions/<your-subscription>/resourceGroups/<your-stores-resource-group>/providers/Microsoft.AppConfiguration/configurationStores/<name-of-your-configuration-store>

Hinweis

Sie können nur eine Authentifizierungsmethode pro Endpunkt definieren: Verbindungszeichenfolge, vom Benutzer zugewiesene Identität oder Tokenanmeldeinformationen. Wenn Sie eine Mischung und Übereinstimmung benötigen, können Sie die ConfigurationClientCustomizer Zunutze ändernConfigurationClientBuilder, um verschiedene Methoden zu verwenden.

Hinweis

Microsoft empfiehlt, immer den sichersten Authentifizierungsflow zu verwenden, der verfügbar ist. Der in diesem Verfahren beschriebene Authentifizierungsfluss, z. B. für Datenbanken, Caches, Nachrichten oder KI-Dienste, erfordert ein sehr hohes Vertrauen in die Anwendung und trägt Risiken, die in anderen Flüssen nicht vorhanden sind. Verwenden Sie diesen Fluss nur, wenn sicherere Optionen wie verwaltete Identitäten für kennwortlose oder schlüssellose Verbindungen nicht geeignet sind. Bei Vorgängen des lokalen Computers bevorzugen Sie Benutzeridentitäten für kennwortlose oder schlüssellose Verbindungen.

Georeplikation

Die Bibliothek unterstützt das Georeplikationsfeature von Azure-App Konfiguration. Mit diesem Feature können Sie Ihre Daten an andere Speicherorte replizieren. Dieses Feature ist nützlich für hohe Verfügbarkeit und Notfallwiederherstellung.

Jedes Replikat, das Sie erstellen, verfügt über einen dedizierten Endpunkt. Wenn sich Ihre Anwendung an mehreren Geostandorten (Geolocations) befindet, können Sie jede Bereitstellung Ihrer Anwendung an einem Standort so aktualisieren, dass eine Verbindung mit dem Replikat hergestellt wird, das dem Standort näher liegt, wodurch die Netzwerkwartezeiten zwischen Ihrer Anwendung und App Configuration minimiert werden. Da jedes Replikat über ein separates Anforderungskontingent verfügt, hilft dieses Setup auch bei der Skalierbarkeit Ihrer Anwendung, während sie auf einen verteilten Dienst mit mehreren Regionen wächst.

Standardmäßig ermittelt die Bibliothek automatisch alle Replikate, die für einen Konfigurationsspeicher vorhanden sind. Wenn eine Anforderung an den bereitgestellten Speicher gestellt wird und ein Fehler auftritt, versucht die Bibliothek die Anforderung automatisch mit den verfügbaren Replikaten erneut.

Das Failover kann auftreten, wenn die Bibliothek eine der folgenden Bedingungen erfüllt:

  • Empfängt Antworten mit dienstlosem Statuscode (HTTP 500 oder höher) von einem Endpunkt.
  • Erfährt Netzwerkkonnektivitätsprobleme.
  • Anforderungen werden gedrosselt (HTTP-Statuscode 429).

Nachdem der bereitgestellte Store wieder online ist, führt die Bibliothek automatisch eine Wiederholung der Anforderung für den bereitgestellten Store durch.

Wenn Sie das Failoververhalten steuern möchten, können Sie manuell eine Liste der Speicher bereitstellen, die für das Failover verwendet werden sollen.

spring.cloud.azure.appconfiguration.stores[0].endpoints[0]=[your primary store endpoint]
spring.cloud.azure.appconfiguration.stores[0].endpoints[1]=[your replica store endpoint]

oder

spring.cloud.azure.appconfiguration.stores[0].connection-strings[0]=[your primary store connection string]
spring.cloud.azure.appconfiguration.stores[0].connection-strings[1]=[your replica store connection string]

Wenn alle bereitgestellten Replikatendpunkte fehlschlagen, versucht die Bibliothek, eine Verbindung mit automatisch ermittelten Replikaten des primären Speichers herzustellen.

Sie können die Replikation mit der Einstellung spring.cloud.azure.appconfiguration.stores[0].replica-discovery-enabled=falsedeaktivieren.

Erstellen eines Konfigurationsspeichers mit Georeplikation

Um ein Replikat Ihres Konfigurationsspeichers zu erstellen, können Sie die Azure CLI oder die Azure-Portal verwenden. Im folgenden Beispiel wird die Azure CLI verwendet, um ein Replikat in der Region Ost-USA 2 zu erstellen:

az appconfig replica create --location --name --store-name [--resource-group]

Schlüsselwerte

Azure-App Configuration unterstützt mehrere Typen von Schlüsselwerten, von denen einige spezielle Features enthalten. Azure-App Configuration bietet integrierte Unterstützung für den JSON-Inhaltstyp, Springplatzhalter und Key Vault-Verweise.

Platzhalter

Die Bibliothek unterstützt Konfigurationen mit Umgebungsplatzhaltern im Stil von ${}. Wenn Sie auf einen Azure-App Konfigurationsschlüssel mit einem Platzhalter verweisen, entfernen Sie Präfixe aus dem Verweis. Beispielsweise wird /application/config.message als ${config.message} referenziert.

Hinweis

Das präfix, das entfernt wird, entspricht dem Wert spring.cloud.azure.appconfiguration.stores[0].selects[0].key-filter. Das präfix, das gekürzt wird, kann durch Festlegen eines Werts für spring.cloud.azure.appconfiguration.stores[0].trim-key-prefix[0].

JSON

Konfigurationen mit einem Inhaltstyp application/json werden als JSON-Objekte verarbeitet. Mit diesem Feature können Sie eine Konfiguration einem komplexen Objekt innerhalb eines @ConfigurationPropertiesObjekts zuordnen. Betrachten Sie beispielsweise den JSON-Schlüssel /application/config.colors mit dem folgenden Wert:

{
 "Red": {
  "value": [255, 0, 0]
 },
 "Blue": {
  "value": [0, 255, 0]
 },
 "Green": {
  "value": [0, 0, 255]
 }
}

Dieser Schlüssel ist dem folgenden Code zugeordnet:

@ConfigurationProperties(prefix = "config")
public class MyConfigurations {

    private Map<String, Color> colors;

}

Key Vault-Verweise

Azure-App Konfiguration und deren Bibliotheken unterstützen das Verweisen auf geheime Schlüssel, die im Key Vault gespeichert sind. In der App-Konfiguration können Sie Schlüssel mit Werten erstellen, die geheimen Schlüsseln zugeordnet sind, die in einem Key Vault gespeichert sind. Geheime Schlüssel bleiben im Key Vault sicher, aber Sie können auf die gleiche Weise wie jede andere Konfiguration beim Laden der App darauf zugreifen.

Ihre Anwendung verwendet den Clientanbieter, um Key Vault-Verweise abzurufen, genau wie für alle anderen schlüssel, die in der App-Konfiguration gespeichert sind. Da der Client die Schlüssel als Key Vault-Verweise erkennt, verfügt er über einen eindeutigen Inhaltstyp, und der Client stellt eine Verbindung mit Key Vault bereit, um seine Werte für Sie abzurufen.

Hinweis

Key Vault erlaubt nur den Abruf einzelner Geheimnisse, so dass jede in der App-Konfiguration gespeicherte Key Vault-Referenz zu einem Abruf von Key Vault führt.

Erstellen von Key Vault-Verweisen

Sie können im Azure-Portal einen Key Vault-Verweis erstellen, indem Sie zum Configuration Explorer navigieren und dann > sowie Key Vault-Verweis auswählen. Sie können dann ein Geheimnis auswählen, das Sie aus einem der Key Vaults, auf die Sie Zugriff haben, referenzieren möchten. Sie können auch beliebige Key Vault-Verweise auf der Registerkarte "Eingabe" erstellen. Geben Sie im Azure-Portal einen gültigen URI ein.

Sie können auch einen Key Vault-Verweis über die Azure CLI erstellen, indem Sie den folgenden Befehl verwenden:

az appconfig kv set-keyvault \
    --name <name-of-your-store> \
    --key <key-name> \
    --secret-identifier <URI-to-your-secret>

Sie können jeden geheimen Bezeichner über die Azure CLI erstellen. Geheime Bezeichner erfordern lediglich das Format {vault}/{collection}/{name}/{version?} , in dem der Versionsabschnitt optional ist.

Verwenden von Key Vault-Verweisen

Sie können die Spring Cloud Azure-Konfiguration verwenden, um die Bibliothek zu konfigurieren. Sie können dieselben Anmeldeinformationen verwenden, die Sie für die Verbindung zu App Configuration genutzt haben, um Azure Key Vault zu verbinden.

Sie können auch eine SecretClientCustomizer gleiche Weise erstellen wie eine ConfigurationClientCustomizer , um Ihre eigene Authentifizierungsmethode bereitzustellen.

Nicht im Key Vault gespeicherte Geheimnisse auflösen

Die App-Konfigurationsbibliothek bietet eine Methode zum Überschreiben der Auflösung von Schlüsseltresorverweisen. Sie können es beispielsweise verwenden, um geheime Schlüssel in einer Entwicklungsumgebung lokal aufzulösen. Diese Auflösung erfolgt über das KeyVaultSecretProvider. Der KeyVaultSecretProvider, sofern angegeben, wird für jeden Schlüsseltresorverweis aufgerufen. Wenn getSecret ein Wert ungleich NULL zurückgegeben wird, wird er als geheimer Wert verwendet. Andernfalls wird die Schlüsseltresorreferenz normal aufgelöst.

public class MySecretProvider implements KeyVaultSecretProvider {

    @Override
    public String getSecret(String uri) {
        ...
    }

}

Funktionsverwaltung

Die Featureverwaltung bietet eine Möglichkeit für Spring Boot-Anwendungen, dynamisch auf Inhalte zuzugreifen. Die Featureverwaltung verfügt über verschiedene Funktionen, z. B. die folgenden Funktionen:

  • Featurekennzeichnungen, die Inhalte aktivieren oder deaktivieren können
  • Featurefilter für die Zielgruppenadressierung, wenn Inhalte angezeigt werden
  • Angepasste Funktionsfilter
  • Feature Gates zur dynamischen Aktivierung von Endpunkten

Sie können Featurekennzeichnungen über die folgende Konfiguration aktivieren:

spring.cloud.azure.appconfiguration.stores[0].feature-flags.enabled= true

Aktivierte Featurekennzeichnungen werden mit dem Präfix feature-managementin das Spring-Konfigurationssystem geladen. Sie können Featurekennzeichnungen auch in der lokalen Konfigurationsdatei registrieren. Weitere Informationen finden Sie im Abschnitt "Featurekennzeichnungsdeklaration ".

Die einfachste Möglichkeit zur Verwendung des Feature-Managements ist die Nutzung der spring-cloud-azure-feature-management und spring-cloud-azure-feature-management-web Bibliotheken. Der Unterschied zwischen den beiden Bibliotheken besteht darin, dass spring-cloud-azure-feature-management-web eine Abhängigkeit von den spring-web und spring-webmvc Bibliotheken hat, um weitere Features wie Feature-Gates hinzuzufügen.

Standardmäßig werden alle Featurekennzeichnungen mit einer \0 Bezeichnung geladen, die als (No Label)" bezeichnet" angezeigt wird. Sie können die Feature-Kennzeichnungen konfigurieren, die geladen werden, indem Sie einen Bezeichnungsfilter festlegen, wie im folgenden Beispiel gezeigt wird:

spring.cloud.azure.appconfiguration.stores[0].feature-flags.selects[0].key-filter=A*
spring.cloud.azure.appconfiguration.stores[0].feature-flags.selects[0].label-filter= dev

Grundlagen der Featureverwaltung

Featureflags

Featurekennzeichnungen bestehen aus mehreren Teilen, einschließlich eines Namens und einer Liste von Featurefiltern, die zum Aktivieren des Features verwendet werden. Featurekennzeichnungen können entweder einen booleschen Status von "Ein" oder "Aus" aufweisen, oder sie können eine Liste mit Featurefiltern enthalten. Merkmalsflags werten Merkmalsfilter aus, bis einer truezurückgibt. Wenn kein Featurefilter true ergibt, wird dann das Feature-Flag false zurückgegeben.

Feature-Filter

Featurefilter definieren ein Szenario, für das ein Feature aktiviert werden soll. Featurefilter werden synchron ausgewertet.

Die Featureverwaltungsbibliothek enthält vier vordefinierte Filter: AlwaysOnFilter, PercentageFilter, TimeWindowFilter und TargetingFilter.

Sie können benutzerdefinierte Featurefilter erstellen. Sie können z. B. einen Featurefilter verwenden, um Kunden, die einen Microsoft Edge-Browser verwenden, eine benutzerdefinierte Benutzeroberfläche bereitzustellen. Sie können die Features in diesem Featurefilter anpassen, um z. B. eine bestimmte Kopfzeile für die Microsoft Edge-Browsergruppe anzuzeigen.

Featureflagdeklaration

Die Featureverwaltungsbibliothek unterstützt die Azure App-Konfiguration zusammen mit application.yml oder application.properties als Quellen für Featurekennzeichnungen. Hier sehen Sie ein Beispiel für das Format, das zum Einrichten von Featurekennzeichnungen in einer application.yml Datei verwendet wird:

feature-management:
  feature_flags:
  - id: feature-t
    enabled: false
  - id: feature-u
    conditions:
      client_filters:
      - name: Random
  - id: feature-v
    conditions:
      client_filters:
      - name: TimeWindowFilter
        parameters:
          Start: "Wed, 01 May 2019 13:59:59 GMT"
          End: "Mon, 01 July 2019 00:00:00 GMT"

  - id: feature-w
    evaluate: false
    conditions:
      client_filters:
      - name: AlwaysOnFilter

Dieses Beispiel weist die folgenden Featurekennzeichnungen auf:

  • feature-t ist auf false eingestellt. Diese Einstellung gibt immer den Wert des Funktionsflags zurück.
  • feature-u wird mit Featurefiltern verwendet. Diese Filter werden unter der enabled-for Eigenschaft definiert. In diesem Fall feature-u hat ein Featurefilter namens Random, der keine Konfiguration erfordert, sodass nur die Namenseigenschaft erforderlich ist.
  • feature-v gibt einen Featurefilter mit dem Namen TimeWindowFilter an. Mit diesem Funktionsfilter können Parameter übergeben werden, die als Konfiguration verwendet werden. In diesem Beispiel übergibt ein TimeWindowFilter, die Start- und Endzeiten, in denen das Feature aktiv ist.
  • feature-w wird für die AlwaysOnFilter verwendet, die immer zu true ausgewertet wird. Das evaluate Feld wird verwendet, um die Auswertung der Featurefilter zu beenden, und führt dazu, dass der Featurefilter immer zurückgegeben wird false.

Auswerten von Merkmalsauszeichnungen

Die spring-cloud-azure-feature-management Bibliothek stellt FeatureManager bereit, um zu bestimmen, ob ein Feature-Flag aktiviert ist. FeatureManager bietet eine asynchrone Möglichkeit zum Überprüfen des Status der Kennzeichnung.

spring-cloud-azure-feature-management-web enthält zusammen mit der Bereitstellung von FeatureManager das FeatureManagerSnapshot, das den Status der zuvor ausgewerteten Feature-Flags im @RequestScope zwischenspeichert, um sicherzustellen, dass alle Anforderungen denselben Wert zurückgeben. Darüber hinaus stellt die Webbibliothek bereit @FeatureGate, die Webanforderungen entweder blockieren oder an verschiedene Endpunkte umleiten kann.

Überprüfen von Featureflags

FeatureManager ist ein @Bean, das @Autowired oder in Objekte vom Typ @Component injiziert werden kann. FeatureManager verfügt über eine Methode isEnabled , die beim Übergeben des Namens eines Featureflags den Status zurückgibt.

@Autowired
FeatureManager featureManager;

...

if (featureManager.isEnabled("feature-t")) {
    // Do Something
}

Hinweis

FeatureManager verfügt außerdem über eine asynchrone Version von isEnabled, namens isEnabledAsync.

Ohne Featureverwaltungskonfiguration oder wenn das Feature-Flag nicht vorhanden ist, isEnabled wird immer zurückgegeben false. Wenn ein vorhandenes Feature-Flag mit einem unbekannten Featurefilter konfiguriert ist, wird ein FilterNotFoundException Fehler ausgelöst. Sie können dieses Verhalten ändern, damit false zurückgegeben wird, indem Sie fail-fast zu false konfigurieren. Die folgende Tabelle beschreibt fail-fast:

Name Beschreibung Erforderlich Standard
spring.cloud.azure.feature.management.fail-fast Wenn eine Ausnahme auftritt, wird ein RuntimeException ausgelöst. Wenn diese Eigenschaft auf false festgelegt ist, wird isEnabled stattdessen false zurückgegeben. Nein true

Der einzige Unterschied zwischen FeatureManagerSnapshot und FeatureManager ist das Zwischenspeichern von Ergebnissen in der @RequestScope.

Merkmal Tor

Mit der Featureverwaltungswebbibliothek können Sie festlegen, dass ein bestimmtes Feature aktiviert ist, um einen Endpunkt auszuführen. Sie können diese Anforderung mithilfe der @FeatureGate Anmerkung einrichten, wie im folgenden Beispiel gezeigt:

@GetMapping("/featureT")
@FeatureGate(feature = "feature-t")
@ResponseBody
public String featureT() {
    ...
}

Sie können nur auf den featureT Endpunkt zugreifen, wenn "feature-t" aktiviert ist.

Deaktivierte Aktionsbehandlung

Wenn ein Endpunkt blockiert wird, weil das von ihm festgelegte Feature deaktiviert ist, wird DisabledFeaturesHandler aufgerufen. Standardmäßig wird ein HTTP 404 zurückgegeben. Sie können dieses Verhalten außer Kraft setzen, indem Sie das folgende Beispiel implementieren DisabledFeaturesHandler:

@Component
public class MyDisabledFeaturesHandler implements DisabledFeaturesHandler {

    @Override
    public HttpServletResponse handleDisabledFeatures(HttpServletRequest request, HttpServletResponse response) {
        ...
        return response;
    }

}
Routenführung

Bestimmte Routen können Anwendungsfunktionen verfügbar machen, die von Features abgesperrt sind. Wenn ein Feature deaktiviert ist, können Sie diese Routen an einen anderen Endpunkt umleiten, wie im folgenden Beispiel gezeigt:

@GetMapping("/featureT")
@FeatureGate(feature = "feature-t" fallback= "/oldEndpoint")
@ResponseBody
public String featureT() {
    ...
}

@GetMapping("/oldEndpoint")
@ResponseBody
public String oldEndpoint() {
    ...
}

Integrierte Featurefilter

Es gibt einige Featurefilter, die im spring-cloud-azure-feature-management Paket enthalten sind. Diese Featurefilter werden automatisch hinzugefügt.

AlwaysOnFilter

Dieser Filter gibt immer zurück true. Ein Verwendungsbeispiel finden Sie im Abschnitt "Featurekennzeichnungsdeklaration ".

Prozentsatzfilter

Jedes Mal, wenn sie überprüft wird, kann die Auswertung PercentageFilter ein anderes Ergebnis zurückgeben. Sie können diese Inkonsistenz umgehen, indem Sie das FeatureManagementSnapshotErgebnis des Featureflags pro Anforderung zwischenspeichern.

feature-management:
  feature_flags:
  - name: feature-v
    conditions:
      client_filters:
      - name: PercentageFilter
        parameters:
          Value: 50

ZeitFensterFilter

Dieser Filter bietet die Möglichkeit, ein Feature basierend auf einem Zeitfenster zu aktivieren. Wenn Sie nur End angeben, wird die Funktion bis zu diesem Zeitpunkt als aktiv betrachtet. Wenn Sie nur Start angeben, wird das Feature ab diesem Zeitpunkt als aktiviert betrachtet. Wenn Sie beide angeben, wird das Feature zwischen den beiden Zeiten als gültig betrachtet.

feature-management:
  feature_flags:
  - name: feature-v
    conditions:
      client_filters:
      - name: TimeWindowFilter
        parameters:
          Start: "Wed, 01 May 2019 13:59:59 GMT"
          End: "Mon, 01 July 2019 00:00:00 GMT"

Dieser Filter unterstützt auch Filter für wiederkehrende Zeitfenster. Sie unterstützt sowohl tägliche als auch wöchentliche Wiederholungen sowie eine Ablaufzeit.

feature-management:
  feature_flags:
  - name: feature-v
    conditions:
      client_filters:
      - name: TimeWindowFilter
        parameters:
          Start: "Mon, 01 July 2019 00:00:00 GMT"
          End: "Mon, 01 July 2019 12:00:00 GMT"
          Recurrence:
            Pattern:
              Type: Weekly
              Interval: 1
              FirstDayOfWeek: Sunday
              DaysOfWeek:
              - Monday
              - Wednesday

Dieses Serienmuster erfolgt jede Woche montags und mittwochs von 00:00:00 GMT bis 12:00:00 GMT und läuft nicht ab.

feature-management:
  feature_flags:
  - name: feature-v
    conditions:
      client_filters:
      - name: TimeWindowFilter
        parameters:
          Start: "Mon, 01 July 2019 00:00:00 GMT"
          End: "Mon, 01 July 2019 12:00:00 GMT"
          Recurrence:
            Pattern:
              Type: Daily
              Interval: 2
            Range:
              Type: EndDate
              EndDate: "Fri, 15 Aug 2025 07:00:00 GMT"

Dieses Serienmuster findet jeden anderen Tag von 00:00:00 GMT bis 12:00:00 GMT bis zum Enddatum statt.

TargetingFilter

Dieser Filter bietet die Möglichkeit, ein Feature für eine Zielgruppe zu aktivieren. Eine ausführliche Erläuterung der Zielbestimmung finden Sie im Abschnitt "Zielbestimmung" . Die Filterparameter enthalten ein Benutzergruppenobjekt, das Benutzer, Gruppen und einen Standardprozentsatz der Benutzerbasis beschreibt, die Zugriff auf das Feature haben soll. Für jedes Gruppenobjekt, das in der Zielgruppe aufgeführt ist, ist ein Prozentsatz erforderlich, der den Prozentsatz der Mitglieder dieser Gruppe definiert, die Zugriff auf das Feature haben. Ein Benutzer hat das Feature in den folgenden Fällen aktiviert:

  • Der Benutzer wird direkt im Abschnitt "Benutzer" angegeben.
  • Der Benutzer befindet sich in dem Prozentsatz, der in einem der Gruppen-Rollouts enthalten ist.
  • Der Benutzer fällt in den Standard-Rollout-Prozentsatz.
feature-management:
  feature_flags:
  - name: target
    conditions:
      client_filters:
      - name: targetingFilter
        parameters:
          users:
          - Jeff
          - Alicia
          groups:
          - name: Ring0
            rollout-percentage: 100
          - name: Ring1
            rolloutPercentage: 100
          default-rollout-percentage: 50

Benutzerdefinierte Funktionsfilter

Das Erstellen eines benutzerdefinierten Featurefilters bietet eine Möglichkeit, Features basierend auf von Ihnen definierten Kriterien zu aktivieren. Zum Erstellen eines benutzerdefinierten Featurefilters müssen Sie die FeatureFilter Schnittstelle implementieren. FeatureFilter hat eine einzelne Methode evaluate. Wenn ein Feature angibt, dass es mit einem Featurefilter aktiviert werden kann, wird die evaluate Methode aufgerufen. Wenn evaluatetrue zurückgegeben wird, bedeutet dies, dass das Feature aktiviert werden soll. Wenn er falsezurückgibt, fährt er mit der Auswertung der Merkmalsfilter fort, bis einer truezurückgibt. Wenn alle Filter den Wert false zurückgeben, ist die Funktion ausgeschaltet.

Featurefilter werden als Spring Beans definiert, daher sind sie entweder als @Component oder in einer @Configuration definiert.

@Component("Random")
public class Random implements FeatureFilter {

    @Override
    public boolean evaluate(FeatureFilterEvaluationContext context) {
        double chance = Double.valueOf((String) context.getParameters().get("chance"));
        return Math.random() > chance / 100;
    }

}

Parametrisierte Featurefilter

Einige Featurefilter erfordern Parameter, um zu bestimmen, ob ein Feature aktiviert werden soll. Beispielsweise kann ein Browserfeaturefilter ein Feature für eine bestimmte Gruppe von Browsern aktivieren. Möglicherweise möchten Sie ein Feature, das für Microsoft Edge- und Chrome-Browser aktiviert ist, aber nicht Firefox. Um diese Situation einzurichten, können Sie einen Funktionsfilter entwerfen, der Parameter erwartet. Diese Parameter werden in der Featurekonfiguration und im Code angegeben und werden über den FeatureFilterEvaluationContext Parameter von evaluate zugänglich sein. FeatureFilterEvaluationContext hat eine Eigenschaft parameters, die ein Map<String, Object> ist.

Zielbestimmung

Die Zielbestimmung ist eine Featureverwaltungsstrategie, mit der Entwickler neue Features schrittweise für ihre Benutzerbasis bereitstellen können. Die Strategie basiert auf dem Konzept der Zielgruppenadressierung einer Gruppe von Benutzern, die als Zielgruppe bezeichnet werden. Eine Benutzergruppe besteht aus bestimmten Benutzern, Gruppen und einem bestimmten Prozentsatz der gesamten Benutzerbasis. Die Gruppen, die in der Zielgruppe enthalten sind, können weiter in Prozentsätze ihrer Gesamtmitglieder unterteilt werden.

Die folgenden Schritte veranschaulichen ein Beispiel für ein progressives Rollout für ein neues Feature „Beta“:

  1. Individuelle Benutzer Jeff und Alicia erhalten Zugriff auf die Betaversion.
  2. Ein anderer Benutzer, Mark, fordert die Anmeldung an und wird aufgenommen.
  3. Zwanzig Prozent einer Gruppe, die als „Ring1“-Benutzer bezeichnet wird, sind in der Betaversion enthalten.
  4. Die Anzahl der in der Betaversion enthaltenen „Ring1“-Benutzer wird auf 100 Prozent erhöht.
  5. Fünf Prozent der Benutzerbasis sind in der Betaversion enthalten.
  6. Der Rollout-Prozentsatz wird auf 100 Prozent erhöht, und das Feature wird vollständig eingeführt.

Diese Strategie für das Rollout eines Features ist über den enthaltenen TargetingFilter Featurefilter in die Bibliothek integriert.

Zielbestimmung in einer Anwendung

Eine Beispielwebanwendung, die den Zielfeaturefilter verwendet, ist im Beispielprojekt verfügbar.

Um den TargetingFilter in einer Anwendung zu verwenden, müssen Sie ihn als @Bean wie jeden anderen Funktionsfilter hinzufügen. TargetingFilter basiert auf einem anderen @Bean , das der Anwendung TargetingContextAccessorhinzugefügt werden soll. Das TargetingContextAccessor ermöglicht das Definieren des aktuellen TargetingContext, das zum Festlegen der aktuellen Benutzer-ID und -Gruppen verwendet werden soll, wie im folgenden Beispiel gezeigt:

public class MyTargetingContextAccessor implements TargetingContextAccessor {

    @Override
    public void configureTargetingContext(TargetingContext context) {
        context.setUserId("Jeff");
        ArrayList<String> groups = new ArrayList<String>();
        groups.add("Ring0");
        context.setGroups(groups);
    }

}

Gezielte Bewertungsmöglichkeiten

Optionen stehen zur Verfügung, um anzupassen, wie die Zielauswertung in einem bestimmten Bereich TargetingFilterdurchgeführt wird. Sie können während der Erstellung von TargetingEvaluationOptions einen optionalen Parameter TargetingFilter festlegen.

    @Bean
    public TargetingFilter targetingFilter(MyTargetingContextAccessor contextAccessor) {
        return new TargetingFilter(contextAccessor, new TargetingEvaluationOptions().setIgnoreCase(true));
    }

Konfigurationsaktualisierung

Wenn Sie die Konfigurationsaktualisierung für Ihre Konfigurationen aktivieren, können Sie die neuesten Werte aus Ihrem App-Konfigurationsspeicher oder -stores abrufen, ohne die Anwendung neu starten zu müssen.

Um die Aktualisierung zu aktivieren, müssen Sie die Überwachung zusammen mit den Überwachungsauslösern aktivieren. Ein Überwachungstrigger ist ein Schlüssel mit einer optionalen Bezeichnung, die das System auf Wertänderungen überwacht, um Aktualisierungen auszulösen. Der Wert des Überwachungstriggers kann ein beliebiger Wert sein, solange er sich ändert, wenn eine Aktualisierung erforderlich ist.

Hinweis

Jeder Vorgang, der das ETag eines Überwachungstriggers ändert, verursacht eine Aktualisierung, z. B. eine Inhaltstypänderung.

spring:
  cloud:
    azure:
      appconfiguration:
        stores:
        - monitoring:
          enabled: true
          triggers:
          - key: [my-watched-key]
            label: [my-watched-label]

Um eine Konfigurationsaktualisierung auszulösen, ändern Sie den Wert eines Schlüssels in Ihrem Konfigurationsspeicher. Aktualisieren Sie dann einen der Uhrenschlüssel auf einen neuen Wert. Diese Änderung löst die Erstellung eines Protokolls aus. Beispielsweise führt das Ändern des Wertes von /application/config.message zu folgender Log-Meldung:

INFO 17496 --- [TaskScheduler-1] o.s.c.e.event.RefreshEventListener       : Refresh keys changed: [config.message]

Nachdem die Anwendung das Protokoll erstellt hat, aktualisiert sie alle @Beans im Aktualisierungsbereich.

Hinweis

Standardmäßig sind @ConfigurationProperties -kommentierte Beans in diesem Bereich enthalten.

Pull-basierte Aktualisierung

Die Spring-Bibliotheken der App-Konfiguration unterstützen die Möglichkeit, in einem Aktualisierungsintervall regelmäßig zu prüfen, ob Änderungen an den Überwachungsauslösern vorgenommen wurden. Standardmäßig ist das Aktualisierungsintervall auf 30 Sekunden festgelegt. Nachdem das Aktualisierungsintervall bestanden wurde, werden alle Auslöser beim Ausführen eines Aktualisierungsversuchs im angegebenen Speicher auf Änderungen eingecheckt. Jede Änderung an dem Schlüssel bewirkt, dass eine Aktualisierung ausgelöst wird. Da die Bibliotheken in das Spring-Aktualisierungssystem integriert sind, lädt jede Aktualisierung alle Konfigurationen aus allen Stores neu. Sie können das Aktualisierungsintervall auf ein beliebiges Intervall festlegen, das länger als 1 Sekunde ist. Die unterstützten Einheiten für das Aktualisierungsintervall sind s, mhund d für Sekunden, Minuten, Stunden und Tage. Im folgenden Beispiel wird das Aktualisierungsintervall auf 5 Minuten festgelegt:

spring.cloud.azure.appconfiguration.stores[0].monitoring.refresh-interval= 5m

Automatisiert

Wenn Sie die spring-cloud-azure-appconfiguration-config-web Bibliothek verwenden, sucht die Anwendung automatisch nach einer Aktualisierung, wenn eine Servlet-Anforderung auftritt, insbesondere ServletRequestHandledEvent. Der häufigste Weg, auf die dieses Ereignis gesendet wird, sind Anforderungen an Endpunkte in einer @RestController.

Handbuch

In Anwendungen, die nur spring-cloud-azure-appconfiguration-config verwenden, z. B. Konsolenanwendungen, können Sie eine Aktualisierung manuell durch Aufrufen der AppConfigurationRefresh-Methode von refreshConfiguration auslösen. AppConfigurationRefresh ist ein @Bean, das Sie in jedes beliebige @Component einfügen können.

Da die Bibliothek das Spring-Konfigurationssystem verwendet, führt das Auslösen einer Aktualisierung auch zu einer Aktualisierung aller Konfigurationen, nicht nur zum Neuladen der Konfigurationen aus Ihrem Azure App Configuration Store.

Hinweis

Diese Methode wird nicht mehr empfohlen, wird aber derzeit noch unterstützt.

Sie können die spring-cloud-azure-appconfiguration-config-web Bibliothek so einrichten, dass Pushbenachrichtigungen aus Ihrem Azure App-Konfigurationsspeicher empfangen werden, um Ihre Konfigurationswerte zu aktualisieren. Sie können diese Konfiguration über einen Azure Event Grid Web Hook einrichten, den Sie konfigurieren können, um Benachrichtigungen über Änderungen an bestimmte Schlüssel zu senden. Durch Hinzufügen der Spring-Aktorbibliothek als Abhängigkeit können Sie die Aktualisierungsendpunkte der App-Konfiguration verfügbar machen. Es gibt zwei verschiedene Endpunkte: appconfiguration-refresh und appconfiguration-refresh-bus. Diese Endpunkte funktionieren ähnlich wie ihre Gegenstücke refresh und refresh-bus, wo die App-Konfigurationsendpunkte das Aktualisierungsintervall ablaufen, anstatt eine Aktualisierung beim Empfang zu erzwingen. Sie können refresh und refresh-bus weiterhin verwenden, aber Sie können sie nicht direkt mit Azure Event Grid über einen Webhook verbinden, da im Setup eine Antwort erforderlich ist.

Die appconfiguration-refresh-Eigenschaft beendet das Aktualisierungsintervall, sodass das verbleibende Aktualisierungsintervall nicht abgewartet wird, bevor die nächste Aktualisierungsprüfung erfolgt. Die appconfiguration-refresh-bus-Eigenschaft sendet eine Benachrichtigung an einen verbundenen Messagingdienst, wie etwa Azure Service Bus, um alle Instanzen einer Anwendung aufzufordern, sich zu aktualisieren. In beiden Fällen läuft sie nicht vollständig im Aktualisierungsintervall ab, ist aber um einen kleinen Jitterbetrag deaktiviert. Dieser Jitter stellt sicher, dass jede Instanz Ihrer Anwendung nicht gleichzeitig versucht, zu aktualisieren.

management.endpoints.web.exposure.include= appconfiguration-refresh, appconfiguration-refresh-bus

Zusätzlich zum Verfügbarmachen der Aktualisierungsendpunkte erfordert die Bibliothek einen Abfrageparameter für die Sicherheit. Standardmäßig ist kein Tokenname oder -wert vorhanden, Sie müssen jedoch einen für die Verwendung der Endpunkte festlegen, wie im folgenden Beispiel gezeigt:

spring.cloud.azure.appconfiguration.stores[0].monitoring.push-notification.primary-token.name=[primary-token-name]
spring.cloud.azure.appconfiguration.stores[0].monitoring.push-notification.primary-token.secret=[primary-token-secret]
spring.cloud.azure.appconfiguration.stores[0].monitoring.push-notification.secondary-token.name=[secondary-token-name]
spring.cloud.azure.appconfiguration.stores[0].monitoring.push-notification.secondary-token.secret=[secondary-token-secret]

Einrichten von Web-Hooks

Um einen Webhook einzurichten, öffnen Sie Ihren Azure App Konfigurationsspeicher und wählen Sie Ereignisse im Navigationsmenü aus. Wählen Sie dann "Ereignisabonnement" aus. Legen Sie den Namen Ihres Ereignisses fest, und wählen Sie den Endpunkttyp als Web Hook aus. Wenn Sie Web Hook auswählen, wird eine Endpunktoption angezeigt. Klicken Sie auf Endpunkt auswählen. Ihr Endpunkt sollte wie im folgenden Beispiel aussehen: https://www.myaplication.com/actuator/appconfiguration-refresh?myTokenName=mySecret.

Auswahl bestätigen sendet eine Setup-Benachrichtigung an die angegebene URI und erwartet eine Antwort. Wenn keine Antwort zurückgegeben wird, schlägt das Setup fehl. Das azure-spring-cloud-appconfiguration-web Bibliothekssetup für Endpunkte gibt die richtige Antwort zurück, wenn der Azure-App Konfigurationsspeicher für die Anwendung konfiguriert ist. Diese Bestätigung kann auf andere Weise gesendet werden. Weitere Informationen zur Webhook-Übermittlung finden Sie unter Webhook-Ereignisübermittlung.

Hinweis

Diese Überprüfung erfolgt nur bei der Erstellung oder Änderung des Endpunkts.

Es wird dringend empfohlen, Filter einzurichten, da andernfalls nach jeder Schlüsselerstellung und -änderung eine Aktualisierung ausgelöst wird.

Erzwungene Clientaktualisierung

Sie können die Bibliothek so konfigurieren, dass eine Aktualisierung aller Konfigurationen in einem Aktualisierungsintervall erzwungen wird. In der folgenden Tabelle wird die refresh-interval Eigenschaft beschrieben:

Name Beschreibung Erforderlich Standard
spring.cloud.azure.appconfiguration.refresh-interval Die Standardzeit zwischen Aktualisierungen. Ist ein Duration. Nein NULL

Das Aktualisieren mit spring.cloud.azure.appconfiguration.refresh-interval prüft keine konfigurierten Überwachungsschlüssel. Diese Eigenschaft wird verwendet, um sicherzustellen, dass die Geheimnisse im Schlüsseltresor aktualisiert bleiben, da die Azure-App-Konfiguration nicht erkennen kann, wann sie aktualisiert werden.

Da Azure Key Vault das öffentliche und private Schlüsselpaar eines Zertifikats als geheimes Zertifikat speichert, kann Ihre Anwendung jedes Zertifikat als Key Vault-Referenz in der App-Konfiguration abrufen. Da Zertifikate regelmäßig erneuert werden müssen, müssen Clientanwendungen in genauso kurzen Abständen aktualisiert werden, was mithilfe des Clientaktualisierungsintervalls erfolgen kann.

Merkmal Flagge aktualisieren

Wenn Featurekennzeichnungen und -überwachungen aktiviert sind, wird standardmäßig das Aktualisierungsintervall für Featurekennzeichnungen auf 30 Sekunden festgelegt. Wenn das Aktualisierungsintervall endet, überprüft das System alle Featurekennzeichnungen im angegebenen Speicher auf Änderungen. Jede Änderung an dem Schlüssel bewirkt, dass eine Aktualisierung ausgelöst wird. Da die Bibliotheken in das Spring-Aktualisierungssystem integriert sind, lädt jede Aktualisierung alle Konfigurationen aus allen Stores neu. Sie können das Aktualisierungsintervall auf ein beliebiges Intervall festlegen, das länger als 1 Sekunde ist. Die unterstützten Einheiten für das Aktualisierungsintervall sind s, mhund d für Sekunden, Minuten, Stunden und Tage. Im folgenden Beispiel wird das Aktualisierungsintervall auf 5 Minuten festgelegt:

spring.cloud.azure.appconfiguration.stores[0].monitoring.feature-flag-refresh-interval= 5m

Gesundheitsindikator

Die Client-Bibliothek verfügt über eine Zustandsanzeige, die prüft, ob die Verbindung zum Azure App Configuration Store oder zu den Stores intakt ist. Wenn sie für jeden Speicher aktiviert ist, erhält er einen der folgenden Statuswerte:

  • UP : Die letzte Verbindung war erfolgreich.
  • DOWN- Die letzte Verbindung führte zu einem Fehlercode ungleich 200. Dieser Status kann auf Probleme zurückzuführen sein, die von ablaufenden Anmeldeinformationen bis hin zu einem Dienstproblem reichen. Die Clientbibliothek versucht automatisch, eine Verbindung mit dem Speicher im nächsten Aktualisierungsintervall herzustellen.
  • NICHT GELADEN – Der Konfigurationsspeicher wird in der lokalen Konfigurationsdatei aufgeführt, der Konfigurationsspeicher wurde jedoch nicht aus der Datei beim Start geladen. Der Konfigurationsspeicher ist in der Konfigurationsdatei deaktiviert oder die Konfiguration oder die Konfigurationen konnten beim Start nicht geladen werden, während die fail-fast -Konfiguration für den Speicher auf falsegesetzt war.

Sie können den Gesundheitsindikator aktivieren, indem Sie management.health.azure-app-configuration.enabled=true setzen.

Anpassung des Clients

Die App-Konfigurationsbibliothek verwendet das Azure SDK für Java zum Herstellen einer Verbindung mit Azure-App Configuration und Azure Key Vault. Es werden zwei Schnittstellen ConfigurationClientCustomizer und SecretClientCustomizerzum Ändern der Clients bereitgestellt. Jede Schnittstelle verfügt über eine customize Methode, die den jeweiligen Generator zusammen mit dem String Wert des URI verwendet, für den der Client konfiguriert wird, wie in den folgenden Schnittstellendefinitionen gezeigt:

public interface ConfigurationClientCustomizer {
    public void customize(ConfigurationClientBuilder builder, String endpoint);
}

public interface SecretClientCustomizer {
    public void customize(SecretClientBuilder builder, String endpoint);
}

Diese Schnittstellen ermöglichen die Anpassung des HTTP-Clients und seiner Konfigurationen. Im folgenden Beispiel wird der Standardwert HttpClient durch einen anderen ersetzt, der einen Proxy für den gesamten Datenverkehr verwendet, der an die App-Konfiguration und den Key Vault weitergeleitet wird.

Hinweis

Die ConfigurationClientBuilder und SecretClientBuilder sind bereits für die Verwendung eingerichtet, wenn sie in customize übergeben werden. Alle Änderungen an den Clients, einschließlich der Anmeldeinformationen und der Wiederholungsrichtlinie, setzen die Standardeinstellungen außer Kraft.

Sie können diese Konfiguration auch mithilfe der Spring Cloud Azure-Konfiguration ausführen.

public class CustomClient implements ConfigurationClientCustomizer, SecretClientCustomizer {

    @Override
    public void customize(ConfigurationClientBuilder builder, String endpoint) {
        builder.httpClient(buildHttpClient());
    }

    @Override
    public void customize(SecretClientBuilder builder, String endpoint) {
        builder.httpClient(buildHttpClient());
    }

    private HttpClient buildHttpClient() {
        String hostname = System.getProperty("https.proxyHosts");
        String portString = System.getProperty("https.proxyPort");
        int port = Integer.valueOf(portString);

        ProxyOptions proxyOptions = new ProxyOptions(ProxyOptions.Type.HTTP,
                new InetSocketAddress(hostname, port));
        return new NettyAsyncHttpClientBuilder()
                .proxy(proxyOptions)
                .build();
    }

}
  • Last updated on