1
votes

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

  • Is SCC attempting to read from those locations in addition to the application config path?
  • Is the default folder config/application configurable such that on startup the app reads from config/mysharedconfig instead?
  • Is it suitable to use /config/application/dev as a shared config location where multiple applications can load common, environment-specific config?
1

1 Answers

0
votes

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