Externalized remote config in git as an alternative to embedded configuration

[gberche-orange]

When changes are made to the configuration, the service broker needs to be re-pushed. Versionning need to be performed by service owners (e.g. versionning the cloudfoundry manifest.yml file).

This builds ontop of #9

Externalizing the configuration in remote config server might be an attractive alternative which enables to manage properties with more flexibility:

• have versionning builtin through git
• have distinct files
• support hot reloading

http://cloud.spring.io/spring-cloud-static/spring-cloud.html#_spring_cloud_config_server

Initially, a git repo backend would be adopted (possibly over https, and using encryption).

In a second step, other backends could be considered such as hashicorp vault

The deployment process would then become:

# Edit the application-myprovider-team-name.yml into git (into a hiearchical format drafted into #9 ) with credentials
# git commit & git push

# Download the binary release of this broker
$ curl -O -L https://github.com/Orange-OpenSource/static-creds-broker/releases/download/v1.0/static-creds-broker-1.0.war

# Configure the broker through environment variables to point to the git repo, possibly captured in a manifest
$ curl -O -L https://raw.githubusercontent.com/Orange-OpenSource/static-creds-broker/master/manifest.yml 

$ vi manifest.yml

---
applications:
- name: my-broker
  memory: 256M
  instances: 1
  host: mybroker
  domain: my-admin-domain.cf.io
  path: static-creds-broker-1.0.war 

  env:
    spring_cloud_config_uri: https://user:secret@mygit.mycompany.com/myrepo.git
    # Choose an alternative file in the git repo
    spring.cloud.config.application: myprovider-team-name
     # The "label" is useful for rolling back to previous versions of configuration; with the default  Config Server implementation it can be a git label, branch name or commit id. 
    spring.cloud.config.label: master

# deploy the broker    
$ cf push 

If an update to the git configuration is made, a hot refresh may be performed through the refresh http endpoint

$ curl https://user:MySecurePwd@mybroker.my-admin-domain.cf.io/refresh

# $ cf update-service-broker SERVICE_BROKER USERNAME PASSWORD URL
cf update-service-broker mybrokername user MySecurePwd https://mybroker.my-admin-domain.cf.io/

#Notify consummers apps that they need to rebind and restage (pending improvement through notifications service for this)

In terms of implementation, as a 1st step the config server would be embedded within the static broker app:

If you want to read the configuration for an application directly from the backend repository 
(instead of from the config server) that’s basically an embedded config server with no endpoints. 
You can switch off the endpoints entirely if you don’t use the @EnableConfigServer annotation 
(just set spring.cloud.config.server.bootstrap=true).

[s-bortolussi]

Hi @gberche-orange ,

Will this be the default way to get config ?

Cheers

[gberche]

@s-bortolussi We're likely to need to still support flat environment variables as the default mechanism, primarily because it has no dependency on the availability of a reacheable secured remote git repo to hold credentials.

[gberche-orange]

Missing documentation on how to enable remote git config. Need an intro description that points to https://github.com/Orange-OpenSource/static-creds-broker/blob/master/manifest.tmpl.remote-config.yml

[s-bortolussi]

readme updated