Frühling Wolke Config Server-Priorität von Umgebungsvariablen

Question

Ich habe eine Frage bezüglich der Priorität von Umgebungsvariablen, wenn sie mit spring cloud config server

In meinem Dienst arbeiten habe ich eine lokalen Eigenschaften application.yml mit diesem Inhalt

foo: 
    bar: "some" 
    buz: "some" 
    joe: "some" 

die Datei Der Dienst ist auch mit einem Konfigurationsserver mit einem Konfigurationsrepository verbunden, das eine Datei testservice-api.yml enthält (wobei testservice-api der Name der Federanwendung des Dienstes ist). Der Inhalt dieser Datei ist:

foo: 
    bar: "some-specific" 

So mit diesem Setup die Konfiguration zur Laufzeit in dieser Folge hätte:

{ 
    "foo.bar": "some-specific", 
    "foo.buz": "some", 
    "foo.joe": "some" 
} 

Jetzt versuche ich foo.bar und foo.joe mit einer Umgebungsvariablen außer Kraft zu setzen.

So beginne ich den Dienst mit diesem Befehl:

FOO_BAR=some-env FOO_JOE=some-env gradle bootRun

Von dem, was ich las in this part of the spring boot documentation die Umgebungsvariablen Vorrang vor den Konfigurationsdateien haben sollte - auch die Federwolke Config-Dokumentation nicht sth angeben anders - so würde ich das Ergebnis erwarten sein:

{ 
    "foo.bar": "some-env", 
    "foo.buz": "some", 
    "foo.joe": "some-env" 
} 

Aber stattdessen erhalte ich:

{ 
    "foo.bar": "some-specific", 
    "foo.buz": "some", 
    "foo.joe": "some-env" 
} 

Daher wird nur die Konfiguration aus der lokalen Konfigurationsdatei innerhalb des Jar durch die Umgebungsvariable überschrieben - die Eigenschaft aus dem Config Repo scheint Vorrang vor der Umgebungsvariablen zu haben.

Ist das erklärbar - Oder ist das ein Fehler? Irgendwelche Hinweise in diesem?

finden Sie den Beispielcode hier:

https://github.com/mduesterhoeft/configserver-test

Die Readme im Repository listet das Problem hier beschrieben als Use Case 3

Answer 1

definieren folgende Eigenschaften in git Repo (als Quelle für die config-Server) [für gegebenes Profil]: spring.cloud.config: overrideSystemProperties: false overrideNone: true

im Auge behalten Eigenschaften (insbesondere overrideSystemProperties & overrideNone) in bootsrap.yml werden standardmäßig von denen vom Config-Server überschrieben