CODEWITHSUNDEEP
spring-bootcloudspring-cloud
Swetha V
Swetha V

Reputation: 310

spring cloud config properties from both local filesystem and git repo

I am using spring cloud config server to host a centralized location for all the property files configurations to be used in the project. I tried using the config files from a 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 using a combination of this in my project. Example - for dev/test profile - i would like to use from local filesystem and for the production - I would like to use Git repository. I enabled both the git uri and native profiles in my application.properties in config server application. But the properties are always picked up from the local file system. Is this possible?

Upvotes: 8

Views: 3879

Answers (1)

Amit Goldstein
Amit Goldstein

Reputation: 907

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

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

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

Now whatever file you put in there will be picked up by configuration-server if it matches any of the application/profile in the request. For example you could put a file there called application-dynamic.properties, and have all your clients use dynamic as the last profile, for example

spring.profiles.active=systesting,dynamic

This way everything you will put in application-dynamic.properties will override whatever is defined in your config repo.

One thing to notice though is that you need to add the file only after configuartion server starts, because it deletes this folder during startup.

Needles to say, it's not a good practice doing this in production (for example a restart will cause the file to be deleted), but for test/dev this is the best option.

Upvotes: 4

Related Questions