7

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

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

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

秘密.yml

Rails 4.1 引入，应该成为存储秘密的约定

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

development:
  secret_key_base: super_long_secret_key_for_development
  ...

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

在这一点上，有人问“我们为什么要使用 ENV 进行生产？”，这是 IMO 的一个合法问题。但是后来有人回答“我们不希望在应用程序中对生产令牌进行硬编码”（也许只是我，但是哼SECRETS .yml，这个名字听起来像是你不想提交的某个文件对吗？），并且最后没有人真正回答这个问题

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

优点：

  • 导轨约定。
  • capistrano-secrets使用gem轻松部署和cap [stage] setup（它只部署阶段秘密很好）
  • YML 数据结构 (array/hash ok) + 可以使用 Ruby 代码

缺点：

  • 需要使用Rails.application.secrets.xxx
  • 许多像 AWS 这样的服务仍然从 ENV 中读取数据来自动设置它们的 gems/services
  • 不是12个因素的方式（或者是吗？）
  • 很新，还没有真正使用过？

Bkeepers dotenv

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

使用capistrano-env和capistrano

专业人士

  • ENV 在 12factor 规则中
  • 3.5k 颗星……也许不是白费？

缺点

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

费加罗

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

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

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

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

4

2 回答 2

0

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

我的想法是这些解决方案中的每一个：

Rails 的秘密

开发人员被迫采用 12 因素，要么在生产服务器上手动设置它，要么在本地机器上保存另一个文件，然后在每次部署期间将其作为 ENV 传递。（不知道capistrano-secrets，它可能处理这个）

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

正如您提到的，访问器也很长。

dotenv

它不鼓励 12 因子，并且无论如何最初都不是为生产环境设计的。您可以编写代码在部署期间将其值作为 ENV 传递给生产环境（使其兼容 12 因子），或者将.env.production文件复制到生产服务器。

它还强制您使用平面键：值配置。没有嵌套。

费加罗

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

它兼容 12 个因素，例如它包含将配置传输到 heroku 的代码。

我的解决方案

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

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

我不再需要区分秘密配置和非秘密配置。默认情况下，它们在一个地方并且是秘密的。在使用易于命名空间的 YAML 文件时，我可以从 12 因素应用程序中受益。

于 2018-03-06T14:48:52.293 回答
0

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

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

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

您与 AWS 的情况似乎是后者。最终，任何一个选项都可以。在没有生产节的情况下提交 secrets.yml 文件几乎没有缺点。

于 2016-08-20T11:37:03.127 回答