首页 文章

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

提问于
浏览 次
4

关于如何在网上和那里管理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 . 但后来有人回答"We don't want production token to be hard coded in the application"（也许只是我，但是哼哼SECRETS.yml，这个名字听起来像是你不想提交的某个文件吗？），最后没有人真正回答这个问题

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

优点：

  • Rails惯例 .

  • 轻松部署 capistrano-secrets gem和 cap [stage] setup （它只能部署舞台机密）

  • YML数据结构（array / hash ok）可以使用Ruby代码

缺点：

  • 需要使用 Rails.application.secrets.xxx

  • 许多像AWS这样的服务仍然从ENV读取以自动设置他们的宝石/服务

  • 不是12种因素的方式（或者是吗？）

  • 很新，所以还没用过呢？

Bkeepers dotenv

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

使用 capistrano-env 和 capistrano

投票站

  • ENV属于12个规则

  • 3.5k星......也许不是什么都没有？

CON外

  • 无自定义代码，仅限于字符串字符串键/ val

费加罗

某种混合秘密/ ENV . 考虑到12factors / Rails / Heroku，但最终似乎并不比其他更好......

从上面和其余的我没写，看起来像secretts.yml将是一个伟大的赢家，如果这些秘密被放入ENV而不是（并且我觉得每次写_2768501都很懒） .

所以，假设我启动了一个非常新的Rails应用程序，并且还根据您的经验 . 你会选哪一个 ？

（我的特定堆栈使用AWS Capistrano，没有Heroku）

ruby-on-rails amazon-web-services deployment capistrano3 app-secret

2 回答

  • 0

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

    在我的情况下，我有由IT管理的服务器，我无法访问vhost或其他任何东西来轻松设置环境变量 . 因此，我提交了一个不包含 生产环境 节的 secrets.yml 文件，然后设置Capistrano将此文件添加到 shared_files . 在每台服务器上，我添加该文件 .

    如果我可以轻松访问vhost，并且我使用Puppet，Chef，Ansible或类似的方式管理服务器vhosts，我会使用环境变量方法，如默认的 secrets.yml 文件 .

    您在AWS的案例似乎是后者 . 最终，任何一种选择都可以 . 在没有 生产环境 节的情况下提交secrets.yml文件几乎没有什么缺点 .

    回复于
  • 0

    首先，所有三种方法都可以是12因子兼容的 . 如果您通过ENV变量传递配置值，而不是首先将一个文件复制到服务器，它是兼容的 .

    我的想法是这些解决方案：

    Rails的秘密

    开发人员被迫采用12因子，或者在 生产环境 服务器上手动设置，或者在本地计算机上安装另一个文件，然后在部署期间每次将其作为ENV传递 . （不知道 capistrano-secrets ，它可能会处理这个）

    （我想你在CON＃2和＃3中所说的与secret.yml解决方案相反）

    你提到的访问器也很长 .

    dotenv

    它不鼓励12因素和was not originally designed for production env anyways . 您可以编写代码以在部署期间将其值作为ENV传递给 生产环境 （使其与12因子兼容），或者将 .env.production 文件复制到 生产环境 服务器 .

    它还会强制您使用扁平键：值配置 . 没有筑巢 .

    费加罗

    虽然它使用YAML，但它不允许嵌套哈希 .

    它是12因子兼容的，例如它包括将配置传输到heroku的代码 .

    我的解决方案

    我写了一个gem，其中的设置存储在gitignored YAML文件中 . 允许嵌套 . 访问某些值时，请执行 Setting.dig(:fb,:api) .

    它通过将整个YAML文件序列化为字符串并将其作为ENV传递给 生产环境 ，为12因素应用程序部署提供机制 .

    我不再需要区分秘密配置和非秘密配置 . 它们默认在一个地方和秘密 . 在使用易于命名空间的YAML文件时，我受益于12因素应用程序 .

    回复于

相关问题