0

背景

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

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

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

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

问题

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

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

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

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

问题

  • 我将如何解决以前的问题？
  • 为什么将私有信息保存在 ENV 变量中被视为一个好主意？
4

1 回答 1

0

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

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

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

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

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

于 2018-01-12T03:34:54.997 回答