Reputation: 32066
We're using Spring Cloud Consul Config 1.3-RELEASE on Java 8 for simple app helloworldclient, works as expected with bootstrap.xml
...
spring:
cloud:
consul:
token: xxxx-xxxx-xxxx-xxxx
discovery:
enabled: true
register: true
service-name: helloworldclient-xyz123
health-check-url: ${HEALTH_CHECK_URL}
config:
profile-separator: '/'
enabled: true
format: yaml
host: ${CONSUL_HTTP_ADDR}
port: 8500
application:
name: helloworldclient
Running the app with profile dev
, this is the loaded config from /env
...
"consul:config/helloworldclient/dev/": {
"product[0].sku": "BL394D",
"product[0].quantity": 8
}
All that is fine, but we're not sure why the remaining consul config sections are even present, and what they're used for:
"consul:config/application/dev/": {},
"consul:config/application/": {},
This is interesting because we have a requirement for shared config such that multiple applications have a way load common, environment-specific config from consul, if possible; some questions to determine if this is a viable solution:
Questions
config/application
configurable such that on startup the app reads from config/mysharedconfig
instead?/config/application/dev
as a shared config location where multiple applications can load common, environment-specific config?Upvotes: 1
Views: 1062
Reputation: 32066
I'm answering my own question:
Based on documentation -- and some quick tests -- Consul supports shared properties via spring.cloud.consul.config.defaultContext
, which by default is set to application
, effectively loading config from consul:config/application
, consul:config/application/dev
, etc., on startup (in addition to config for the app, of course). And defaultContext
is customizable, so we changed it to commoncfg
then granted all ACL tokens permission to read from that location. You don't need to bother with ACL tokens unless you're using them, I only mention it because we use tokens and this step was necessary.
spring: cloud: consul: config: defaultContext: commoncfg
Upvotes: 1