Puppet Chef Ansible Salt 和SaltStack、Fabric自动化运维工具处理效率之比较.docx

《Puppet Chef Ansible Salt 和SaltStack、Fabric自动化运维工具处理效率之比较.docx》由会员分享，可在线阅读，更多相关《Puppet Chef Ansible Salt 和SaltStack、Fabric自动化运维工具处理效率之比较.docx（6页珍藏版）》请在第壹文秘上搜索。

1、目前市面上常见的自动化运维工具主要有以下几种，PuppetChef、Ansible和SaltStack.Fabric下面对四种产品做一个对比介绍：Puppet应该是市面上使用最多的，就操作、模块、界面而言，它是最全面的，Puppet呈现了数据中心协调的全貌，为各大操作系统提供了深入的工具，初始设置简单，只是需要加以管理的每个系统上安装客户端代理软件，C1.I简单直观，允许通过puppet命令下载和安装模块，你可以对配置文件进行需要的修改，让模块适合所需的任务，接到指令的客户端与主服务器联系时，会更改配置文件，也可以是客户端主动与服务端通信来获取到最新的配置文件，还有一些模块可以提供和配置云服务

2、器实例和虚拟服务器实例，所有模块和配置都使用基于RUby的PUPPet专属语言或者RUby本身构建而成，因而除了系统管理技能外，还需要编程专业知识。Chef的总体概念类似Puppet,因为在被管理的节点上安装代理软件，但实际部署又不一样。除了主服务器外，安装的Chef环境还需要工作站来控制主服务器。代理软件可以借助使用SSH来部署的knife工具从工作站加以安装，减轻了安装负担。被管理的节点通过使用证书，完成与主服务器之间的验证。与PUPPet一样，Chef得益于一大批的模块和配置菜谱，那些模块和配置菜谱又高度依赖RUby。由于这个原因，Chef非常适合注重开发的基础设施。Ansible极其类

3、似Salt,而不太类似Puppet或Chef,Ansible关注的重点是力求精简和快速，而且不需要在节点上安装代理软件也可以选择安装。Ansible能通过SSH执行所有功能，Ansible基于Python开发对于熟悉python的人而言是一大福音，并且是由红帽进行运营。AnSibIe可以从命令行来运行，不需要使用配置文件。至于比较复杂的任务，AnSibIe配置通过名为Playbook的配置文件中的YAM1.语法来加以处理。Playbook还可以使用模板来扩展其功能，目前PIaybOOk的模板还是非常丰富的。Salt类似AnSibIe,因为它也是基于C1.l的工具，采用了推送方法实现客户端通信。

4、它可以通过Git或通过程序包管理系统安装到主服务器和客户端上，客户端会向主服务器提出请求，请求在主服务器上得到接受后，就可以控制该客户端了。这四款自动化运维工具网上的比较很多，但是很难说谁就一定比谁好很多，还是那句话，你的团队具有哪方面的人才就使用哪个，如果非要选出一个我个人推荐ansible,因为基于PythOn实现，开发人员比较好找，同时社区资源活跃，相关的资源和组件也是比较丰富的。Ansible.SaIt和PUPPet主要是操作系统或平台层的编排工具，这3个工具的选择的建议要根据企业实际情况而定，如果安全上对SSh没有特殊限制的、企业运维的服务器数量也不是很多的建议使用AnSible。A

5、nSible学习曲线平滑,使用简单,社区资源丰富。SaIt和Puppet性能相对较差，可以根据企业实际情况选择。I)PUPPet是一个开源的软件自动化配置和部署工具，它使用简单且功能强大，很多大型IT公司均在使用PUPPet对集群中的软件进行管理和部署。puppetdashboard1223HGmeNge3GrOUCeaatsesRwns“seam优缺点分析：优点是Web界面生成处理报表、资源清单、实时节点管理，PUSh命令可即刻触发变更，缺点是相对其他工具较匏杂、需学习PUPPet的DS1.或RUby,安装过程缺少错误校验和生成错误报表。2)SallStaek是一种全新的基础设施管理方式，部

6、署轻松，在几分钟内可以运行起来，扩展性好，很容易管理上万台服务器，速度够快，服务器之间秒级通讯。e0SA1.TSTACKCommandTargetFormatMacroCompoundActionDOCSearchResults*rx)c9；”r优缺点分析：优点是可以使用简单的配置模块或叁杂的脚本，Web界面可以看到运行和监控的工作状态、事件日志，扩展能力极强，缺点是缺少生成深度报告的能力。3)AnSibIe是基于PythOn研发的，综合了众多老牌运维工具的优点，实现了批量操作系统配置、批量程序的部署、批量运行命令等功能。在进行大规模部署时，手工配置服务器环境是不现实的，这时必须借助于自动化部

7、署工具。用户添加/修改组漆归，心改rontab漳IMIntervals+tfl，修改Periodictasks*年加TasksWorkers，修改站点管理Profiles漆h11,“淤沙Jobs*Q/修改Packaops:Q4怆曲Projects添加，修改优缺点分析：优点是模块可以用任何语言开发、备管节点不需要安装代理软件、有Web管理界面、安装运行简单，缺点是对WindOWS备管节点需要加强、执行效率相对较低。下图是PUPPet、SaltStack、AnSibIe这三款运维工具处理能力与处理效率的对比：名称PupptSaItStackAnsiblt开发语言RubyPythonPython客户

8、跳有有无二发不支持支持通信蛉证是是是加里方式标准SS1.协议AESiQSOpenSSH平台支持AIXfBSDfHP-UK1.inuxtMacOSX1SoIaris1WindowsBSD,1.I,MCOSX1SoIarIs-WindowsA1KBSD,HP-UX11.inuxMacOSXSoIaris配理文件格式RUby法格式YAM1.YAM1.WebUl提供提供提供（商业版本）令执行不支持（配置模块可实现）支持纳修行点Si量和处理效专扩展能力皎弱速度很快,扩展性好，可以雷理任何数量的服宪器超过500台主机效率蛟任各种运维工具只是用于帮助人员进行运维的，每种工具都有其使用的优势领域，Puppet

9、适用于软件自动化配置和部署；SaItStaCk适用于基础设施管理，在几分钟内可运行起来，很容易管理上万台服务器，速度够快；Ansible适用于批量操作系统配置、批量程序的部署、批量运行命令等。PytOhn开发的AnSibIe,无agent方式，小规模运维（并发20台一下），软件部署使用，7人以下小团队自己做工具用非常合适。Saltstack也是python开发的，mq+agent方式部署，master管理100o设备没有问题，开发的api适合单体数据中心部署和对其进行二次POrtal开发，完成自身业务逻辑，但开源版本不支持aix和hpux,需要向厂商付费才能获得aix和hpux的agentPU

10、PPet由ruby开发，基本是一个配置管理工具，在PUPPet6中去掉了mco,自己配置管理能力增强，独立的语法需要长时间学习和适应，刷配置失误会导致严重的系统故障业务停止等问题，目前使用时需要谨慎和完全测试。Chef由ruby开发结构master+mq+agent完成大并发，多模块，可单独编写菜单完成配置管理和命令行管理，但国内使用数量稀少，相应的人才太少，所有功能需要你自学成才。实际上这三个社区活跃度、需求满足程度都差不多）我个人比较喜欢用PUPPet和AnSible,倒不是说SaItStaek不好,是我从开始就在用Puppet,所以，就没有再去学习SaItStaCk的必要了而Ansibl

11、e主要是远程命令执行，比较适合做一些“一次性”的动作。推模式（ansible）推模式有一个中心节点，用于将最新的配置信息推到各个节点上，典型代表ansible0很明显，推模式的瓶颈就在中心节点，如果同一时间有10000个节点需要更新配置，那么中心节点如何稳定的工作就比较有学问。它比较适合这种场景：对配置生效的时间敏感，十分关心。必须让他们即可生效，如果不生效，立马要采取行动让他们生效。配置生效的顺序十分关心和敏感。比如需要这10个节点一起生效，或者按照依次生效。执行顺序的区别配置生效顺序在puppet和ansible之间有很大的不同，理解这些区别对于如何选择配置管理至关重要。下面举例说明两者的

12、区别：假设现在有三个节点hostl,2,3,它们需要执行配置更新的三个步骤：1,2,3（圆圈表示），我们用图来表示三个节点上的三个步骤执行顺序是如何的。PUPPet的执行顺序如图所示，因为拉模式不管不顾其他节点的执行情况，专心致志完成自己的任务，所以节点之间的更新步骤完全随机。这种更新方法很“分布式”，跑得快的节点可以很快地跑完全程，不用等其他慢的小伙伴，没有短板，没有瓶颈。ansible的执行顺序如上图所示。由于有一个中心节点控制所有机器的配置更新。只有一个步骤在所有节点上完成后，才会继续下一个步骤,所以三个节点的执行顺序会很整齐。这种更新方法目的很明确，就是要“整齐”，跑的快的节点需要等待

13、其他小伙伴完成这个步骤后，大家在进行下一个步，谁都不允许自己先执行下一步。不过ansible2.0中新增加了一种playbook的执行策略：freestrategy,它允许某个playbook不再“整齐”的执行，而是像puppet一样，每个节点trybest的跑到终点，而不用管其他节点执行的情况如何。如何选择虽然puppet和ansible有一定的功能重叠，比如都支持配置文件模版，装包，启动服务，等等，但是仍然有区别。如何选择？只能说“视情况而定”。如果你的团队己经有合适的配置管理，并且已经能否覆盖90%的场景，那么很幸运，不需要换配置管理工具。如果如PUPPet顺序图所示的情况你不能接受，那

14、么最好选择ansibleo如果一开始选择了ansible,并且对“整齐”不敏感，不关心，那么可以使用freestrategy,或者用ansible-pull如果已经使用puppet好多年，并且对于“不整齐”执行没什么顾虑，不关心，不敏感，那么继续使用puppets如果已经使用puppet好多年，并且对于“不整齐有顾虑，很敏感，但是又不想抛弃己有的puppetmodules,因为它们已经很稳定了，那么可以选择使用Mcollective改造，或者用ansible调用puppet,或者两者一起用。Atlassian公司（做Jira的公司）己经给我们介绍了经验我们用Ansible创建AWS虚拟机，将它

15、们放进DNS,和负载均衡后面，然后用Puppet管理这些虚拟机的操作系统的配置。当它们完成后，再使用Ansible管理应用层软件的部署和升级。SaltStack或AnsibleSaltStack与Ansible都是Python写的而且较新，网上评论也很好。1、是否需要每台机器部署agent（客户端）很多选用ansible的朋友，都是因为agentless这个原因，觉得要维护agent很麻烦。而一些使用SaItStaCk比较顺的朋友，觉得这个问题无所谓，agent出问题的概率有，但不高。其实ansible也支持agent的方式，即所谓的“pull”的模式，就是通过一个客户端去拉取要执行的任务。2、大规模并发的能力这方面的对比己经比较多了，因为实现机制的差异，也导致SaltStaCk在这方面是占优的。不过对于几十台-200台规模的兄弟来讲，ansible的性能也可接受。注：前期调研的大多数都是中下企业，服务器规模一般不超过200台，所以对这个问题不算太看重。如果一次操作的机器过千台，可能还是用SakStaCk效率更高一些。ansible的执行架构已经有所优化，采用基于MQ的agent机制，己支持比较大规