Puppet：维护运行环境一致性的利器 _配置管理

配置管理工具的定位
每次我提到配置管理工具，有些同学就会问类似的问题：容器化时代和时代，还需要配置管理工具吗？我们先不去讨论容器化之后是否需要配置管理工具，那什么时候容器能够在全球范围达到100%的普及？什么时候AWS仅提供容器而不再提供虚拟机呢？
之所以会有如上的问题，根源还在于配置管理工具的定位，到底要解决什么问题？配置管理工具的厂商当然希望你什么事情都通过它来实现，在很长时间内，因为市面上没有针对运维各类场景的细分产品，因此配置管理工具就承担了多面手的角色，而随着各类细分产品的逐渐成熟，那些本不适合配置管理工具解决的场景，必然会被逐步替换。举个例子，你可以搜索到很多早期用配置管理工具进行服务部署的教程，但现在讲服务部署，恐怕很少会有人建议你使用配置管理工具了。
那配置管理工具的定位到底是什么呢？个人认为是持续保证运行环境的一致性，主要针对符合幂等性的变更操作，具体解释如下：

文章插图
市面上，配置管理工具的选择有很多，号称CAPS（Chef、、、），我使用较多，通过在单机上的客户端，可以做到”持续保证运行环境的一致性“ 。对于工具的选型，如果有几个候选相差不大，那么更适合你的或者说你更容易搞定的，选他就对了。
配置管理工具的解决方案
全球范围内，笔者了解到的一些使用信息：
那为什么还会有公司使用呢（接下来，我将把配置管理工具替换为），其实刚刚的定位就可以回答这个问题，持续保证运行环境的一致性。在系统安装阶段，各大公司都会将一些定制化的内容置于安装镜像内，例如常用的软件和工具，客户端，一些调优参数，内核模块等等，从而达到开机即用的要求。但存量问题，如何对已经装机完毕的机器，新增/修改/删除部分配置内容（例如新装各种工具如iotop、iftop），以及说服务器存在安全漏洞，需要紧急修复，这个时候，其实镜像模式都不能很好的解决问题，大部分情况下，还得找运维团队通过这类批量操作的方式进行处理。
有同学会说，镜像有问题，重新上线镜像就好了，分分钟就能搞定，但是下面的问题大家是否考虑了：
综合上述的原因看，不可变基础设施对于全量上云的公司来讲，或许可以一试，也许有可能实现，但对于云厂商本身或者大厂来讲，追求所谓的不可变基础设施，投入产出可能不成比例。退而求其次，零接触配置（ZTP，Zero Touch ）其实也挺好的。
基于此，我提出的折中方案是：镜像++的组合
一些可落地的实践

文章插图
通过，我们能够确保如下信息持续的一致性
上述策略的具体配置，可以参考我们开源的内容：
而官方也给出了一些高频场景（Top 5to，详见参考文档的链接）
对于各类信息的一致性监控，两个页面以供参考：

文章插图

文章插图
从以上的截图内容也可以看出，这类信息，不管是服务器还是，随着运行时间的推移，都有可能发生各种变化，在变更入口无法完全收敛的情况下，通过来维护和统计状态，就变得极为重要了。
最后，对于超大规模集群，也可以参考官方提供的解决方案，后期我们也会提供国内互联网厂商的解决方案的相关文章。