On Dec 9, 2011, at 1:46 PM, Darren Boyd wrote: > On Fri, Dec 9, 2011 at 12:50 PM, Patrick Crowley <[email protected]> wrote: > > It pulls in config/initializers/* automatically, not config/* > > Even so, just comment everything out in the example files, so it can't > execute. > > One approach I've taken with secrets in initializers is to have code in the > initializer load the secret from a different file. Depending on how you > deploy, you can then 'search' for the file, and load it... > > For Capistrano based deployments, something like this... > > if File.exist?("#{shared_dir_in_production}/my_config.yml" > # Load the file from its location on production/staging servers > conf = YAML::load_file(...) > elsif File.exist?("~/.my_config.yml") > # This is for developers, if appropriate > conf = YAML::load_file(...) > else > # fail or continue, depending on your needs > end > > If you are on something like heroku, this would look different. (I haven't > done anything like this with Heroku, so I can't offer much.)
The "Heroku" Way of dealing with secrets is to use environment variables for them: http://devcenter.heroku.com/articles/config-vars In a nut-shell, in your initializer you have stuff like: AWS::S3::Base .establish_connection!( :access_key_id => ENV['S3_KEY'], :secret_access_key => ENV['S3_SECRET'] ) In your development environment you set your variables accordingly and you use the heroku CLI to set the variables on the server: $ heroku config:add S3_KEY=8N029N81 S3_SECRET=9s83109d3+583493190 Hope this help, -- Ylan -- SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby
