使用 ENV 变量是个好主意吗？

Question

背景

我们的应用使用 MySQL 数据库和更多服务。

为了将我们的应用程序连接到这些服务器，我们将用户名和密码保存在 prod.config 文件中。如果我们在 dev 中，我们使用 dev.config 文件等等...

最近，我一直在研究行业中的良好实践（例如https://12factor.net/），其中大多数（如果不是全部）指定连接数据库和其他服务的用户名和密码等信息应该不在配置文件中，而是在 ENV 变量中。

如果您不知道 12 因子规格是什么，您可以查看此免费教程：

• https://egghead.io/lessons/egghead-summary-concepts-of-the-twelve-factor-app

问题

现在，起初这看起来不错。 Travis 或 CircleCI 等许多 CI 工具已经强制你这样做了。这里的问题是当您最小的应用程序使用多个服务时。

在我们的例子中，对于我们最小的应用程序，我们需要 13 个 ENV 变量。不在任何特定文件中的变量，它们都必须在它们运行的​​机器的 ENV 中。

我不明白这怎么能被视为一种好的做法。我理解不推送包含所有这些敏感数据的配置文件的主要想法，但这种方法会带来几个问题：

1. 当机器重新启动时，您会丢失所有 ENV 变量。
2. 如果您想避免前面的问题，您需要在机器启动时运行一个脚本来设置这些变量，这意味着您会将它们存储在一个文件中，从而违背了整个目的。
3. 您将这些变量保存在哪里？他们需要在你这个脆弱的脑袋之外的其他地方！

问题

• 如何解决之前的问题？
• 为什么将私有信息保存在 ENV 变量中是个好主意？

Answer 1

我将在此退后一步，向您提出一个问题：您为什么要尝试从测试环境连接到生产数据库？

CI 工具的美妙之处在于它们允许您启动 Docker 容器以充当测试服务。在您的生产代码中，将密码保存在环境变量中被认为是最佳实践，主要有两个原因： 1.) 如果有人掌握了您的代码，他们就可以访问您的数据库。它需要额外的安全级别，这是不现实的。 2.) 如果有人确实掌握了您的密码，您希望能够快速更改密码。如果您的代码引用环境变量而不是硬编码字符串，这将更容易做到。

当您迁移到 CI 系统时，第 2 点变得毫无意义，但第 1 点变得非常重要。使用 Travis 和 CircleCI，您的配置文件是公开的。如果您将生产密码放入配置文件中，我（或更恶意的人）可能会扫描您的文件并跳入您的数据库。我听说过黑客从公共存储库中抓取配置文件中的硬编码密码的故事。使用像 CircleCI 这样的工具会更容易。

您在 Travis 和 CircleCI 中设置的环境变量应该存储在存储库级别 - 您不需要移动变量或保存它们。

生产系统中的环境变量应设置为启动脚本的一部分。这在很大程度上取决于您使用的是哪种服务，因此我不会在这里详细介绍。