@feuyeux
2015-03-27T17:08:59.000000Z
字数 1619
阅读 2596
infoq
CM
配置管理
当尝试使用配置管理工具融合系统配置时,像conf.d这样的流行配置机制带来了多种问题。Ish-Shalom为配置管理提出了五条设计原则,以防止那些问题的发生。其核心思想是利用配置API,以及基于系统更新需要的类型,进行配置分离。
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的工作定义。