Spring config properties dal filesystem locale e git repo

Question

Sto utilizzando il server di configurazione spring cloud per ospitare un percorso centralizzato per tutte le configurazioni di file di proprietà da utilizzare nel progetto. Ho provato ad utilizzare i file di configurazione da un file system locale utilizzando qui sotto e funziona benissimo:

spring.profiles.active=native 
spring.cloud.config.server.native.searchLocations=file://${HOME}/Documents/test-config/cloud-config-properties/ 

ho usato anche il repo git utilizzando: spring.cloud.config.server.git.uri=ssh://xxxxxx.com:7999/test/cloud-config-properties.git

Vorrei provare a utilizzare una combinazione di questo il mio progetto. Esempio: per il profilo dev/test - vorrei usare dal filesystem locale e per la produzione - Vorrei usare il repository Git. Ho abilitato sia git uri che i profili nativi nel mio application.properties nell'applicazione server di configurazione. Ma le proprietà vengono sempre prelevate dal file system locale. È possibile?

Answer 1

Non supportato, tuttavia è possibile ovviare a questo problema. È possibile definire il basedir per il server di configurazione, che è dove si salva i file che scarica dal server remoto, impostando la proprietà (nel server di configurazione):

spring.cloud.config.server.git.basedir=<your_dir> 

Se si sta lavorando con finestra mobile, è può mappare questa directory al filesystem host.

Ora qualsiasi file inserito verrà raccolto dal server di configurazione se corrisponde a qualsiasi applicazione/profilo nella richiesta. Per esempio si potrebbe mettere un file chiamato lì application-dynamic.properties, e hanno tutti i client utilizzano dinamica come l'ultimo profilo, ad esempio

spring.profiles.active=systesting,dynamic 

In questo modo tutto quello che si metterà in application-dynamic.properties avrà la precedenza qualunque cosa sia definita nel tuo repository di configurazione.

Una cosa da notare è che è necessario aggiungere il file solo dopo l'avvio del server di configurazione, poiché elimina questa cartella durante l'avvio.

Aghi per dire, non è una buona pratica farlo in produzione (per esempio un riavvio causerà l'eliminazione del file), ma per test/dev questa è l'opzione migliore.