从项目开发到云头架构(20)

5.5  DIY after

       这里的核心实现是一些脚本工具，业界有些成熟的开源的工具集合使用，用以完成对资源以及软件的部署和自动化管理。典型的有puppet与chef，这2款比较如下：

相同点：

•  都是基于ruby语言
•  对要配置的对象提供了跨平台的抽象，用户大部分时间只跟这些抽象的资源打交道。
• 都有配置中心服务器，都需要安装客户端，客户端跟服务器端用证书认证。
• 配置应用过程都有两个阶段，第一个阶段在配置中心进行，由配置中收服务器针对客户端生成资源列表，第二个阶段在客户端运行，将应用收到的资源列表。
• 都提供了扩展的方式，puppet用的是模块的方式，而chef用的是cookbook的方式。虽然感觉chef的cookbook方式更灵活和易于分享，但是这两者实质是一样的。

不同点：

• puppet提供的配置语言更通用和高级一些，用户不需要懂ruby语言。而对于chef，没有专门的配置语言，用户需要了解比较多的ruby语言。
• puppet资源之间有显式的依赖关系，按照这些关系去实现，而跟这些资源在配置文件的位置或前后没有关系。而chef，更像是ruby脚本，从前到后按顺序执行
• puppet安装简单，需要的支持软件也少，服务器端也是这样。而chef在配置中心服务器端需要依赖软件比较多，需要couchdb、RabbitMQ和Solr，这样连带需要安装java和erlang，这样配置服务器过程要复杂很多
• puppet服务端的配置都是一个一个的文本文件，这样易于发布、备份和扩展。而chef的服务器端的配置放在couchdb和solr索引等二进制文件中，通过远程命令工具knife来操作这些配置。这样，puppet更符合unix管理员的使用习惯。
• puppet的用户很多，象Google、Redhat等大公司都在用它。而chef的用户就少多了，而且没有什么大的公司，不过现在有些云平台公司在尝试使用chef。

写道这里，该系列暂时告一段落。后续有新的篇章在完整的介绍其他的内容。

这里把pdf文档发上来，敬请大家拍砖  ；）