2
votes

I'm starting to use Spring Cloud Config and would like to give a way for clients to override properties that come from cofnig server. However, after reading https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html, it isn't apparent when the Cloud Configuration applies.

I've also read http://cloud.spring.io/spring-cloud-config/spring-cloud-config.html and it talks about overrides. But they seem to be the opposite of what I want (those overrides are for overriding the client provided properties).

So, where does the Cloud Config fit in the ordering? Would I still be able to give a local application.properties file on the classpath to override certain Cloud Config properties?

1
Config server applies at the topmost level. If you want an application to override something, why not provide application specific config IN config server? I'm a bit confused about what your use case is.spencergibb
Take a look at the /env actuator endpoint. It will show you the property sources used in your application, and the ordering by which they override each other (earlier listed sources override later listed sources). In general, ConfigServer sources are very early, only behind command line -D properties in the default ordering.nicholas.hauschild
When testing applications it is too much overhead to go through the git branch, push, and review process for configuration changes. Testers are preferring a way to make local changes without having to go through the git process.Andy Shinn
Are you sure /env in Spring Boot Actuator is ordered by configuration order? It appears to just be alphabetical ordering to me. In my example, defaultProperties is showing after configService which isn't correct ordering.Andy Shinn
@AndyShinn: Do you have something reordering them? When I hit the endpoint I see them listed in this order 1. profiles 2. configService:myrepo.git/application.properties 3. servletContextInitParams 4. systemProperties 5. systemEnvironment 6. applicationConfig: classpath:/application.properties 7. defaultPropertiesnicholas.hauschild

1 Answers

4
votes

The git commit/push process is part of the process, actually...Spring Cloud Config uses git to handle the config files, changes, auditing, etc., as git is ideally suited for that, & Config leverages those strengths.

If you're just looking for a way to expedite testing of config changes and are willing to accept the tradeoffs, you can use a local (or local network) repo for your config repository for testing. I realize this isn't what you're asking specifically, but it's an option that may help, assuming you're using the Config server app's application.properties to point to the underlying git repo. If so, you can override spring.cloud.config.server.git.uri on the command line like so:

java -Dspring.cloud.config.server.git.uri=${HOME}/testing/config-repo -jar your_jar_here.jar

This will allow you to tweak the config settings for client apps/services that obtain their settings from the Config server without affecting the production config files (even branches).

I hope this helps. If not, or if I've misunderstood your goals or constraints, please clarify (a use case or two might help me triangulate better, if you can share them) and I'll take another run at it. :)

Cheers, Mark