Reputation: 13952
In Rails default secrets.yml
it has the code:
# Do not keep production secrets in the repository,
# instead read values from the environment.
production:
secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>
which follows the 12 factor recommendation to store config in environment variables.
Now, one alternative solution would be to not check secrets.yml
into git, and maintain a copy of it on the production / staging servers. You'd then symlink to it each deploy (I'm using Capistrano) and avoid using env vars at all. 12 factor seems to recommend against this approach, citing (among other reasons) that env vars are better because they're a language- and agnostic standard.
So, I have two questions:
If you're storing your config stuff in env vars, then pulling those env vars into your secrets.yml
, how do you manage those env vars on the production server? Do you just put them all in your ~/.bashrc
file? Or is there some better way?
There seems to be very little practical benefit to storing in env vars as opposed to storing in a symlinked secrets.yml
. Am I right in saying that, or am I missing an obvious benefit?
Upvotes: 1
Views: 742
Reputation: 1819
Going backwards:
2) There are fewer moving parts, in that you don't have to muck around with files inside the app directory itself when you deploy. If you're pre-baking an image of your app-server (with Docker, for example), or using an app-as-a-static-slug service like Heroku, you can run the same image in staging and production and feed the different environment variables when the app is started.
1) I use dotenv (or dotenv-rails) to provide the environment for development and test, and either provide the environment via Heroku, via Docker when running the image, or having the Ansible/Puppet/whatever include it in, yeah, an /etc/environment.d file that both included by your .bashrc and the config for Upstart/Monit/whatever that runs your app.
Upvotes: 2