运维管理⼯具的对⽐Puppet、Chef、Ansible和SaltStack
随着虚拟化技术⽇益普及，基于⾏业标准的服务器功能越来越强⼤，加上云计算的出现，这些因素共同导致了企业内外需要加以管理的服务器数量⼤幅增长。过去我们只要管理内部数据中⼼⾥⾯的物理服务器机架，⽽现在我们要管理多得多的服务器，它们有可能遍布全球各地。
  这时候，数据中⼼协调和配置管理⼯具就派得上⽤场。在许多情况下，我们管理⼤批同样的服务器，它们运⾏同样的应⽤程序和服务。这些服务器部署在企业内部的虚拟化框架上，或者作为云计算或托管实例在远程数据中⼼运⾏。在⼀些情况下，我们可能谈论的是完全为了⽀持超⼤应⽤系统⽽存在的⼤型环境，或者是⽀持⽆数⼩型服务的⼤型环境。不管怎么样，让它们都乖乖听从管理员的指挥这种能⼒不可⼩视。这是管理这些越来越庞⼤的基础设施的唯⼀⽅式。
  Puppet、Chef、Ansible和Salt都是为了实现这个⽬标⽽开发的：让⽤户极容易配置和维护数⼗台、数百台、乃⾄数千台服务器。这倒不是说⼩公司就不会得益于这些⼯具，因为⾃动化和协调技术通常可以简化任何规模的基础设施的正常运⾏。
  深⼊测评这四款⼯具中的每⼀款，探究各⾃的设计和功能，可以发现：虽然⼀些⼯具的得分更⾼，但每款⼯具都有⼀席之地，这取决于部署的⽬的。
Puppet
  Puppet也许是四款⼯具中最深⼊⼈⼼的。就可⽤操作、模块和⽤户界⾯⽽⾔，它是最全⾯的。Puppet呈现了数据中⼼协调的全貌，⼏乎涵盖每⼀个运⾏系统，为各⼤操作系统提供了深⼊的⼯具。初始设置⽐较简单，只需要在需要加以管理的每个系统上安装主服务器和客户端代理软件。
  命令⾏接⼝(CLI)简单直观，允许通过puppet命令下载和安装模块。然后，需要对配置⽂件进⾏更改，好让模块适合所需的任务；应接到指令的客户端与主服务器联系时，会更改配置⽂件，或者客户端通过⽴即触发更改配置⽂件的推送(push)来进⾏更改。
  还有⼀些模块可以提供和配置云服务器实例和虚拟服务器实例。所有模块和配置都使⽤基于Ruby的Puppet专属语⾔或者Ruby本⾝构建⽽成，因⽽除了系统管理技能外，还需要编程专业知识。
  Puppet企业版拥有最全⾯的Web⽤户界⾯，允许使⽤主服务器上的预制模块和菜谱(cookbook)，实时控制被管理的节点。Web⽤户界⾯很适合⽤于管理，但是不允许对模块进⾏诸多配置。报告⼯具⾮常完善，提供了详细信息，以便了解代理软件运⾏如何、已做出什么样的变更。
  Chef
  Chef的总体概念类似Puppet，因为在被管理的节点上安装有主服务器和代理软件，但实际部署⼜不⼀样。除了主服务器外，安装的Chef环境还需要⼯作站来控制主服务器。代理软件可以借助使⽤SSH来部
署的knife⼯具从⼯作站加以安装，减轻了安装负担。之后，被管理的节点通过使⽤证书，完成与主服务器之间的验证。
  Chef的配置离不开Git，所以对Chef运作⽽⾔，了解Git如何⼯作是先决条件。与Puppet⼀样，Chef同样基于Ruby，所以还需要了解Ruby。与Puppet⼀样，模块可以下载，也可以从头开始编写，可以在所需配置之后部署到被管理的节点。
  与Puppet不⼀样，Chef还没有⼀项完善的推送功能，不过提供了测试版代码。这意味着需要配置代理软件，以便与主服务器进⾏联系，实际上不可能⽴即应⽤变更的内容。
  企业版Chef的Web⽤户界⾯很实⽤，但不提供更改配置的功能。这个Web⽤户界⾯不如Puppet企业版来得全⾯，缺少报告及其他功能，但允许库存控制和节点组织。
  与Puppet⼀样，Chef得益于⼀⼤批的模块和配置菜谱，那些模块和配置菜谱⼜⾼度依赖Ruby。由于这个原因，Chef⾮常适合注重开发的基础设施。
  Ansible
  Ansible极其类似Salt，⽽不太类似Puppet或Chef。Ansible关注的重点是⼒求精简和快速，⽽且不需要在节点上安装代理软件。因
此，Ansible通过SSH执⾏所有功能。Ansible基于Python；相⽐之下，Puppet和Chef基于Ruby。
  Ansible可以通过Git软件库克隆，安装到Ansible主服务器上。安装完毕后，需要管理的节点被添加到Ansible配置环境，SSH授权密钥被附加到每个节点上，这与运⾏Ansible的⽤户有关。⼀旦完成了这步，Ansible主服务器可以通过SSH与节点进⾏通信，执⾏所有必要的任务。为了与默认情况下不允许根SSH访问的操作系统或发⾏版协同运⾏，Ansible接受sudo登录信息，以便在那些系统上以根⽤户的⾝份运⾏命令。
  Ansible可以使⽤Paramiko(基于SSH2协议的Python实现)或标准SSH⽤于通信，不过还有⼀种加速模式，允许更快速、更⼤规模的通信。
  针对确保服务在运⾏，或者触发更新和重新启动之类的简单任务，Ansible可以从命令⾏来运⾏，不需要使⽤配置⽂件。⾄于⽐较复杂的任务，Ansible配置通过名为Playbook的配置⽂件中的YAML语法来加以处理。Playbook还可以使⽤模板来扩展其功能。
  Ansible有⼀⼤批模块，可⽤于管理各种系统以及亚马逊弹性计算云(EC2)和OpenStack等云计算基础设施。可以⽤⼏乎任何⼀种语⾔来编写⾃定义Ansible模块，只要模块输出是有效的JSON。
  Ansible的Web⽤户界⾯以AnsibleWorks AWX的形式出现，但AWX与CLI并不直接联系在⼀起。这意味着，除⾮进⾏了同步过程，否则
CLI⾥⾯的配置元素不会出现在Web⽤户界⾯中。你可以使⽤那个内置的同步⼯具，让两者保持⼀致，但需要按照预定计划运⾏同步⼯具。　SaltStack
  Salt类似Ansible，因为它也是基于CLI的⼯具，采⽤了推送⽅法实现客户端通信。它可以通过Git或通过程序包管理系统安装到主服务器和客户端上。客户端会向主服务器提出请求，请求在主服务器上得到接受后，就可以控制该客户端了。
  Salt可以通过普通的SSH与客户端进⾏通信，但如果使⽤名为minion的客户端代理软件，可以⼤⼤增强可扩展性。此外，Salt含有⼀个异步⽂件服务器，可以为客户端加快⽂件服务速度，这完全是Salt注重⾼扩展性的⼀个体现。
  与Ansible⼀样，你可以直接通过CLI，向客户端发出命令，⽐如启动服务或安装程序包；你也可以使⽤名为state的YAML配置⽂件，处理⽐较复杂的任务。还有“pillar”，这些是放在集中地⽅的数据集，YAML配置⽂件可以在运⾏期间访问它们。
  你可以直接通过CLI，向客户端请求配置信息，⽐如内核版本或⽹络接⼝⽅⾯的详细信息。只要使⽤名为“grain”的库存元素，就可以描述客户端；这样⼀来，管理员可以轻松向某⼀种类型的服务器发出命令，不需要依赖已配置组。⽐如说，只要使⽤⼀个CLI命令，你就可以向运⾏某个内核版本的每个客户端发送命令。
  与Puppet、Chef和Ansible⼀样，Salt也提供了⼤量的模块，以处理特定的软件、操作系统和云服务。⾃定义模块可以⽤Python或PyDSL来编写。除了Unix管理外，Salt的确提供Windows管理功能，但它还是更擅长管理Unix和系统。
  Salt的Web⽤户界⾯Halite⾮常新，功能不如其他系统的Web⽤户界⾯来得全⾯。它提供了事件⽇志和客户端状态的视图，能够在客户端上运⾏命令，但除此之外乏善可陈。
  Salt的最⼤优点在于可扩展性和弹性。你可以有多个级别的主服务器。上游主服务器可以控制下游主服务器及其客户端。另⼀个优点在于对等系统，让客户端可以向主服务器提出问题，然后主服务器从其他服务器得到答案，提供全⾯信息。如果需要在实时数据库中查询数据，以便完成客户端的配置，这个优点就很⽅便。
  选⽤Puppet、Chef、Ansible还是Salt?
⼯具语⾔架构协议
Puppet Ruby C/S HTTP
Chef Ruby C/S HTTP
Ansible Python⽆Client SSH
Saltstack Python C/S(可⽆Client)SSH/ZMQ/RAET
  Puppet和Chef会吸引⼴⼤开发⼈员和注重开发的公司，⽽Salt和Ansible极其适合系统管理员的要求。Ansible的简洁界⾯和可⽤性⾮常迎合系统管理员的想法;⽽在拥有许多Linux和Unix系统的公司，Ansible运⾏起来⼀开始就快速⼜轻松。
  Salt是四款⼯具中最漂亮最稳健的；与Ansible⼀样，它也会博得系统管理员的芳⼼。Salt拥有⾼扩展性和强⼤功能，唯⼀的软肋就是Web ⽤户界⾯。
  Puppet是这四款⼯具中最成熟的，从可⽤性的⾓度来看恐怕也最容易上⼿，不过竭⼒建议你对Ruby要有深⼊了解。Puppet不如Ansible 或Salt来得精简，配置起来有时会变得错综复杂。对异构环境来说，Puppet是最稳妥的选择，但是你可能会发觉Ansible或Salt⽐较适合更庞⼤或更⼀致的基础设施。
  Chef拥有稳定的、精⼼设计的布局，虽然它在原始功能⽅⾯远未达到Puppet的⽔平，但这是款功能⾮常强⼤的解决⽅案。要是管理员缺乏丰富的编程经验，Chef学起来可能最困难，但它也许最适合注重开发的管理员和开发部门。ssh工具手机版

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。