1

There are solutions in the market such as Spring cloud, Consul etc. which can store and serve env. specific configuration data. But all of these services involve a runtime or boot-time dependency between microservices which consume the configuration and config service itself.

Are there any solutions available which make configuration available at package time?

Also from experience, what are the tradeoffs for package time vs. runtime configuration?

4
  • By building you mean also packing? Or just compilation? – Laiv Aug 9 '17 at 9:34
  • @Laiv packing as well - I have edited the question – senseiwu Aug 9 '17 at 9:35
  • Fix me if I'm wrong but, could not do that with CI? For example with Jenkins, should be possible to get the config file from any "repository", place it into the jenkin's task workspace and generate the deployable. – Laiv Aug 9 '17 at 9:52
  • jenkins is not used by our operations for deployment to production, so not an option. For sure, I can even handcraft a script for all this, but by having Spring cloud like solution, we have more control at the development time. My question is how to eliminate risks associated with an external config tool - assume Jenkins is not an option for several reasons – senseiwu Aug 9 '17 at 10:47
1

Octopus allows you to change settings when you create a release.

You could also use team city or other build tools, but you probably want different settings per environment. So your deployment tool is better placed for this job.

Configuring services at run time obviously introduces a risk of the config service not being up. But I believe the real risk is in the confusion of configuration with application state.

Being sure about the change control for your deployed service is very important.

So moving configuration parameters which can only change with a deployment to Application state which changes depending on the state of another tool introduces an extra variable into you change control process.

Make sure whatever configuration tool you are using enables you to audit the config of the various services over time.

You need to be able to determine what the config was at any given point of time and match it against error logs.

Its tempting to use a config tool as a kind of solution control panel, where you switch features on and off, implement failover, control load balancing etc.

But as with all powerful tools, the 'boring' 'YAGNI' features such as rollback, logging and diagnostics can be forgotten untill something breaks. and you wish you had them.

5
  • good points(+1), regardless of the solution, risks surrounding auditing the changes is not an issue as configuration will be stored in Git separately for each env. – senseiwu Aug 9 '17 at 10:49
  • I would be wary of that kind of statement. Even if you use an automatic git backing store there are a number of steps between commit and the service getting that config – Ewan Aug 9 '17 at 10:52
  • also you can have stuff like a name change "connstr" to "constr" the app will use whatever its default is instead of getting the expected value – Ewan Aug 9 '17 at 10:55
  • Its tempting to use a config tool as a kind of solution control panel, where you switch features on and off I'd agree with anyone that feature toggles can make the code messy, but lacking any specific tooling for that, I cannot imagine not using my configuration files for that purpose. Any thoughts? – senseiwu Aug 9 '17 at 11:20
  • I agree, I think the problem is that its the start of a slippery slope. There is a good argument for feature flags to be application state, but they are in the config file.... so we need to be able to change config on the fly.... oo we can change lots of things on the fly. Powerful, but potentially bypassing a lot of change control. – Ewan Aug 9 '17 at 11:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.