You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We've found this pattern works better than other obvious alternatives with CloudFoundry because:
Putting secrets (such as the client secret) in the manifest.yml as an environment variable is challenging with respect to public source repositories.
Setting environment variables on an already running app doesn't work well as many zero-downtime deploy plugins create a new app on each deployment.
Context
Currently runtime properties are spread between:
./config.properties file
Environment variables (sometimes set via manifest.yml)
/etc/secrets directory
Some settings appear to only work if specified in the ./config.properties file, others appear to allow overriding by environment variables.
Possible Implementation
Last year we made a small Go library to handle looking up environment variables from a list of sources, e.g. first look for environment variables, falling back to data provided by a user provided services, falling back to defaults.
We (cloud.gov.au team) worked with 18F to integrate this with their console.
I've made an experimental change to integrate the same library with the Stratos codebase which is linked as a PR below.
The change is actually quite small - the main part (in main.go) is this method, which initialises an env.VarSet:
// getEnvironmentLookup return a search path for configuration settingsfuncgetEnvironmentLookup() *env.VarSet {
// Make environment lookupenvLookup:=env.NewVarSet()
// Environment variables directly set trump all othersenvLookup.AppendSource(os.LookupEnv)
// If running in CloudFoundry, fallback to a user provided service (if set)cfApp, err:=cfenv.Current()
iferr==nil {
envLookup.AppendSource(env.NewLookupFromUPS(cfApp, "stratos-properties"))
}
// Fallback to a "config.properties" files in our directoryenvLookup.AppendSource(config.NewConfigFileLookup("./config.properties"))
// Fallback to individual files in the "/etc/secrets" directoryenvLookup.AppendSource(config.NewSecretsDirLookup("/etc/secrets"))
returnenvLookup
}
which is passed around to each component that needs to lookup anything from any of the config sources (that is, it is a replacement for the the config.GetValue() calls).
The branch above compiles and pushes, I haven't tested any deeper than that yet, but we can look at if this is a direction worth pursuing.
The text was updated successfully, but these errors were encountered:
@nwmac - is this set of proposed changes of interest to the Stratos team? We found that having the option to specify config this way worked well for deployment within a CloudFoundry app. I've just updated the linked branch above to rebase on current code.
Detailed Description
We'd like to add support for specifying runtime configuration properties via CloudFoundry user-provided services.
For example, an operator would specify prior to deployment:
cf create-user-provided-service stratos-properties -p '{"CF_CLIENT": "stratos","CF_CLIENT_SECRET": "xxxx"}'
And then in the
manifest.yml
:We've found this pattern works better than other obvious alternatives with CloudFoundry because:
manifest.yml
as an environment variable is challenging with respect to public source repositories.Context
Currently runtime properties are spread between:
./config.properties
filemanifest.yml
)/etc/secrets
directorySome settings appear to only work if specified in the
./config.properties
file, others appear to allow overriding by environment variables.Possible Implementation
Last year we made a small Go library to handle looking up environment variables from a list of sources, e.g. first look for environment variables, falling back to data provided by a user provided services, falling back to defaults.
We (cloud.gov.au team) worked with 18F to integrate this with their console.
I've made an experimental change to integrate the same library with the Stratos codebase which is linked as a PR below.
The change is actually quite small - the main part (in
main.go
) is this method, which initialises an env.VarSet:which is passed around to each component that needs to lookup anything from any of the config sources (that is, it is a replacement for the the
config.GetValue()
calls).The branch above compiles and pushes, I haven't tested any deeper than that yet, but we can look at if this is a direction worth pursuing.
The text was updated successfully, but these errors were encountered: