在AWS上使用Capistrano的Rails secrets.yml VS Dotenv VS Figaro

Question

关于如何在SO上以及在网络上管理API令牌存在一些问题，但是我看到很多人只是在其他地方重复他们阅读的内容，而且他们通常没有多大意义。

我想知道你们如何处理所有这些API令牌等。

到目前为止，这是我使用3种不同的宝石阅读的内容

secrets.yml

在Rails 4.1中引入，应该成为存储秘密的惯例

是（显然不是吗？）打算被推送到存储库中。但是，我经常看到使用环境变量进行生产的示例

development:
  secret_key_base: super_long_secret_key_for_development
  ...

production:
  secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>
  ...

此时，有人问“ IMO为什么要使用ENV进行生产？”，这是一个合法问题。但后来有人回答：“我们不想生产令牌在应用程序中硬编码”（也许这只是我，但哼哼秘密 .yml，像一些文件的名字听起来你不想右犯？），和最后没人真的回答这个问题

但是我仍然设法找到了这个：

优点：

• Rails约定。
• 使用capistrano-secretsgem 轻松部署，并且cap [stage] setup（并且只部署不错的舞台秘密）
• YML数据结构（可以使用数组/哈希）+可以使用Ruby代码

缺点：

• 需要使用 Rails.application.secrets.xxx
• 诸如AWS之类的许多服务仍从ENV读取以自动设置其gem /服务
• 这不是12个因素的方式吗？
• 挺新的，所以还没真正使用过？

Bkeepers Dotenv

只需在启动时由Rails读取的根目录下定义一个.env文件

使用capistrano-env和capistrano

专业人士

• ENV在12要素规则中
• 3.5颗星...也许不算什么？

缺点

• 没有自定义代码，限于字符串-字符串键/值

费加罗报

某种混合机密/ ENV。考虑到12factors / Rails / Heroku，但最后似乎并不比其余的要好...

从上面以及我没有写的其余部分来看，似乎secrets.yml如果将这些秘密放在ENV中会是一个伟大的赢家（而且Rails.Application.secrets每次我对写这些东西都很懒惰）。

因此，假设我也基于您的经验启动了一个全新的Rails应用程序。你会选哪一个 ？

（我的特定堆栈使用AWS + Capistrano，无Heroku）

Answer 1

我个人认为“正确”的方法取决于您的环境。

就我而言，我拥有由 IT 管理的服务器，并且无法访问虚拟主机或其他任何内容来轻松设置环境变量。因此，我提交了一个secrets.yml不包含生产节的文件，然后设置 Capistrano 将此文件添加到shared_files. 在每台服务器上，我添加该文件。

如果我可以轻松访问虚拟主机，并且我使用 Puppet、Chef、Ansible 或类似工具管理服务器虚拟主机，我会使用环境变量方法，例如默认文件secrets.yml。

您使用 AWS 的情况似乎属于后者。最终，任何一个选择都可以。在没有生产节的情况下提交 Secrets.yml 文件几乎没有什么缺点。