Verwenden des Anwendungskonfigurationsdiensts für Tanzu

  • Artikel

Hinweis

Azure Spring Apps ist der neue Name für den Azure Spring Cloud-Dienst. Obwohl der Dienst umbenannt wurde, wird der alte Name noch an einigen Stellen verwendet, solange wir Ressourcen wie Screenshots, Videos und Diagramme aktualisieren.

Dieser Artikel gilt für:❌ Basic/Standard ✔️ Enterprise

In diesem Artikel erfahren Sie, wie Sie den Anwendungskonfigurationsdienst für VMware Tanzu mit dem Azure Spring Apps Enterprise-Plan verwenden.

Der Anwendungskonfigurationsdienst für VMware Tanzu ist eine der kommerziellen VMware-Komponenten. Er ermöglicht die Verwaltung von Kubernetes-nativen ConfigMap-Ressourcen, die aus Eigenschaften mit Daten aufgefüllt werden, die in mindestens einem Git-Repository definiert sind.

Mit dem Anwendungskonfigurationsdienst erhalten Sie einen zentralen Ort, um externe Eigenschaften für Anwendungen in allen Umgebungen zu verwalten. Informationen zu den Unterschieden zwischen Spring Cloud Config Server im Basic- und Standard-Plan finden Sie unter Migrieren einer Azure Spring Apps-Instanz in dem Basic- oder Standard-Plan zum Enterprise-Plan im Abschnitt Verwenden des Anwendungskonfigurationsdiensts für die externe Konfiguration.

Der Anwendungskonfigurationsdienst wird in zwei Versionen angeboten: Gen1 und Gen2. Die Gen1-Version dient hauptsächlich vorhandenen Kunden zur Abwärtskompatibilität und wird nur bis zum 30. April 2024 unterstützt. Neue Dienstinstanzen sollten Gen2 verwenden. Die Gen2-Version verwendet Flux als Back-End für die Kommunikation mit Git-Repositorys und bietet eine bessere Leistung im Vergleich zu Gen1.

Die folgende Tabelle zeigt die Unterkomponentenbeziehungen:

Generierung des Anwendungskonfigurationsdienstes Unterkomponenten
Gen1 application-configuration-service
Gen2 application-configuration-service
flux-source-controller

In der folgenden Tabelle sind einige Benchmarkdaten für Sie als Referenz aufgeführt. Die Größe des Git-Repositorys ist jedoch ein wichtiger Faktor, der erhebliche Auswirkungen auf die Leistungsdaten hat. Es wird empfohlen, nur die erforderlichen Konfigurationsdateien im Git-Repository zu speichern, um es klein zu halten.

Generierung des Anwendungskonfigurationsdienstes Dauer der Aktualisierung bei weniger als 100 Mustern Dauer der Aktualisierung bei weniger als 250 Mustern Dauer der Aktualisierung bei weniger als 500 Mustern
Gen1 330 s 840 s 1500 s
Gen2 13 s 100 s 378 s

Gen2 bietet auch mehr Sicherheitsüberprüfungen, wenn Sie eine Verbindung mit einem Remote-Git-Repository herstellen. Gen2 erfordert eine sichere Verbindung, wenn Sie HTTPS verwenden, und überprüft den richtigen Hostschlüssel und Hostalgorithmus bei Verwendung einer SSH-Verbindung.

Sie können die Version des Anwendungskonfigurationsdiensts auswählen, wenn Sie eine Azure Spring Apps Enterprise-Dienstinstanz erstellen. Die Standardversion ist Gen1. Sie können auch ein Upgrade auf Gen2 durchführen, nachdem die Instanz erstellt wurde, aber eine Herabstufung wird nicht unterstützt. Beim Upgrade gibt es keine Ausfallzeit, es wird jedoch weiterhin empfohlen, es in einer Stagingumgebung zu testen, bevor Sie es in eine Produktionsumgebung verschieben.

Voraussetzungen

Verwalten von Anwendungskonfigurationsdiensteinstellungen

Der Anwendungskonfigurationsdienst unterstützt Azure DevOps, GitHub, GitLab und Bitbucket zum Speichern Ihrer Konfigurationsdateien.

Um die Diensteinstellungen zu verwalten, öffnen Sie den Abschnitt Einstellungen. Im diesem Abschnitt können Sie die folgenden Schlüsselpunkte konfigurieren:

  • Generation: Upgrade der Dienstgeneration.
  • Aktualisierungsintervall: Anpassen der Häufigkeit, mit der der Dienst in Git-Repositorys nach Updates sucht.
  • Repositorys: Hinzufügen neuer Einträge oder Ändern vorhandener Repositorys. Mit dieser Funktion können Sie steuern, welche Repositorys die Dienstüberwachung zum Abrufen von Daten verwenden.

Screenshot: Seite „Anwendungskonfigurationsdienst“ im Azure-Portal mit hervorgehobener Registerkarte „Einstellungen“

Wenn Sie aktuell mit der Dienstgenereration Gen1 arbeiten, können Sie ein Upgrade auf Gen2 durchführen, um eine bessere Leistung zu erzielen. Weitere Informationen finden Sie im Abschnitt Upgrade von Gen1 auf Gen2.

Das Aktualisierungsintervall gibt die Häufigkeit zum Überprüfen von Updates im Repository an (in Sekunden). Der Mindestwert ist 0, wodurch die automatische Aktualisierung deaktiviert wird. Legen Sie dieses Intervall für eine optimale Leistung auf einen Minimalwert von 60 Sekunden fest.

Die Eigenschaften für jeden Repositoryeintrag werden in der folgenden Tabelle beschrieben.

Eigenschaft Erforderlich? BESCHREIBUNG
Name Ja Ein eindeutiger Name zum Bezeichnen der einzelnen Git-Repositorys.
Patterns Ja Die Muster für die Suche in Git-Repositorys. Verwenden Sie für jedes Muster ein Format wie {application} oder {application}/{profile} anstelle von {application}-{profile}.yml. Trennen Sie die Muster durch Kommas. Weitere Informationen finden Sie im Abschnitt Muster in diesem Artikel.
URI Ja Ein Git-URI (z. B https://github.com/Azure-Samples/piggymetrics-config oder git@github.com:Azure-Samples/piggymetrics-config)
Label Ja Der Branchname für die Suche im Git-Repository
Search path No Optionale Suchpfade (durch Kommas getrennt) zum Durchsuchen von Unterverzeichnissen des Git-Repositorys.

Muster

Die Konfiguration wird aus Git-Back-Ends mithilfe der Definition abgerufen, die Sie in einem Muster festgelegt haben. Ein Muster ist eine Kombination aus {application}/{profile}, wie in den folgenden Anweisungen beschrieben.

  • {application} – Der Name einer Anwendung, deren Konfiguration Sie abrufen. Der Wert application gilt als Standardanwendung und enthält die Konfigurationsinformationen, die von mehreren Anwendungen gemeinsam genutzt werden. Jeder andere Wert verweist auf eine bestimmte Anwendung an und enthält Eigenschaften sowohl für die angegebene Anwendung als auch gemeinsam verwendete Eigenschaften für die Standardanwendung.
  • {profil}: Optional. Der Name eines Profils, dessen Eigenschaften Sie abrufen können. Ein leerer Wert oder der Wert default beinhaltet Eigenschaften, die für alle Profile gemeinsam verwendet werden. Nicht standardmäßige Werte enthalten Eigenschaften für das angegebene Profil und Eigenschaften für das Standardprofil.

Authentifizierung

Der folgende Screenshot zeigt die drei Arten von Repository-Authentifizierung, die vom Anwendungskonfigurationsdienst unterstützt werden.

Screenshot: Seite „Anwendungskonfigurationsdienst“ im Azure-Portal mit hervorgehobenem Menü „Authentifizierungstyp“

In der folgenden Liste werden die drei Authentifizierungstypen beschrieben:

  • Öffentliches Repository.

    Sie benötigen keine zusätzliche Authentifizierungskonfiguration, wenn Sie ein öffentliches Repository verwenden. Wählen Sie im Formular Authentifizierung die Option Öffentlich aus.

    In der folgenden Tabelle sind die konfigurierbaren Eigenschaften angezeigt, die Sie zum Einrichten eines öffentlichen Git-Repositorys verwenden können:

    Eigenschaft Erforderlich? Beschreibung
    CA certificate Nein Nur erforderlich, wenn ein selbstsigniertes Zertifikat für die Git-Repository-URL verwendet wird.

  • Privates Repository mit Standardauthentifizierung.

    Die folgende Tabelle enthält die konfigurierbaren Eigenschaften, die Sie zum Einrichten eines privaten Git-Repositorys mit Standardauthentifizierung verwenden können:

    Eigenschaft Erforderlich? BESCHREIBUNG
    username Ja Der Benutzername, der für den Zugriff auf das Repository verwendet wird.
    password Ja Das Kennwort, das für den Zugriff auf das Repository verwendet wird.
    CA certificate Nein Nur erforderlich, wenn ein selbstsigniertes Zertifikat für die Git-Repository-URL verwendet wird.

  • Privates Repository mit SSH-Authentifizierung.

    Die folgende Tabelle enthält die konfigurierbaren Eigenschaften, die Sie zum Einrichten eines privaten Git-Repositorys mit SSH verwenden können:

    Eigenschaft Erforderlich? BESCHREIBUNG
    Private key Ja Der private Schlüssel, der den Git-Benutzer identifiziert. Mit einer Passphrase verschlüsselte private Schlüssel werden nicht unterstützt.
    Host key Nein zu Gen1
    Ja zu Gen2    		 Der Hostschlüssel des Git-Servers. Wenn Sie über Git über die Befehlszeile eine Verbindung mit dem Server hergestellt haben, befindet sich der Hostschlüssel in Ihrer SSH/known_hosts-Datei. Schließen Sie das Algorithmuspräfix nicht ein, da es in Host key algorithm angegeben wird.
    Host key algorithm Nein zu Gen1
    Ja zu Gen2    		 Der Algorithmus für hostKey: einer der Werte ssh-dss, ssh-rsa, ecdsa-sha2-nistp256, ecdsa-sha2-nistp384 oder ecdsa-sha2-nistp521. (Erforderlich, wenn Host key angegeben wird).
    Strict host key checking Nein Optionaler Wert, der angibt, ob das Back-End ignoriert werden soll, wenn bei Verwendung des bereitgestellten Host key ein Fehler auftritt. Gültige Werte sind true und false. Der Standardwert ist true.

Wählen Sie zum Überprüfen des Zugriffs auf den Ziel-URI die Option Überprüfen aus. Wählen Sie nach erfolgreichem Abschluss der Überprüfung Anwenden aus, um die Konfigurationseinstellungen zu aktualisieren.

Upgrade von Gen1 auf Gen2

Der Anwendungskonfigurationsdienst Gen2 bietet eine bessere Leistung im Vergleich zu Gen1, insbesondere wenn Sie über eine große Anzahl von Konfigurationsdateien verfügen. Wir empfehlen die Verwendung von Gen2, insbesondere weil Gen1 bald eingestellt wird. Beim Upgrade von Gen1 auf Gen2 gibt es keine Ausfallzeit, es wird jedoch weiterhin empfohlen, dass Sie in einer Stagingumgebung testen, bevor Sie zu einer Produktionsumgebung wechseln.

Gen2 erfordert mehr Konfigurationseigenschaften als Gen1 bei Verwendung der SSH-Authentifizierung. Sie müssen die Konfigurationseigenschaften in Ihrer Anwendung aktualisieren, damit sie mit Gen2 funktioniert. Die folgende Tabelle zeigt die erforderlichen Eigenschaften für Gen2 bei Verwendung der SSH-Authentifizierung:

Eigenschaft Beschreibung
Host key Der Hostschlüssel des Git-Servers. Wenn Sie über Git über die Befehlszeile eine Verbindung mit dem Server hergestellt haben, befindet sich der Hostschlüssel in Ihrer SSH/known_hosts-Datei. Schließen Sie das Algorithmuspräfix nicht ein, da es in Host key algorithm angegeben wird.
Host key algorithm Der Algorithmus für hostKey: Einer von ssh-dss, ssh-rsa, ecdsa-sha2-nistp256, ecdsa-sha2-nistp384 oder ecdsa-sha2-nistp521.

Führen Sie die folgenden Schritte aus, um ein Upgrade von Gen1 auf Gen2 durchzuführen:

  1. Navigieren Sie im Azure-Portal zur Seite „Anwendungskonfigurationsdienst“ für Ihre Azure Spring Apps-Dienstinstanz.

  2. Wählen Sie den Abschnitt Einstellungen und dann im Dropdownmenü Generation die Option Gen2 aus.

    Screenshot: Seite „Anwendungskonfigurationsdienst“ im Azure-Portal mit Registerkarte „Einstellungen“ und geöffnetem Menü „Generation“

  3. Wählen Sie zum Überprüfen des Zugriffs auf den Ziel-URI die Option Überprüfen aus. Wählen Sie nach erfolgreichem Abschluss der Überprüfung Anwenden aus, um die Konfigurationseinstellungen zu aktualisieren.

    Screenshot: Seite „Anwendungskonfigurationsdienst“ im Azure-Portal mit Registerkarte „Einstellungen“ und hervorgehobener Schaltfläche „Überprüfen“

Polyglot-Unterstützung

Der Anwendungskonfigurationsdienst arbeitet nahtlos mit Spring Boot-Anwendungen zusammen. Die vom Dienst generierten Eigenschaften werden als externe Konfigurationen von Spring Boot importiert und in die Beans eingefügt. Sie müssen keinen zusätzlichen Code schreiben. Sie können die Werte verwenden, indem Sie die @Value-Anmerkung verwenden, auf die über die Spring Environment Abstraktion zugegriffen wird, oder Sie können sie mithilfe der @ConfigurationProperties-Anmerkung an strukturierte Objekte binden.

Der Anwendungskonfigurationsdienst unterstützt auch Polyglot-Apps wie dotNET, Go, Python usw. Um auf Konfigurationsdateien zuzugreifen, die Sie während der Polyglot-App-Bereitstellung in den Apps angeben, versuchen Sie, auf einen Dateipfad zuzugreifen, den Sie über eine Umgebungsvariable mit einem Namen wie AZURE_SPRING_APPS_CONFIG_FILE_PATH abrufen können. Sie können auf alle gewünschten Konfigurationsdateien unter diesem Pfad zugreifen. Verwenden Sie die vorhandenen Lese-/Schreibdateibibliotheken für Ihre App, um auf die Eigenschaftswerte in den Konfigurationsdateien zuzugreifen.

Aktualisierungsstrategien

Wenn Sie Ihre Konfigurationen in einem Git-Repository ändern und übertragen, sind mehrere Schritte erforderlich, bevor sich diese Änderungen in Ihren Anwendungen widerspiegeln. Dieser Prozess ist zwar automatisiert, umfasst jedoch die folgenden einzelnen Phasen und Komponenten, die jeweils ihren eigenen Zeitplan und ihr eigenes Verhalten haben:

  • Abfrage durch den Anwendungskonfigurationsdienst: Der Application Configuration Service fragt regelmäßig die Back-End Git Repositorys ab, um Änderungen zu erkennen. Diese Abfrage erfolgt in einer bestimmten Frequenz, die durch das Aktualisierungsintervall definiert ist. Wenn eine Änderung erkannt wird, aktualisiert der Anwendungskonfigurationsdienst die Kubernetes-ConfigMap.
  • ConfigMap-Aktualisierung und Interaktion mit dem Kubelet-Cache: In Azure Spring Apps wird ConfigMap als Datenvolumen in die jeweilige Anwendung eingebunden. Allerdings gibt es bei diesem Prozess eine natürliche Verzögerung, die auf die Häufigkeit zurückzuführen ist, mit der das Kubelet seinen Cache aktualisiert, um Änderungen in ConfigMap zu erkennen.
  • Anwendung liest aktualisierte Konfiguration: Ihre Anwendung, die in der Azure Spring Apps-Umgebung läuft, kann auf die aktualisierten Konfigurationswerte zugreifen. Die vorhandenen Beans im Spring-Kontext werden nicht automatisch auf die aktualisierten Konfigurationen aktualisiert.

Diese Stages wird im folgenden Diagramm zusammengefasst:

Diagramm, das den Lebenszyklus des Aktualisierungsprozesses des Anwendungskonfigurationsdiensts zeigt

Sie können das Aktualisierungsintervall für die Abfrage des Anwendungskonfigurationsdienstes an Ihre speziellen Bedürfnisse anpassen. Um die aktualisierten Konfigurationen in Ihrer Anwendung anzuwenden, ist ein Neustart oder eine Aktualisierung erforderlich.

In Spring-Anwendungen werden Eigenschaften als Beans innerhalb des Spring-Kontextes gehalten oder referenziert. Um neue Konfigurationen zu laden, können Sie die folgenden Methoden verwenden:

  • Starten Sie die Anwendung neu. Beim Neustart der Anwendung wird immer die neue Konfiguration geladen.

  • Rufen Sie den Endpunkt /actuator/refresh auf, der auf dem Konfigurationsclient über den Spring-Aktuator bereitgestellt wird.

    Um diese Methode zu verwenden, fügen Sie der Datei pom.xml Ihres Konfigurationsclients die folgende Abhängigkeit hinzu:

    <dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

    Sie können den Aktuatorendpunkt auch aktivieren, indem Sie die folgende Konfiguration hinzufügen:

    management.endpoints.web.exposure.include=refresh, bus-refresh, beans, env

    Nach dem erneuten Laden der Eigenschaftenquellen durch Aufrufen des Endpunkts /actuator/refresh werden die an @Value in den Beans mit der Anmerkung @RefreshScope gebundenen Attribute aktualisiert.

    @Service
@Getter @Setter
@RefreshScope
public class MyService {
   @Value
   private Boolean activated;
}

    Verwenden Sie curl mit dem Anwendungsendpunkt, um die neue Konfiguration zu aktualisieren, wie im folgenden Beispiel gezeigt:

    curl -X POST http://{app-endpoint}/actuator/refresh

  • Verwenden Sie FileSystemWatcher, um die Dateiänderung zu beobachten und den Kontext bei Bedarf zu aktualisieren. FileSystemWatcher ist eine mit spring-boot-devtools bereitgestellte Klasse, die bestimmte Verzeichnisse auf Dateiänderungen überwacht. Alternativ können Sie ein anderes Dienstprogramm mit ähnlicher Funktion verwenden. Bei der ersten Option muss die Aktualisierung aktiv angestoßen werden, während bei der zweiten Option die Dateien überwacht werden können und die Aktualisierung automatisch aufgerufen wird, sobald Aktualisierungen erkannt werden. Sie können den Dateipfad mit Hilfe der Umgebungsvariablen AZURE_SPRING_APPS_CONFIG_FILE_PATH abrufen, wie im Abschnitt über die Polyglot-Unterstützung erwähnt.

Konfigurieren der Einstellungen des Anwendungskonfigurationsdienstes

Führen Sie die folgenden Schritte aus, um den Anwendungskonfigurationsdienst zu konfigurieren:

  1. Wählen Sie Anwendungskonfigurationsdienst aus.

  2. Wählen Sie Übersicht aus, um den Ausführungsstatus und die Ressourcen anzuzeigen, die dem Anwendungskonfigurationsdienst zugeordnet sind.

    Screenshot: Seite „Anwendungskonfigurationsdienst“ im Azure-Portal mit hervorgehobener Registerkarte „Übersicht“

  3. Wählen Sie Einstellungen aus, und fügen Sie im Abschnitt Repositorys einen neuen Eintrag mit den Git-Back-End-Informationen hinzu.

  4. Wählen Sie zum Überprüfen des Zugriffs auf den Ziel-URI die Option Überprüfen aus. Wählen Sie nach erfolgreichem Abschluss der Überprüfung Anwenden aus, um die Konfigurationseinstellungen zu aktualisieren.

    Screenshot: Seite „Anwendungskonfigurationsdienst“ im Azure-Portal mit hervorgehobener Registerkarte „Einstellungen“ und hervorgehobener Schaltfläche „Überprüfen“

Konfigurieren des TLS-Zertifikats für den Zugriff auf das Git-Back-End mit einem selbstsignierten Zertifikat für Gen2

Dieser Schritt ist optional. Wenn Sie ein selbstsigniertes Zertifikat für das Git-Back-End verwenden, müssen Sie das TLS-Zertifikat für den Zugriff auf das Git-Back-End konfigurieren.

Sie müssen das Zertifikat zuerst in Azure Spring Apps hochladen. Weitere Informationen finden Sie im Abschnitt Importieren eines Zertifikats von Verwendung von TLS/SSL-Zertifikaten in Ihrer Anwendung in Azure Spring Apps.

Führen Sie die folgenden Schritte aus, um das TLS-Zertifikat zu konfigurieren:

  1. Navigieren Sie zu Ihrer Dienstressource und wählen Sie dann den Anwendungskonfigurationsdienst aus.

  2. Wählen Sie Einstellungen aus und fügen Sie im Abschnitt Repositorys einen neuen Eintrag mit den Git-Back-End-Informationen hinzu oder aktualisieren Sie ihn.

    Screenshot: Seite „Anwendungskonfigurationsdienst“ im Azure-Portal mit Registerkarte „Einstellungen“

Verwenden des Application Configuration Service (Anwendungskonfigurationsdienst) mit Anwendungen

Wenn Sie den Anwendungskonfigurationsdienst mit einem Git-Back-End und die zentralisierten Konfigurationen verwenden, müssen Sie die App an den Anwendungskonfigurationsdienst binden.

Verwenden Sie den folgenden Befehl, um den Anwendungskonfigurationsdienst mit Anwendungen zu verwenden:

  1. Öffnen Sie die Registerkarte App-Bindung.

  2. Wählen Sie App binden und wählen Sie eine App aus der Dropdown-Liste. Wählen Sie Anwenden aus, um die Bindung zu aktivieren.

    Screenshot: Seite „Anwendungskonfigurationsdienst“ im Azure-Portal mit hervorgehobener Registerkarte „App-Bindung“

    Hinweis

    Wenn Sie den Bindungsstatus ändern, müssen Sie die App neu starten oder erneut bereitstellen, damit die Bindung wirksam wird.

  3. Wählen Sie im Navigationsmenü Apps aus, um die Liste aller Apps anzuzeigen.

  4. Wählen Sie die Zielanwendung, um Muster für die Spalte name zu konfigurieren.

  5. Wählen Sie im linken Navigationsbereich Konfiguration und dann Allgemeine Einstellungen aus.

  6. Wählen Sie in der Dropdownliste Konfigurationsmuster mindestens ein Muster aus der Liste aus. Weitere Informationen finden Sie im Abschnitt Muster.

    Screenshot: Seite „App-Konfiguration“ im Azure-Portal mit hervorgehobener Registerkarte „Allgemeine Einstellungen“ und hervorgehobenen Optionen für „api-gateway“

  7. Wählen Sie Speichern.

Binden einer App an den Anwendungskonfigurationsdienst

Sie können ihre Anwendung jetzt beim Erstellen einer neuen App an den Anwendungskonfigurationsdienst binden.

Führen Sie die folgenden Schritte aus, um eine neue App zu erstellen und an den Anwendungskonfigurationsdienst zu binden:

  1. Wählen Sie im Navigationsbereich Apps aus, um alle Ihre Apps anzuzeigen.

  2. Wählen Sie App erstellen aus, um eine neue App zu erstellen.

  3. Geben Sie einen Namen für Ihre neue App ein.

  4. Wählen Sie die Registerkarte Binden und dann Anwendungskonfigurationsdienst aus der Dropdownliste aus.

    Screenshot: Seite „App erstellen“ im Azure-Portal mit hervorgehobenem Dropdownmenü „Bindung“

  5. Wählen Sie Erstellen aus, um die Erstellung Ihrer App abzuschließen und sie an den Anwendungskonfigurationsdienst zu binden.

Aktivieren/Deaktivieren des Anwendungskonfigurationsdiensts nach der Diensterstellung

Sie können den Anwendungskonfigurationsdienst nach der Diensterstellung über das Azure-Portal oder die Azure CLI aktivieren und deaktivieren. Bevor Sie den Anwendungskonfigurationsdienst deaktivieren, müssen Sie die Verknüpfung aller Apps daraus aufheben.

Führen Sie die folgenden Schritte aus, um den Anwendungskonfigurationsdienst zu aktivieren oder zu deaktivieren:

  1. Navigieren Sie zu Ihrer Dienstressource und wählen Sie dann den Anwendungskonfigurationsdienst aus.
  2. Wählen Sie Verwalten aus.
  3. Wählen Sie Anwendungskonfigurationsdienst aktivieren oder deaktivieren aus, und wählen Sie dann Speichern aus.
  4. Sie können nun den Status des Anwendungskonfigurationsdiensts auf der Seite Anwendungskonfigurationsdienst anzeigen.

Überprüfen der Konfigurationsdatei in ConfigMap

Im folgenden Abschnitt wird gezeigt, wie Sie den Inhalt der Konfigurationsdatei untersuchen, die vom Anwendungskonfigurationsdienst aus Git-Upstreamrepositorys im zugehörigen Kubernetes-ConfigMap-Objekt gepullt werden. Weitere Informationen finden Sie im Abschnitt Aktualisierungsstrategien dieses Artikels.

Zuweisen einer Azure-Rolle

Zunächst muss Ihnen die Azure-Rolle Azure Spring Apps Application Configuration Service Config File Pattern Reader Role zugewiesen werden.

Führen Sie die folgenden Schritte aus, um eine Azure-Rolle zuzuweisen:

  1. Öffnen Sie das Azure-Portal, und navigieren Sie zu Ihrer Azure Spring Apps-Dienstinstanz.

  2. Wählen Sie im Navigationsbereich Zugriffssteuerung (IAM) aus.

  3. Wählen Sie auf der Seite Zugriffssteuerung (IAM) die Option Hinzufügen und dann Rollenzuweisung hinzufügen aus.

    Screenshot: Azure-Portal, in dem die Registerkarte „Zugriffssteuerung (IAM)“ für eine Azure Spring Apps-Instanz angezeigt wird und die Option „Rollenzuweisung hinzufügen“ hervorgehoben ist

  4. Suchen Sie auf der Seite Rollenzuweisung hinzufügen in der Liste Name die Zielrolle, und wählen Sie sie und anschließend Weiter aus.

    Screenshot: Azure-Portal mit der Seite „Rollenzuweisung hinzufügen“ für eine Azure Spring Apps-Instanz mit hervorgehobenem Namen „Azure Spring Apps-Leserrolle für das Konfigurationsdateimuster des Anwendungskonfigurationsdiensts“

  5. Wählen Sie Mitglieder aus, suchen Sie nach Ihrem Benutzernamen, und wählen Sie diesen dann aus.

  6. Wählen Sie Überprüfen und zuweisen aus.

Überprüfen der Konfigurationsdatei mit der Azure CLI

Führen Sie den folgenden Befehl aus, um den Inhalt der Konfigurationsdatei nach Muster anzuzeigen:

az spring application-configuration-service config show \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --config-file-pattern <pattern>

Dieser Befehl erzeugt eine JSON-Ausgabe ähnlich wie im folgenden Beispiel:

{
  "configurationFiles": {
    "application.properties": [
      "example.property.application.name: example-service",
      "example.property.cloud: Azure"
    ]
  },
  "metadata": {
    "gitRevisions": "[{\"url\":\"{gitRepoUrl}\",\"revision\":\"{revisionInfo}\"}]"
  }
}

Hinweis

Die Eigenschaften metadata und gitRevisions sind für die Gen1-Version des Anwendungskonfigurationsdiensts nicht verfügbar.

Sie können diesen Befehl auch mit dem Parameter --export-path {/path/to/target/folder} verwenden, um die Konfigurationsdatei in den angegebenen Ordner zu exportieren. Er unterstützt sowohl relative Pfade als auch absolute Pfade. Wenn Sie den Pfad nicht angeben, verwendet der Befehl standardmäßig den Pfad des aktuellen Verzeichnisses.

Überprüfen der Konfigurationsdatei in der App

Nachdem Sie die App an den Anwendungskonfigurationsdienst gebunden und das Muster für die App-Bereitstellung festgelegt haben, wie im Abschnitt Verwenden des Anwendungskonfigurationsdiensts mit Anwendungen dieses Artikels beschrieben, sollte das ConfigMap-Objekt, das die Konfigurationsdatei für das Muster enthält, in den Anwendungscontainer eingebunden werden. Führen Sie die folgenden Schritte aus, um die Konfigurationsdateien in allen Instanzen der App-Bereitstellung zu überprüfen:

  1. Stellen Sie eine Verbindung mit einer der Anwendungsinstanzen her. Weitere Informationen finden Sie unter Herstellen einer Verbindung mit einer App-Instanz zur Problembehandlung.

  2. Verwenden Sie den Befehl echo $AZURE_SPRING_APPS_CONFIG_FILE_PATH, um die Ordner zu finden, die die Konfigurationsdateien enthalten. Eine Liste der Speicherorte wird durch Kommas getrennt angezeigt, wie im folgenden Beispiel gezeigt:

      $ echo $AZURE_SPRING_APPS_CONFIG_FILE_PATH
  /etc/azure-spring-cloud/configmap/acs-default-payment-default-e9d46,/etc/azure-spring-cloud/configmap/acs-default-catalog-default-616f4

  3. Überprüfen Sie den Inhalt der Konfigurationsdatei mithilfe von Befehlen wie cat.

Hinweis

Die Git-Überarbeitungsinformationen sind in der App nicht verfügbar.

Überprüfen der Protokolle

In den folgenden Abschnitten wird gezeigt, wie Anwendungsprotokolle mithilfe der Azure CLI oder des Azure-Portals angezeigt werden.

Verwenden des Echtzeitprotokollstreamings

Sie können Protokolle in Echtzeit mit der Azure CLI streamen. Weitere Informationen finden Sie in Echtzeit unter Verwaltete Komponentenprotokolle von Stream Azure Spring Apps. Die folgenden Beispiele zeigen, wie Sie Azure CLI-Befehle verwenden können, um fortlaufend neue Protokolle für application-configuration-service- und flux-source-controller-Unterkomponenten zu streamen.

Verwenden Sie den folgenden Befehl, um Protokolle zu streamen für application-configuration-service:

az spring component logs \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name application-configuration-service \
    --all-instances \
    --follow

Verwenden Sie den folgenden Befehl, um Protokolle zu streamen für flux-source-controller:

az spring component logs \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name flux-source-controller \
    --all-instances \
    --follow

Verwenden von Log Analytics

In den folgenden Abschnitten erfahren Sie, wie Sie Systemprotokolle mithilfe von Log Analytics aktivieren und anzeigen.

Diagnoseeinstellung für Log Analytics

Sie müssen Systemprotokolle aktivieren und die Protokolle an Ihre Log Analytics-Instanz senden, bevor Sie die Protokolle für den Anwendungskonfigurationsdienst abfragen. Führen Sie die folgenden Schritte aus, um Systemprotokolle im Azure-Portal zu aktivieren:

  1. Öffnen Sie Ihre Azure Spring Apps-Instanz.

  2. Wählen Sie im Navigationsbereich die Diagnoseeinstellungen aus.

  3. Wählen Sie Diagnoseeinstellung hinzufügen oder Einstellung bearbeiten für eine vorhandene Einstellung aus.

  4. Wählen Sie im Abschnitt Protokolle die Kategorie Systemprotokolle aus.

  5. Wählen Sie im Abschnitt Zieldetails die Option An Log Analytics-Arbeitsbereich senden und dann Ihren Arbeitsbereich aus.

  6. Wählen Sie Speichern aus, um die Einstellung zu aktualisieren.

Überprüfen von Protokollen in Log Analytics

Führen Sie die folgenden Schritte aus, um die Protokolle von application-configuration-service und flux-source-controller im Azure-Portals zu überprüfen zu verwenden:

  1. Stellen Sie sicher, dass Sie Systemprotokolle aktiviert haben. Weitere Informationen finden Sie im Abschnitt Diagnoseeinstellungen für Log Analytics.

  2. Öffnen Sie Ihre Azure Spring Apps-Instanz.

  3. Wählen Sie im Navigationsmenü Protokolle und dann Übersicht aus.

  4. Verwenden Sie die folgenden Beispielabfragen im Abfragebearbeitungsbereich. Passen Sie den Zeitraum an und wählen Sie dann Ausführen aus, um nach Protokollen zu suchen.

    • Verwenden Sie die folgende Abfrage, um die Protokolle für application-configuration-service anzuzeigen:

      AppPlatformSystemLogs
| where LogType in ("ApplicationConfigurationService")
| project TimeGenerated , ServiceName , LogType, Log , _ResourceId
| limit 100

      Screenshot: Azure-Portal mit dem Abfrageergebnis für Protokolle für application-configuration-service.

    • Verwenden Sie die folgende Abfrage, um die Protokolle für flux-source-controller anzuzeigen:

      AppPlatformSystemLogs
| where LogType in ("Flux")
| project TimeGenerated , ServiceName , LogType, Log , _ResourceId
| limit 100

      Screenshot: Azure-Portal mit dem Abfrageergebnis für Protokolle für flux-source-controller.

Hinweis

Es kann möglicherweise ein paar Minuten dauern, bis die Protokolle in Log Analytics verfügbar sind.

Problembehandlung für bekannte Probleme

Wenn die letzten Änderungen nicht in den Anwendungen übernommen wurden, überprüfen Sie die folgenden Punkte anhand des Abschnitts Aktualisierungsstrategien :

  • Vergewissern Sie sich, dass das Git Repo korrekt aktualisiert wurde, indem Sie die folgenden Punkte überprüfen:
    • Vergewissern Sie sich, dass der Branch mit den gewünschten Änderungen der Konfigurationsdatei aktualisiert wird.
    • Bestätigen Sie, dass das im Anwendungskonfigurationsdienst konfigurierte Muster mit den aktualisierten Konfigurationsdateien übereinstimmt.
    • Bestätigen Sie, dass die Anwendung an den Anwendungskonfigurationsdienst gebunden ist.
  • Vergewissern Sie sich, dass das ConfigMap-Objekt, das die Konfigurationsdatei für das von der Anwendung verwendete Muster enthält, aktualisiert wird, wie im Abschnitt Überprüfen der Konfigurationsdatei in ConfigMap dieses Artikels beschrieben. Wenn sie nicht aktualisiert wurde, erstellen Sie ein Ticket.
  • Vergewissern Sie sich, dass ConfigMap als Datei in die Anwendung eingebunden wird, wie im Abschnitt Überprüfen der Konfigurationsdatei in der App dieses Artikels beschrieben. Wenn die Datei nicht aktualisiert wurde, warten Sie das Aktualisierungsintervall von Kubernetes ab (1 Minute) oder erzwingen Sie eine Aktualisierung, indem Sie die Anwendung neu starten.

Nachdem Sie diese Punkte überprüft haben, sollten die Anwendungen in der Lage sein, die aktualisierten Konfigurationen zu lesen. Wenn die Anwendungen immer noch nicht aktualisiert wurden, erstellen Sie ein Ticket.

Zugehöriger Inhalt

Azure Spring Apps