2

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?

pramodc84
  • 1,576
  • 2
  • 25
  • 33
Andy Shinn
  • 26,561
  • 8
  • 75
  • 93
  • 4
    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 Apr 01 '16 at 19:12
  • 1
    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 Apr 02 '16 at 02:11
  • 1
    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 Apr 02 '16 at 15:18
  • 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 Apr 02 '16 at 15:21
  • 1
    @AndyShinn: Do you have something reordering them? When I hit the endpoint I see them listed in this order 1. profiles 2. configService:https://myrepo.git/application.properties 3. servletContextInitParams 4. systemProperties 5. systemEnvironment 6. applicationConfig: classpath:/application.properties 7. defaultProperties – nicholas.hauschild Apr 02 '16 at 20:35
  • You know what, you are indeed correct. I have been using HTTPie as a debugging tool for a while and had no idea it was reordering JSON keys in alphabetical order! I just tried it in curl and the ordering makes much more sense. However, while that is extremely helpful it doesn't ultimately answer my question. The questions still stands if there is a way to have a file that a testing team can use to come after the configServer? – Andy Shinn Apr 03 '16 at 02:29
  • And for anyone wondering about HTTPie, I did find the relevant issue at https://github.com/jkbrzt/httpie/issues/128. – Andy Shinn Apr 03 '16 at 02:31
  • You can set some configurations in the remote `application.yml` (e.g. remote git repository) to allow local override of remote properties. Please, take a look at [this](https://stackoverflow.com/a/55231816/4071001) answer for details. – lcnicolau Mar 20 '19 at 14:40

1 Answers1

4

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

Mark Heckler
  • 126
  • 1
  • 7
  • Actually, this is helpful and something I didn't consider. Taking this one step further, it appears I could potentially use pattern matching to match `staging*` or `dev*` profiles and send those requests to another git repository that the testers can make ad-hoc changes to without going through the normal git process. I'll try this out and accept this answer if this turns out to work out for my use case. – Andy Shinn Apr 05 '16 at 15:46
  • I'll accept this and add the information that gets me where I want: I'm using Spring Profiles to switch the Spring Cloud Config git URI to another testing repo that is mostly empty. Since the git repo is empty for this profile, it allows me to still override properties from a file or environment variable (since they are the only ones that exist). – Andy Shinn Apr 17 '16 at 17:48
  • Resourceful! Nicely done, and glad you're back in business. Best to you, Andy! – Mark Heckler Apr 18 '16 at 18:27