Nothing to answer your initial question, but I've got some thoughts... If I'm not misunderstanding things, I'm pretty sure I agree with Chris -- I'm not sure it's a great idea to write stuff that circumvents the database.yml load process, as it'll probably die at some point in the future when Rails is upgraded; and it works quite nicely, even if you don't like the erb thing. The point of the env vars would be that you wouldn't have to look at it that often :)
I also put all the config for my services etc in yaml files in the config dir, and check in dev versions of the files. The chef stuff generates deploy-specific versions that are either used directly, or symlinked in (database.yml being an example of this). I generally partition them by rails env, but only to keep symmetry with database.yml -- the only setup that gets used in either staging or production is the "production" env. This seems nicer to me because you're not just setting a bunch of unstructured global variables, and you've got a single point (or a small number of points) to look at that makes sense (hopefully). (It also stops you just using ENV['xyz'] in your code -- I usually write a wrapper class that at least keeps everything localised.) If you do use env vars, you might be better off putting them in an exec wrapper script so that they're kept in one place. Even if you are using chef, it's still a possible point of failure/confusion putting them everywhere. Whichever way, I'm pretty sure having worked on the same "explosion of environments" rails app you have, that keeping the rails envs limited to "development", "test" and "production" is the only way to go. :) Simon. On Sun, Jul 29, 2012 at 4:15 PM, Michael Pearson <[email protected]> wrote: > .. getting way off topic here. > > Personally, I'm still undecided as to whether "credentials in VCS" is enough > of a security issue that it justifies either: > > hand-entering credentials on a per system basis > bespoke credential distribution solutions such as the one described below > > I kinda like the chef encrypted data bag solution, assuming you've rolled > your own chef server (how is trusting opscode any better/worse than trusting > github?) > > Anybody care to share some horror stories on having creds in VCS (or other > developer or external party sources) that led to an incident? > > On Sun, Jul 29, 2012 at 4:06 PM, Chris Berkhout <[email protected]> > wrote: >> >> At REA we have a config service that is queried via HTTP and tailors >> its response based on the hostname of the request (which should >> indicate the environment). Our DNS setup takes care of making the >> config service available on the same hostname in all environments. >> >> Our config service client writes the results into files that can be >> sourced to set the environment variables. It's probably nicer to not >> write that stuff at all when you can avoid it, but you should make >> sure you don't pass credentials as command line parameters that are >> visible to anyone who can list running processes. >> >> This is different from Heroku and the 12factor idea of having build + >> config = release. We version control the builds but they get whatever >> config is current for the given environment. >> >> The sensitive data has to go somewhere, but not in in the app code and >> also not in your chef/puppet scripts. You could put it in its own >> repo, which would let you see what happened to config over time, but >> it's probably better to have config destroyed forever when it is no >> longer current. >> >> Cheers, >> Chris >> >> >> On Sun, Jul 29, 2012 at 2:09 PM, James Healy <[email protected]> wrote: >> > 2012/7/29 Mike Bailey <[email protected]> >> >> >> >> When and how are you setting the environment variable? >> > >> > I'm interested in this too. I've worked on apps with two dozen or more >> > environment dependent config options (databases, API keys, admin email >> > addresses, etc) and they usually end up being stored in version >> > control in one way or another (in the project or separate chef >> > recipes). >> > >> > I like the idea of setting the config values via ENV vars, but how >> > should I set them without also storing sensitive data as cleartext in >> > a repo somewhere? >> > >> > James >> > >> > -- >> > You received this message because you are subscribed to the Google >> > Groups "Ruby or Rails Oceania" group. >> > To post to this group, send email to [email protected]. >> > To unsubscribe from this group, send email to >> > [email protected]. >> > For more options, visit this group at >> > http://groups.google.com/group/rails-oceania?hl=en. >> > >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ruby or Rails Oceania" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/rails-oceania?hl=en. >> > > > > -- > Michael Pearson > > > -- > You received this message because you are subscribed to the Google Groups > "Ruby or Rails Oceania" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/rails-oceania?hl=en. -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
