系统配置 5 大设计原则

Fewbytes 首席技术官和 DevOps Days 特拉维夫站的联合组织者 Avishai Ish-Shalom 指出，当前定义和更新系统管理的困难是不一致的配置。他提出了五条设计原则，帮助解决这些问题。

多种格式的配置需要维护者具备更强的技能、配置结果缺乏验证和反馈、特别是自定义格式的配置很难自动生成，这些都是配置管理所面临的问题。Ish-Shalom 表示，现代化的配置管理（CM）工具的流行加重了其中的某些问题，因为他们破坏了系统的自动化和标准化。

拿 Linux 下流行的 conf.d 模式（ popular conf.d pattern ）作为反例，Ish-Shalom 提出，配置管理工具可以在一台机器上自动应用某些配置，但是手动添加新文件（甚至只是改变它们的顺序），却可以改变最终的配置。配管（CM）工具对检测这种偏差缺乏足够的粒度和上下文。

此外，Ish-Shalom 还说，删除这些文件甚至不能保证实际的系统配置会被更新。应用系统配置的多种手段（例如，重新加载或者重新启动）很难确保即使很小的配置变化能够自动且一致地生效。即使是不变的基础架构也不能解决所有场景，正如Ish-Shalom 对InfoQ 所说的：

即使使用不变的基础架构和一次性实例，配置仍然是个大问题。在某种程度上说，这样做的问题更大。配置就像应用程序里“状态”的概念，虽然有些配置可以在 VCS 中进行改动，在构建时集成，在持续发布管道中测试，最后像代码一样部署到不可变的基础架构​​（这样很好，如果可能肯定要这么做）——但其它许多配置不能这么处理，比如像数据库地址这样的环境配置——这是个只存在于生产环境中的动态值，任何时候都可能由于出现故障而产生改变。再比如功能开关标志，你可以在想将它们打开或关闭的时候切换，其全部意义在于避免再进行一次部署以激活这个功能。最后，尽管一些公司已经发展到不变的基础架构和一次性组件，世界上大多数公司仍在使用传统架构——事实上，即使在如今，使用传统架构的公司依然比使用不变架构的公司数量更多。

Ish-Shalom 提出的五大设计原则基于两个核心思想：创建一个基于 REST 的配置 API，以及按照系统更新需要的类型分离配置文件。

API 分别通过标准的 GET 和 POST 方法支持读、写系统配置。这样可以通过 GET 方法交叉检查当前系统配置与 CM 工具中定义的是否匹配，以及通过 POST 方法应用新的配置。这两大原则支持第三原则，那就是给配管（CM）工具管理配置更新的全部责任，从而避免了 conf.d 模式。

按照系统更新类型分离的配置文件一起工作（第四原则），这样配管工具就可以为相同的更新类型，合并多个配置（文件），并使用 POST 方法向配置 API 请求变更，然后读取检查是否成功应用，并且没有被修改。

最后，理想的配置格式应该是标准化和序列化的（例如 JSON 或 YAML），可以由配管工具自动生成。如果不可能，那么最好的选择是将配置视为一个插件，并提取变量到外部配置文件。

当 InfoQ 询问，这样的配置 API 是否会增加潜在的安全漏洞时，Ish-Shalom 说：

配置 API 和任何其他控制 API 没有什么不同。你可以对它进行加密，并要求高级别的身份验证（如 SSL 客户端证书），只在受信任的网络的特殊端口公布，或者简单地使用与你正在使用的 REST API 相同的身份验证方法。公共云服务（PAAS 和 SAAS）是一个很好的例子，我们每天通过 API 配置它们，感觉自然舒适——安全性是内置的，来自 start.s。

Ish-Shalom 将在下一个 DevOps 日 卢布尔雅那站讨论 DevOps 的工作定义。

查看英文原文： 5 Design Principles for System Configuration

感谢邵思华对本文的审校。

给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们，并与我们的编辑和其他读者朋友交流。