We had a dynamic configuration system for much of our configuration, but it didn't play well with environment variables.
And environment variables are a must, because that's the easiest way to get terraform created config (via a configmap).
We updated the dynamic configuration system so that a config value can now be "provided by" an environment variable. This is going a long way to helping us have a much more sane single place to look to understand all our configuration.
I definitely feel this pain. Changing environment variables at works sucks. JIRA ticket and then back and forth with SRE about whether we really need it.
So it all goes in code and defeats the whole purpose of having the app be configurable.
I don't know if secret management should be part of the same system though.
4 comments
[ 4.6 ms ] story [ 24.5 ms ] threadAnd environment variables are a must, because that's the easiest way to get terraform created config (via a configmap).
We updated the dynamic configuration system so that a config value can now be "provided by" an environment variable. This is going a long way to helping us have a much more sane single place to look to understand all our configuration.
So it all goes in code and defeats the whole purpose of having the app be configurable.
I don't know if secret management should be part of the same system though.
Our intent is to provide the same thing you get with Rails encrypted credentials https://edgeguides.rubyonrails.org/security.html#custom-cred... but for all supported languages and in a way that let's you share between apps.
If you want a lot more control than that, 1P, Doppler, Envkey may be the way and those can fit in via environment variables as normal.