Kapitel 14 · Cloud

Spring Cloud Config und zentrale Konfiguration

Typ: FrameworkVersion 2 ausführlich

Spring Cloud Config trennt Anwendung und Umgebungskonfiguration und stellt Properties zentral für viele Services bereit.

‹ Zurück ⌂ Index Weiter ›

Fachliche Einordnung

In Enterprise-Landschaften müssen Umgebungen reproduzierbar, versioniert und auditierbar sein. Config Server hilft, Konfiguration zentral zu organisieren, ersetzt aber nicht Secret Management.

Enterprise-Merksatz: Spring Cloud Config trennt Anwendung und Umgebungskonfiguration und stellt Properties zentral für viele Services bereit.

Technische Darstellung

Kernkonzepte

Config Server und Config Client.
Git, Vault oder andere Backends.
PropertySource und Environment Integration.
Profile und Labels für Umgebung/Version.
Refresh-Strategien und Betriebsdisziplin.

Wann einsetzen?

Viele Services teilen Konfigurationskonventionen.
Du willst Config versionieren und reviewen.
Du brauchst klare Trennung zwischen Build-Artefakt und Umgebung.

Typische Fehler und Risiken

Secrets unverschlüsselt in Git speichern.
Laufzeit-Refresh ohne Tests und Governance.
Zu viele Profile statt weniger klarer Umgebungsvarianten.

Legacy- und Modernisierungssicht

Properties aus EAR/WAR, WebSphere Variablen und Dateiablagen werden in versionierte Config-Repositories und Secret-Stores überführt.

Ausführliches Beispiel

Das Beispiel zeigt bewusst nicht nur Annotationen, sondern auch die Verantwortung der Schicht. In echten Projekten sollte der technische Spring-Code an Adapter- oder Konfigurationsrändern bleiben, während die Fachlogik testbar und möglichst frameworkarm bleibt.

# application.yml des Config Servers
server:
  port: 8888
spring:
  cloud:
    config:
      server:
        git:
          uri: ssh://git.example.com/platform/config-repo.git
          default-label: main

# application-prod.yml eines Clients im Config Repo
order:
  risk:
    max-amount: 15000
    manual-review: true

Checkliste für Reviews

Ist die Verantwortung des Bausteins klar: Framework steuert Lebenszyklus, Library wird gezielt benutzt?
Ist die Fachlogik außerhalb von Controller, Listener, Repository-Implementierung oder Konfiguration?
Sind Fehlerfälle, Timeouts, Security, Monitoring und Tests sichtbar modelliert?
Gibt es klare Grenzen zwischen DTO, Domäne, Persistence und Infrastruktur?