应用配置存储的良好做法？答案

【问题标题】：Good practices for app configuration storage?应用配置存储的良好做法？
【发布时间】：2021-06-15 20:42:53
【问题描述】：

我们有许多松散耦合的应用程序，一些使用 PHP，一些使用 Python。

有一些集中的地方可以让他们获得全局和特定于应用程序的配置信息，这将是有益的。

类似，对于 Python：

conf=config_server.get_params(url='http://config_server/get/My_app/all', auth=my_auth_data)

然后理想地使用参数作为潜在的嵌套属性，例如。 conf.APP.URL, conf.GLOBAL.MAX_SALES

我正在考虑制作自己的配置服务器应用程序，但不确定这种方法的优缺点是什么 与例如。将配置存储在集中式数据库或任何其他多站点访问模式中。

另外，如果我可能缺少一些现成的工具，有良好的支持，它可以做到这一点（我看过 Puppet 和 Ansible，但它们似乎是非常先进的工具远不止于此。我还为此查看了软件推荐 SE，但他们已经有许多此类问题没有得到解答。

【问题讨论】：

标签： configuration distributed

【解决方案1】：

我认为您的配置机制最好不要硬编码以通过特定技术（例如文件、Web 服务器或数据库）获取配置数据，而是能够从多种不同技术中的任何一种获取配置数据。我用以下伪代码示例来说明这一点：

cfg = getConfig("file.cfg");                          # from a file
cfg = getConfig("file#file.cfg");                     # also from a file
cfg = getConfig("url#http://config_server/file.cfg"); # from the specified URL
cfg = getConfig("exec#getConfigFromDB.py");           # from stdout of command

传递给getConfig() 的参数可能是从命令行选项获得的。 "exec#..." 格式是一种灵活的机制，但存在有人指定要执行的恶意命令的潜在危险，例如 "exec#rm -rf /"。

这种方法意味着您可以尝试任何您认为是理想的配置数据源技术，然后，如果您发现该技术不合适，丢弃它并使用不同的源将是微不足道的 -而不是配置数据技术。实际上，使用哪种配置数据源技术的决定可能因一个用例/用户而异。

我开发了一个名为 Config4* 的 C++ 和 Java 配置文件解析器（抱歉，没有 Python 或 PHP 实现）。如果您查看Config4* Getting Started Guide 的第 2 章（语法概述）和第 3 章（API 概述），您会注意到它支持我在此答案中讨论的那种灵活方法（不支持 "url#... 格式，但"exec#curl -sS ..." 提供相同的功能）。 99% 的情况下，我最终都会使用配置文件，但我很欣慰地知道，我的应用程序可以在需要时轻松切换到使用不同的配置数据源技术。

【讨论】：