哪里存储公共轨道应用程序的敏感数据？
我的个人栏目项目使用了一些API，我将API密钥/秘密存储在config / environments / production.yml和development.yml中作为全局variables。 我现在想把这个项目推到github上供其他人使用，但是我不希望他们有这些敏感数据。 我也不想在.gitignore这个文件，因为它是运行所需的应用程序。 我已经考虑把它们放在数据库的某处，但是希望find一个更好的解决scheme。
TLDR ：使用环境variables！
我认为@布莱斯的评论提供了一个答案，我只是冲了出来。 Herokubuild议使用环境variables来存储敏感信息（API密钥string，数据库密码）。 因此，调查你的代码，看看你有哪些敏感数据。 然后创build存储敏感数据值的环境variables（例如.bashrc文件中）。 例如你的数据库：
export MYAPP_DEV_DB_DATABASE=myapp_dev export MYAPP_DEV_DB_USER=username export MYAPP_DEV_DB_PW=secret 现在，在您的本地框中，只要您需要敏感数据，就可以引用环境variables。 例如在database.yml中：
development: adapter: mysql2 encoding: utf8 reconnect: false database: <%= ENV["MYAPP_DEV_DB_DATABASE"] %> pool: 5 username: <%= ENV["MYAPP_DEV_DB_USER"] %> password: <%= ENV["MYAPP_DEV_DB_PW"] %> socket: /var/run/mysqld/mysqld.sock
我认为database.yml得到parsing只是在应用程序的初始化或重新启动，所以这不应该影响性能。 所以这将解决它为您的本地开发和公开您的存储库。 如果没有敏感数据，您现在可以像使用私人那样为公众使用相同的存储库。 它也解决了这个问题，如果你在一个VPS。 只需ssh，然后像在开发框中那样在生产主机上设置环境variables。
同时，如果你的生产环境涉及一个不能SSH的生产服务器，就像Heroku的那样，你需要看看如何远程设置环境variables。 对于Heroku，这是用heroku config:add 。 所以，根据同一篇文章，如果你将S3集成到你的应用程序中，并且你有敏感数据从环境variables中传入：
AWS::S3::Base.establish_connection!( :access_key_id => ENV['S3_KEY'], :secret_access_key => ENV['S3_SECRET'] )
只要Heroku为它创build环境variables：
heroku config:add S3_KEY=8N022N81 S3_SECRET=9s83159d3+583493190
这个解决scheme的另一个亲是它是语言中立的，不只是Rails。 适用于任何应用程序，因为它们都可以获取环境variables。
这个怎么样…
创build一个新的项目，并在production.yml和development.yml文件中使用占位符值将其检入到GitHub中。
更新.gitignore以包含production.yml和development.yml。
用您的秘密replace占位符值。
现在你可以检查你的代码到GitHub中而不会影响你的秘密。
任何人都可以克隆你的回购没有任何额外的步骤来创build丢失的文件（他们只会replace占位符的值）。
这是否符合你的目标？
他们可能是最好的初始化（configuration/初始化/ api.yaml），但我认为你已经煮熟了很好。 将实际的密钥添加到.gitignore文件中，然后运行git rm config/environments/production.yml以从您的repo中删除敏感数据。 公平的警告，它会删除该文件，所以先备份。
然后，只需在您的实际文件旁边创build一个config / environments / production.yml.example文件，其中包含相关的详细信息，但不包含敏感数据。 当你把它拉出来生产，只需复制没有.example文件，并replace适当的数据。
使用环境variables。
在Ruby中，它们可以这样访问：
ENV['S3_SECRET']
两个原因：
- 这些值不会进入源代码控制。
- 无论如何，“敏感数据”也就是密码往往会根据环境变化。 例如，您应该使用不同的S3凭证进行开发与生产。
这是最佳做法吗？
是的： http : //12factor.net/config
我如何在本地使用它们？
工头和dotenv都很容易。 或者，编辑你的shell 。
我如何在生产中使用它们？
很大程度上，这取决于。 但是对于Rails来说， dotenv是一个简单的胜利。
平台即服务呢？
任何PaaS应该给你一个方法来设置它们。 Heroku例如： https ： //devcenter.heroku.com/articles/config-vars
这难道不是为这个项目build立一个新的开发者吗？
也许，但这是值得的。 您可以随时使用一些示例数据将.env.sample文件复制到源代码控制中。 在项目的自述文件中添加关于它的注释。
Rails 4.1现在有一个约定。 你用secrets.yml存储这个东西。 所以你最终不会在你的应用程序中散布一些全局的ENV调用。
这个yaml文件就像database.yml erbparsing，所以你仍然可以在这里使用ENV调用。 在这种情况下，您可以将其置于版本控制之下，然后将其作为必须使用ENVvariables的文档。 但是你也可以将它从版本控制中解放出来，并在那里存储实际的秘密。 在这种情况下，你可以把一些secrets.yml.default或类似的东西放到公共回购库中用于文档目的。
development: s3_secret: 'foo' production: s3_secret: <%= ENV['S3_SECRET']%>
比你可以访问这个东西下
Rails.application.secrets.s3_secret
在本集开头详细讨论
