I'm only starting out with Clojure/Ring, but I was thinking about this recently too. I had something like the following in mind, borrowing some concepts from other projects/frameworks/strategies that I've had success with.
The project could contain something like 'config/global.clj' which contains a simple Clojure map with configuration for your app that is appropriate for version control. Maybe it has some default values, comments, etc. You could build this in to your app somewhere, too. The project would then have another Clojure map in a file named like 'config/local.clj' in your project root which would be ignored by version control, and deployed alongside your application. You'd probably template it with Puppet or Chef or Ansible and it would contain your deep, dark secrets. You'd have a project-local one of these for development. You could even have more than one, if that's your thing. At application initialization, the maps are then read in, merged and made available to your application exactly like weavejester's environ that you mentioned. environ already handles leiningen profiles for things like AWS access keys which might be annoying to duplicate across all of your projects in development, and such a system as I've described would fit in fairly naturally with environ. In any event, I hadn't found that project yet, but I definitely plan to use it now. Thanks for pointing it out! On Sat, Sep 7, 2013 at 11:53 PM, Alexandr Kurilin <a...@frontrowed.com> wrote: > I'm curious to find out how you folks decided to organize configuration for > your Ring applications, assuming you also use configuration management like > Puppet/Ansiblet etc to deploy them. > > So far I've been using a combination of daemontools' envdir (through runit) > + weavejester's environ for things like db address, db password, cookie > secret keys, logging level etc. Each one is an individual file in root-only > folder that runit envdirs from. > > I honestly can't decide whether a single configuration file (YAML, EDN, > whatever) would be more appropriate for this scenario or if I should go > ahead and continue keeping each configuration value in its own file and use > env to load them. > > What are people's thoughts on this? Any reason why one or the other would be > better, or is there an even better option out there I'm not considering? -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
