Microservices mit Spring Cloud, Teil 3 Microservice-Konfiguration per Config Server

Der Betrieb von Microservices hat allein schon wegen der Masse an verschiedenen Diensten seine eigenen Tücken. Eine zentralisierte Konfiguration mit dem Spring Config Server nimmt einem viel Arbeit ab.

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

In Spring Boot-Anwendungen wird die Konfiguration getrennt vom Code in den Dateien application.properties oder application.yml aufbewahrt; im Normalfall werden sie dann aber trotzdem zusammen in einer Jar-Datei paketiert. Im Microservices-Umfeld kann das schnell zum Problem ausarten.

Oft hat man es mit sehr vielen Services zu tun. Jeder Service liegt womöglich in mehreren Instanzen und für verschiedene Umgebungen vor. Bei Änderungen an der Konfiguration müssten alle Instanzen neu deployt werden. Eine Lösung für dieses Problem ist die Verwaltung der Konfigurationen mit einem separaten Server.

Wir vertrauen dabei in unserem Beispiel auf den Spring Config Server. Dieser bezieht die Key/Value-Paare aus einem Git-Repository oder einer Datenbank und stellt sie die den vorhandenen Diensten über HTTP zur Verfügung – im besten Fall ohne Neustart der Services bei Änderung eines Wertes.

Anlegen des Repositories

In diesem Beitrag kommen die Daten aus Gründen der einfachen Nachvollziehbarkeit aus einem lokalen Git-Repository, das die Properties-Files enthält. Eine Umstellung auf ein Remote-Repo ist aber kein Problem. Das Repository wird angelegt, indem ein neuer Ordner erstellt und darin git init aufgerufen wird:

Anschließend wird in dem neuen Ordner eine Properties-Datei erstellt und mit einem Key-Value-Paar zum Testen versehen. Der Name der Properties-Datei entspricht dabei dem Namen des Client-Services. Hier werden Properties für einen Client namens config-server-client angelegt, die Datei heißt deshalb config-server-client.properties. Darin enthalten ist eine einfache Property namens message:

Die Datei wird dem Git-Repository zugefügt und committet:

Erstellen des Config-Servers

Der Server selbst wird erstellt, indem einem neuen Spring-Boot-Projekt zum Beispiel in STS oder mithilfe des Initializr neben Spring Web die Dependency „Config Server“ zugefügt wird. Die Klasse mit der main-Methode erhält die Annotation _@EnableConfigServer_:

Schließlich ist noch die Konfigurationsdatei application.properties des neu erstellten Server-Projekts anzupassen. Hier wird der Port auf den für Config-Server üblichen Wert 8888 eingestellt, der Name für die Anwendung vergeben und der Pfad zum Git-Repository beschrieben. Wer macOS oder Linux nutzt, braucht bei der Angabe des Pfades nach file: lediglich zwei Slashes:

Der Server kann danach gestartet werden. Die URL, unter der die Properties erreichbar sind, ergibt sich aus Host, Port, Name der Properties-Datei und Umgebung. Ein Aufruf http://localhost:8888/config-server-client/default im Browser führt zu folgender JSON-Antwort:

Erscheint die Ausgabe, dann ist der Config-Server funktionsbereit.

Anlegen des Config-Server-Client

Die Daten werden im Normalfall nicht vom Browser abgerufen, sondern von einem Service, der als Client des Config-Servers fungiert. Auch er wird als Spring Boot-Anwendung zum Beispiel mit dem Initializr angelegt. Erforderlich sind die Abhängigkeiten Spring Web und Config Client.

Der Service erhält in application.properties einen Namen und bei Bedarf einen vom Default-Wert abweichenden Port. Ein vorhandener Config-Server wird seit Spring Boot 2.4 mithilfe der Property spring.config.import angegeben. Das sieht beispielsweise so aus:

Diese Anpassungen genügen im einfachsten Fall bereits, der Service bezieht eine (hier optionale) Konfiguration vom Config-Server auf localhost und Default-Port 8888. Um das auszuprobieren, wird hier eine Methode angelegt, die die Property message als String zurückgibt:

@SpringBootApplication
@RestController
public class ConfigServerClientApplication {

  @Value("${message}")
  private String message;

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

  @GetMapping("/")
  public String getMessage() {
    return message;
  }

Ein Aufruf des Dienstes im Browser unter http://localhost:8080 bringt die vom Config-Server ausgelieferte Property aus dem Repository zur Anzeige. Im Normalfall wird man Host und Port des Config-Server konfigurieren wollen:

Lässt man „optional:“ weg, ist eine Verbindung zum Config-Server auf jeden Fall erforderlich.

Änderungen zur Laufzeit

Ändert man nun den Wert in der Properties-Datei im Repo, kann man mit http://localhost:8888/config-server-client/default überprüfen, dass der Config-Server die Änderung auswertet. Der Client dagegen bekommt die Änderung erst nach einem Neustart mit.

Das ist nicht ganz optimal, lässt sich aber beheben. Dazu wird im Client-Projekt zunächst das Actuator-Framework mit Hilfe der Dependency „Spring Boot Actuator“ zugefügt und in application.properties der Endpunkt refresh verfügbar gemacht:

Außerdem wird die Klasse mit der zu aktualisierenden Variable mit @RefreshScope annotiert:

Beim Neustart des Service sollte im Log der Eintrag “Exposing 1 endpoint(s) beneath base path ‘/actuator’” auftauchen. Nun kann man mit Hilfe eines POST-Requests den Actuator-Endpunkt refresh aufrufen. Das geht zum Beispiel mit Postman oder wie hier gezeigt mit curl:

Der Client sieht dann ohne Neustart eine zur Laufzeit geänderte Property. Der Beitrag hat nur die grundlegende Funktion des Config-Servers demonstriert, es gibt eine Menge mehr zu entdecken. Weitere Informationen finden sich in der Spring-Dokumentation zum Spring Cloud Config Server.

(ID:47835839)