Add spring-cloud-config-server ability to share common configuration across applications

[btiernay]

Right now it doesn't seem possible to share common configuration across applications. This might be a typical use case for certain types of configurations such as shared resources and system wide conventions. Perhaps it would be possible to add something conventional like a bootstrap.yml file for this purpose. Some ideas for naming here:

• defaults.yml
• base.yml
• common.yml
• shared.yml
• application.yml

This could also support the label variants as well (e.g. application-development.yml, application-production.yml, etc.) The last one is particularly interesting because it is already a convention for Spring Boot. It seems to make sense in a system context as well.

Open to suggestions, but this is something that seems general enough to warrant some sort of support.

[spencergibb]

@btiernay That is currently how `application.[properties|yml] is shared across all applications using config server.

[btiernay]

My apologies then. Thats great :)

[ssindelar]

It would be nice to better describe it in the documentation. It is only very short described in brackets in the config under "Environment Repository". Also it should be noted that when a use a file-system backed config server the application.yml/properties needs to be in a seperate folger (/config is default) to work. If you put it in root it is used in the configserver but not shared with the clients.

[shashanksinghal]

Hi @ssindelar,

I am also trying to achieve what you mentioned in your last comment. By file-system backed config server I assume you mean 'spring.profiles.acive: native'. I want some shared config and some service specific config. As you suggested I created an 'application.yml' under src/main/resources i.e. config folder is at classpath. The client does not picks that up.

[dsyer]

@shashanksinghal the "native" profile excludes all property sources that occur in the server itself. I suggest you use a local git repository if you need this feature in a local repo.

[shashanksinghal]

@dsyer Thanks for the prompt response. I actually got it working just now. So I am not sure the behaviour I am seeing is a bug or its intended (and should be put in doc in that case)

My application.yml now looks like:

server:
  port: 8888

spring:
  profiles:
    active: native
  cloud:
    config:
      server:
        native:
          search-locations: classpath:config/,classpath:config/global.yml

What is happening currently is that what I put in global.yml is seen across all clients. In the config folder I can put ymls as {application-name}.yml and its seen by that application only.

Even if its not intended I am happy for now and hope it remains same :-)

I am on spring-cloud-config-server v1.1.0.M3 (through spring cloud Brixton M3)

Thanks again!

[dsyer]

Yeah that would work.

[ssindelar]

@shashanksinghal sorry for the late answer. It put the files outside the jar because inside the jar they don't make sense, because the whole point is that you can edited them on the fly. I also used .properties instead of .yml, maybe there is also a different. {workingdir}/config is not picked up by the normal scan for properties/yml files.

[dinkarthakur]

Hi I'm aslo in same problem with Brixton.M4 and

spring:
  profiles:
    active: native 

if i create application.yml in /config folder inside resources in spring config server its not shared and if i use application.properties it get shared. Is this a bug?

[dsyer]

It might be a bug if it shares application.properties (since that should be used by the config server app itself), unless you mean you added it after start up. Can you provide a sample project?

[dinkarthakur]

i have to add

spring:
  application:
    name: config-server
  profiles:
    include: native
  cloud:
    config:
      server:
        native:
          search-locations: classpath:config/

to make it work even when the config folder is in BuildPath also i found some odd behaviour like if i use appplication.properties then the sequence in which properties from {application}.property and common appplication.properties are picked is diifferent if i use yml

also if i use @project.artifactId@ to get value from the mvn in common application.properties then it always shows the value from pom.xml of config server and if i add @project.artifactId@ to application specific {application}.yml/.property in config server then its value is not calculated

and if i add logging.file= ${spring.application.name} to the common application.properties in config server its fails to start with ex Could not resolve placeholder 'spring.application.name' in string value "${spring.application.name}" sample app is at https://github.com/dinkarthakur/spring-cloud-sample.git

[dsyer]

Placeholders with "@" are a maven feature (so part of your build). Take those out of the equation and open a new issue if you have some ordering questions.

[cesargomezvela]

In response to the main topic: "Add spring-cloud-config-server ability to share common configuration across applications"

Now you can add a general application.yml to share common configuration across applications. I found the response here: http://stackoverflow.com/questions/35555232/loading-multiple-properties-with-config-server?answertab=votes#tab-top

I paste the response in case you don't want to follow the link:

You can create a general application.yml in the root folder of SVN. See the example config repo here: https://github.com/spring-cloud-samples/config-repo And here is an example consumer https://github.com/spring-cloud-samples/customers-stores/blob/master/rest-microservices-store/src/main/resources/bootstrap.yml

The customer-stores project will read from application.yml and also from stores.yml in the repo.

To confirm, check the /env URL if you have actuator added and you should see two configService entries

[hodeh]

a really great feature , but I have a question. in application-dev.yml / application-test.yml /application-prod.yml I want to include configurations for the infrastructure so I dont repeat it in each service , things like hosts/usernames/passwords for ( zipkin,eureka,mysql,cassandra,rabbit,redis)

the question here is that I dont want to pull all configurations in that file , i mean some services might use MySQL configs and not Cassandra , is there something out of the box to do it or maybe i have to develop custom PropertySourcesPlaceholderConfigurer to exclude some configs based on custom property in that the service to allow it to filter only the required technology configs required by that service.

[ryanjbaxter]

What is the concern with a client pulling down some configuration it doesnt use?

[hodeh]

@ryanjbaxter I have a concern that might not be valid, the client (Spring Boot Service) may complain if it found configs for a library that it is not found on the class path. example : the client found a property for spring.datasource.url and the client doest have any dependency declared in the pom for spring-boot-starter-data-jpa , should I worry about that ?

[ryanjbaxter]

I don't think its too much of a concern, it is just a warning. If you want you might be able to adjust things using Spring Profiles so only certain configuration properties are set.

[emedina]

@ryanjbaxter I don't agree with you. Setting properties not required for an application, like DB URLs or URLs to external services which include authentication is a security/privacy issue and not recommended. Why would an application get all connection properties to HR DBs, for instance, just because there may be other "global defaults" I want to share amongst all the applications?

[spencergibb]

Why would the hr db credentials be in the common file?

[emedina]

Well, in any case, they are obfuscated.

Currently, we use one single credential for all applications (which of course it's not a good practice, but that's the current situation now).

[emedina]

Using the Spring Profiles approach would definitively do the trick, though.

[qilaijun101]

ok，well done

[parameshjava]

Observed that, application.yml configuration not overriden by respective service configuration, if service would need to modify the common properties. Is this expected behaviour?

[spencergibb]

@parameshjava this has been working as designed for quite a long time. If you can you provide a complete, minimal, verifiable sample that reproduces the problem, please open a new issue. It should be available as a GitHub (or similar) project or attached to the new issue as a zip file.

[parameshjava]

@parameshjava this has been working as designed for quite a long time. If you can you provide a complete, minimal, verifiable sample that reproduces the problem, please open a new issue. It should be available as a GitHub (or similar) project or attached to the new issue as a zip file.

@spencergibb thanks for your quick reply. Based on the search paths order it overriding the properties. It's working as expected, when placed base/shared configuration files path application-<profile>.yml is first searchable path.