Spring cloud configuration properties from local file system and git repo

Question

I am using spring cloud configuration server to host a central location for all property file configurations that will be used in the project. I tried using configuration files from the local file system using below and it works fine:

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

I also used the git repo using: spring.cloud.config.server.git.uri=ssh://xxxxxx.com:7999/test/cloud-config-properties.git

I would like to try a combination of this in my project. An example - for dev / test profile - I would like to use from the local file system and for production - I would like to use the git repository. I have included both git uri and my own profiles in my application.properties applications in the config server application. But properties are always selected from the local file system. Is it possible?

Answer 1

Not supported out of the box, however there is a workaround for this. You can define basedir for the configuration server, where it saves the files that it retrieves from the remote server, by setting the property (on the configuration server):

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

If you are working with docker, you can map this directory to the host file system.

Now, any file that you enter there will be uploaded by the configuration server if it matches any of the applications / profiles in the request. For example, you can put a file there called application-dynamic.properties and let all your clients use dynamic as the last profile, for example

 spring.profiles.active=systesting,dynamic 

That way, everything you put in application-dynamic.properties will override everything that is defined in your configuration repo.

One note is that you only need to add the file after the configuration server starts, as it deletes this folder during startup.

The needle says that this is not a good practice for this in production (for example, reloading will delete the file), but for test / dev this is the best option.