Spring Cloud Config für die zentrale Konfigurationsverwaltung

Gepostet am 24. April 2025  •  3 Minuten  • 637 Wörter

Spring Cloud Config für die zentrale Konfigurationsverwaltung

Einführung

In modernen Microservice-Architekturen wächst die Zahl der Anwendungen und damit auch die Komplexität ihrer Konfigurationen. Spring Cloud Config bietet hier eine elegante Lösung: eine zentrale Konfigurationsverwaltung, die Ihre Properties und YAML-Dateien in einem Git-Repository ablegt und bei Bedarf an Ihre Clients ausliefert. In diesem Artikel zeige ich dir, wie Spring Cloud Config funktioniert, welche Vorteile ein Git-basiertes zentrales Repository bietet und auf welche Fallstricke du achten solltest.

Was ist Spring Cloud Config?

Spring Cloud Config besteht aus zwei Hauptkomponenten:

1. Config Server
   Ein eigenständiger Spring-Boot-Service, der Konfigurationsdaten aus verschiedenen Quellen (Git, SVN, lokale Dateien, etc.) liest und über HTTPS REST-Endpunkte bereitstellt.

2. Config Clients
   Die Microservices, die beim Start (und optional während der Laufzeit) ihre Konfigurationen vom Config Server abrufen.

Die Basisarchitektur sieht so aus:

    flowchart LR

  GIT[Git-Repo]
  CONFIG[Config Server]
  CLIENT[Config Client]

  GIT -- git --> CONFIG
  CONFIG -- HTTP --> CLIENT

Clients greifen in ihrer bootstrap.yml oder über spring.config.import auf den Config Server zu:

spring:
  application:
    name: orders-service
  cloud:
    config:
      uri: http://config-server:8888
      label: main

Vorteile eines zentralen Git-Repositories

1. Single Source of Truth

Durch ein zentrales Git-Repository existiert nur eine Konfigurationsquelle. Kein durcheinandergewürfeltes Properties-Verzeichnis auf verschiedenen Servern mehr – alle Services referenzieren dieselben Dateien.

2. Versionsverwaltung und Audit-Trail

Git speichert jeden Commit als Revision. Änderungen an Konfigurationen sind:

• Nachvollziehbar: Wer hat wann was geändert?
• Rollback-fähig: Bei einem fehlerhaften Update einfach auf einen vorherigen Commit zurücksetzen.

3. Branches und Environments

Du kannst Git-Branches in Spring Cloud Config als Labels nutzen, um Umgebungskonfigurationen sauber zu trennen, z.B.:

• main für Produktion
• develop für Staging
• Feature-Branches für spezielle Testfälle

Clients holen sich dann über spring.cloud.config.label automatisch die passende Version.

4. Kollaboration und Code-Review

Konfigurationsänderungen durchlaufen denselben Pull-Request-Workflow wie Code. So kann das Team:

• Änderungsanfragen diskutieren
• Automatisierte CI-Prüfungen (Linting, Validierung) laufen lassen
• Verantwortlichkeiten klar verteilen
• Frühzeitig erkennen, wenn geänderte Konfigurationen nicht abwärtskompatibel sind.

5. Dynamische Konfigurations-Reloads

In Kombination mit dem Spring Actuator lässt sich die Konfiguration zur Laufzeit aktualisieren:

1. POST /actuator/refresh am Client
2. Neue Werte aus dem Config Server werden geladen
3. Beans, die mit @RefreshScope annotiert sind, werden neu initialisiert

So vermeidest du Neustarts und minimierst Ausfallzeiten.

Wichtige Fallstricke und Best Practices

1. Netzwerk-Abhängigkeit & Hochverfügbarkeit

• Problem: Fällt der Config Server aus oder ist das Netzwerk gestört, starten Clients nicht.
• Lösung: Stellen Sie den Config Server redundant auf mehreren Instanzen bereit und setzen Sie einen Load Balancer davor. Da der Config Server den Inhalt des Git-Repository zwischenspeichert, ist ein kurzzeitiger Ausfall des Repository dagegen in der Regel kein Problem.

2. Geheimnisse und Verschlüsselung

• Problem: Sensible Daten (Passwörter, API-Keys) sollen nicht als Klartext in Git liegen.
• Lösung:
  • Aktiviere die in Spring Cloud Config eingebaute Verschlüsselung (encrypt.key) und encrypt.* Endpunkte.
  • Nutze einen externen Secret-Manager (HashiCorp Vault, AWS KMS, etc.) in Kombination mit Spring Cloud Config.

3. Config-Sprawl und Overfetching

• Problem: Clients laden alle Properties, auch solche, die sie gar nicht benötigen.
• Lösung:
  • Strukturiere Konfigurationen modular, z. B. pro Service ein eigenes File (orders-service.yml).
  • Nutze spring.cloud.config.profile und spring.cloud.config.label, um nur die relevanten Profile zu laden.

4. Konsistenz bei verteilten Services

• Problem: Services könnten zu unterschiedlichen Zeitpunkten unterschiedliche Konfigurationen beziehen.
• Lösung:
  • Plane koordinierte Deployments oder Versionssprünge.
  • Verwende Tools wie Spring Cloud Bus, um Konfig-Änderungen als Ereignisse an alle Clients zu schicken.

Beispiel: Minimaler Config Server

@SpringBootApplication
@EnableConfigServer
public class ConfigServerApplication {
  public static void main(String[] args) {
    SpringApplication.run(ConfigServerApplication.class, args);
  }
}

Im application.yml des Servers:

server:
  port: 8888

spring:
  cloud:
    config:
      server:
        git:
          uri: https://github.com/mein-org/config-repo
          default-label: main

Fazit

Spring Cloud Config bringt Struktur und Transparenz in die Konfigurationslandschaft und nutzt Git als robustes, bewährtes Rückgrat. Du gewinnst:

• Versionskontrolle
• Audit und Rollback
• Dynamische Reloads
• Saubere Trennung von Umgebungen

Gleichzeitig erfordert es Sorgfalt bei der Absicherung sensibler Daten, der Hochverfügbarkeit und dem Management von Latenzen. Mit den vorgestellten Best Practices bist du jedoch bestens gerüstet, um deine Microservices skalierbar und wartbar zu konfigurieren – ganz im Sinne von „Configuration as Code“.