Environment specific configurations (documentation)

[tomaszmichalak]

Please provide a recommendation for environment specific configurations. We can achieve that with https://github.com/Cognifide/knotx/wiki/KnotxDeployment. But we need to expand this with an example.

[tomaszmichalak]

An example approach:

For simple string values we override values with simple key=value strategy. For more complex cases like Json objects we need to use a different strategy and we need to load a configuration from an external file.

So finally our solution will look like:

/ config-publish.json
/ config-author-int.properties
/ proxy.json

and our config-author-int.properties contains:

com.projectspecific.extension.options.config.address=knotx.adapter.action
com.projectspecific.extension.options.config.dcs.clientOptions=file://proxy.json

proxy.json file contains:

{
  "proxyOptions": { 
    "host": "test" 
  }
}

Based on those files we expect to start Knot.x with command:

java -Dlogback.configurationFile=logback.xml -cp "app/*" io.knotx.launcher.LogbackLauncher -conf config-author.json -Dcom.projectspecific.extension.options.config.address=knotx.adapter.action -Dcom.projectspecific.extension.options.config.clientOptions=file:proxy.json

Note that the transformation from the environment specific properties file to the Knot.x start command is performed by some automation tool like Chef.

[jwadolowski]

As far as I understand CLI values take precedence over the *.json ones, which is fine as a temporary solution. The positive side of that is the fact we're using built-in knot.x feature and automation created around that should be able to transform any number of *.properties entries into a set of start parameters, which simplifies deployments a lot. Once it's there you can just add new key-value pairs to that file to override pretty much anything.

The downside is that effectively we're running something different on each environment/server and there's a risk that it may quickly become a nightmare to manage, in particular if you're trying to override a couple of config sections completely (plenty of small JSON files). We're mixing various config types (standard JSON-based and *.properties files) here and in case of a long list of properties to override it can become an issue. At the same time automation should significantly mitigate that risk.

More comprehensive solution I can think of right now may require changes to the way knot.x handles config files, i.e.

• all default values are delivered as usual in config-publish.json
• environment specific values go into my-env.json values
• knot.x gets started with -Doverride.profile=my-env
• knot.x merges config-publish.json and <ENV-PROFILE>.json upon start (values specified in <ENV-PROFILE>.json take precedence over the ones in main config file)

Approach above keeps config clean - all options are stored as JSON files and only one environment specific parameter needs to be added to the start script.

For a short list of overrides solution you proposed is absolutely fine though.

[tomaszmichalak]

Thank you Kuba for your feedback. In our case we plan to override only a few parameters. But your approach looks tempting for the next Knot.x releases.

[malaskowski]

Milestone milestone/backpressure-and-configs and Knot.x 1.3.0 will those problems.