我们的应用程序使用 MySQL 数据库和更多服务。
为了将我们的应用程序连接到这些服务器，我们将用户名和密码保存在一个prod.config文件中。如果我们在开发中，我们使用一个dev.config文件等等......
最近，我一直在研究行业中的良好实践（例如https://12factor.net/），其中大多数（如果不是全部）指定用户名和密码等信息连接到数据库和其他服务不应该在 conifg 文件中，而是在 ENV 变量中。
如果您不知道 12 因子规格是什么，您可以查看此免费教程：
现在，起初这看起来不错。无论如何，许多 CI 工具（如 Travis 或 CircleCI）已经迫使您这样做。这里的问题是当您最小的应用程序使用多个服务时。
在我们的例子中，对于我们最小的应用程序，我们需要 13 个 ENV 变量。不会在任何特定文件中的变量，它们都必须在它们运行的机器的 ENV 中。
我不明白这怎么能被视为一种好的做法。我理解不使用所有这些敏感数据推送您的配置文件的主要思想，但这种方法带来了几个问题：
我将在这里退一步向您提出一个问题：您为什么要尝试从测试环境连接到生产数据库？
CI 工具的美妙之处在于它们允许您启动 Docker 容器以充当测试服务。在您的生产代码中，将密码保存在环境变量中被认为是最佳实践，主要有两个原因：1.) 如果有人掌握了您的代码，他们将可以访问您的数据库。它需要额外的安全级别，这是不现实的。2.) 如果有人确实掌握了您的密码，您希望能够快速更改它们。如果您的代码引用环境变量而不是硬编码字符串，则这更容易做到。
当您转向 CI 系统时，第 2 点变得没有实际意义，但第 1 点变得非常重要。使用 Travis 和 CircleCI，您的配置文件是公开的。如果您将生产密码放入配置文件，我（或更恶意的人）可以扫描您的文件并跳转到您的数据库。我听说过黑客在配置文件中抓取公共存储库以获取硬编码密码的故事。使用像 CircleCI 这样的工具会更容易。
您在 Travis 和 CircleCI 中设置的环境变量应该存储在存储库级别 - 您不需要移动变量或保存它们。
生产系统中的环境变量应该作为启动脚本的一部分进行设置。这在很大程度上取决于您使用的服务类型，因此我不会在这里详细介绍。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句