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文档发上来,敬请大家拍砖 ;)