Rails4.1が正式にリリースされたらしいので少し見てみたけど、secrets.ymlとかいうのがサポートされるようになったんですね。
公開したくないAPIキーなどの情報をconfig/secrets.ymlに書いておくとRails内でアクセスできるのだとか。
こうやって書いておくと
# config/secrets.yml
development:
secret_key_base: cfcc784a39....
hoge_api_key: hogehogehoge
こう呼べる。
Rails.application.secrets.hoge_api_key
で、このsecrets.ymlをソース管理から外しておけばその他は公開できるよね、みたいな。他のサービスと連携するオープンソースなRailsアプリにするときなんかに使えばいいんだと思います。
Figaroと一緒では
同じことをするためのFigaroってgemあったじゃん。そう思って調べたら機能的にはほぼ一緒？みたいですね。
Figaroの作者がsecrets.ymlに触れてたので読んでみました。
The Marriage of Figaro… and Rails // Collective Idea | Crafting web and mobile software based in Holland, Michigan
で、この人が考えるsecrets.ymlのメリットとデメリットがこれです。
メリット
- Railsが認めた規約になるので単なるgemより良い。HerokuとかTravisがサポートしてくれるようになるし
- ENVハッシュじゃなくてオブジェクトになるから便利
- secret_key_baseがデフォルトで隠せるからよりセキュアになる
デメリット
- The Twelve-Factor AppではENV使う方がいいよと言ってる
- ENVを使わないことで全てのアプリケーションサーバーに必ずsecrets.ymlが必要になる
- デフォルトで
.gitignoreにsecrets.ymlがないのでうっかりソース管理に追加してしまう可能性がある（正式なリリース時にはなおると思う）
最後の1つですが、正式リリースの4.1を試したところ.gitignoreにsecrets.ymlはいませんでした。気をつけないといけないっぽい。
ちゃんとissueでの議論を読んでみる
ここまで書いておいてなんですが、secrets.ymlのproductionのところにこんな風にかいてありました。
# Do not keep production secrets in the repository,
# instead read values from the environment.
production:
secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>
「プロダクション環境の値はリポジトリにいれないで環境から読もうね」って書いてありますね。
となるとこれまでの話には疑問が。本当に秘密にする値はENVから読んでsecrets.ymlはソース管理に入れるってことなんでしょうか？その辺の思想がよくわからないのでGitHubで関連のissueを読んでみました。
が、よくわからんｗ ざっくり言うと、Railsとしてはそこはユーザーに選ばせればよくてこれまでのdatabase.ymlと同じように扱えばいいんだよ、みたいなことが書いてあったような気がします。仕組みは提供したからあとは好きにやってねってことなんでしょうか。
できることはFigaroと同じだけど思想の違いからちょっとした差がでているようですね。と、逃げとく。