Closed johanhaleby closed 8 years ago
Configurations in Duct are just maps. You can meta-merge
configurations from any source you want.
Right, so essentially my question is whether or not this would be something that should be available by default (In Java I'm used to spring boot which supports loading configuration from a variety of different sources by default)? But I do understand if this is not desirable from Duct's perspective (since might increase the complexity of duct's code) but I just want to make sure that I'm not missing anything.
I don't think offering multiple configuration sources by default as being a good idea. Adding a new configuration source should be one or two lines of code, and I don't think a template is needed for that. Better to have a single, sensible default - in this case environment variables - but make it trivial for users to use any source that produces a map of data.
Would it make sense (and be possible) to create a profile that would add support for this? If so maybe I could help out.
Add support for what? Kubernetes' ConfigMaps? I think that's a little too niche to warrant a profile.
No no, I meant support for loading configuration from a user specified file. But the more I think of it the less sense it makes.. Thanks for your feedback, I'll close the issue.
Well, that should only be a couple of lines of code. e.g.
(def file-config
(edn/read-string (slurp "config.edn")))
Substituting edn/read-string
with whatever configuration library you want. The <project>.config
namespace is designed to hold static configurations loaded at startup, be it from a file, the environment, or something more exotic.
thanks!
Would it make sense to be able to load configuration not only from the environment but also from a file in Duct? I.e. when my uberjar is created I'm looking for something like this:
Background:
I'm trying to use ConfigMaps in Kubernetes with an application developed in Clojure using Duct. Kubernetes doesn't support specifying environment variables from a config map that doesn't match regex
\.?[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*
, which means that you cannot expose environment variables containing "special characters" this way (for example a\
). Another way that is supported by Kubernetes is expose a config map as a file. Which means that if I somehow could instruct my uberjar to load properties from a file of my choice I would be able to get things to work without having to hack things.