开源自动化配置管理工具ansible、saltstack、Puppet、Chef选择

深碍√TFBOYSˉ_ 2022-07-12 11:41 1595阅读 0赞

目前市场上主流的开源自动化配置管理工具有puppet、chef、ansible、saltstack。到底选择哪一个好？

我为什么选择Saltstack，考虑方式很简单，主要基于如下两个方面：

第一、语言的选择（puppet/chef vs ansible/saltstack）

开源技术，不看官网不足以熟练，不懂源码不足以精通

Puppet、Chef基于Ruby开发，ansible、saltstack基于python开发的

本人热衷于python（后期可做二次开发），排除Puppet、Chef

第二、速度的选择 (ansible vs saltstack)

管理配置讲究的是更快更稳

ansible基于SSH协议传输数据，Saltstack使用消息队列zeroMQ传输数据

测试SSH和MQ传输速度：

例：分别使用两种工具测试1000台服务器的连通性，结果对比：

\&lt;img data-rawheight="153" data-rawwidth="321" src="https://pic1.zhimg.com/ac7a953dd1698d6449296c43a2e24fac\_b.jpg" class="content\_image" width="321"\&gt;可以看出使用MQ通讯和SSH通讯,速度相差大约40倍![ac7a953dd1698d6449296c43a2e24fac_b.jpg][]可以看出使用MQ通讯和SSH通讯,速度相差大约40倍

显然，从速度的角度，排除ansible，最终选择了Saltstack。

在python系列的ansible、Saltstack的选择中，有人放弃Saltstack的主要原因是Saltstack需要安装客户端，在服务器有一定数量的情况下比较麻烦，而ansible不需要安装客户端。我个人认为这个考虑是多余的，Saltstack中的Salt-ssh可以轻易解决这个问题（后面会写篇使用salt-ssh批量部署客户端的博客），而且ansible也并非是不需要在“客户端”做任何操作。例如，1.“客户端”系统python版本需要满足2.6+，否则需要进行升级；2.ansible使用一些功能也需要“客户端”有对应模块（主要是python模块，即使python版本满足2.6+，也需要额外安装）

================================================================

我们前阵子在做DevOps这块的调研，应该说在中小规模的公司里，Saltstack和Ansible这两块选用的人都不少。  
  
大家选择这两个平台所做的依据，其实上面各个答主也基本都有提到。  
**1、是否需要每台机器部署agent（客户端）**  
很多选用ansible的朋友，都是因为agentless这个原因，觉得要维护agent很麻烦。  
而一些使用saltstack比较顺的朋友，觉得这个问题无所谓，agent出问题的概率有，但不高。  
  
其实ansible也支持agent的方式，即所谓的“pull”的模式，就是通过一个客户端去拉取要执行的任务。  
  
**2、大规模并发的能力**  
这方面的对比已经比较多了，因为实现机制的差异，也导致saltstack在这方面是占优的。  
不过对于几十台-200台规模的兄弟来讲，ansible的性能也可接受。  
  
注：我前期调研的大多数都是中下企业，服务器规模一般不超过200台，所以对这个问题不算太看重。如果一次操作的机器过千台，可能还是用saltstack效率更高一些。  
  
**补充-20161114：我们正在改造ansible的执行架构，采用基于MQ的agent机制，以支持比较大规模（1000-10000台）的服务器的批量自动化运维。这样，在这种存在大规模运维的需求的客户这里，也可以应用丰富的ansible的Playbook了。  
  
3、二次开发扩展的能力**  
ansible和saltstack都是基于python的，而python在运维开发这个圈子里接受度还是非常高的，二次开发的人员相对也好招。  
这也是这两个工具相对于puppet和chef更容易被接受度原因，这两个曾经的主流工具都是基于ruby，而现在ruby的活跃度越来越低了，要招人也不容易。  
  
ansible和saltstack都具备很好的二次开发扩展能力，可以写YAML编排。  
  
**4、开源社区的对接**  
在github上，ansbile有18300多颗星，salt有6700多颗星。  
直接按关键字搜索，ansible的相关项目也更多一些。  
  
这些指标虽然不能直接说明什么，但很多技术人员会关注自己所使用的技术的活跃度。  
一般来说，越活跃的开源项目，得到的关注会更高些，功能完善和问题解决的效率也会更高。  
  
**5、学习的门槛**  
从第一次使用来讲，ansible的部署配置会更简单一些。  
从官方文档的质量来看，saltstack就比ansible要好一些。  
  
从国内的中文资料来说，ansbile和saltstack好像各有2-3本中文书。  
这两家的国内用户组也分别在做一些技术资料翻译的工作。  
  
**6、操作界面的友好程度**  
试用过Ansible的Tower，但实在是不喜欢这种操作习惯，只能说勉强可用。  
saltstack的没仔细用过，但看过朋友搭建的环境，感觉官方的UI还可以，基本够用了。  
  
Ansible的最初设计定位就不是一个完整的运维管理系统，因此官方UI粗糙些也在预料之中。  
  
**7、第三方工具的丰富程度**  
ansibe有一个galaxy站点： Ansible Galaxy  
这个站点集合了3000多个第三方开发的Role/Playbook。  
  
salt也有一些预先写好的Formulas（Formulas are pre-written Salt States）  
官方地址： Salt Formulas  
github地址： Salt Stack Formulas · GitHub  
目前已有的Formulas大概在200个左右，比ansible galaxy少了一个数量级，不过大部分常用软件也覆盖到了。  
  
**8、现有用户使用的规模**  
根据rightscale的调研报告：  
Ansible在2015年有10%的用户选用，而2016年有20%的用户选用。  
Saltstack在2015年有6%的用户选用，而2016年有9%的用户选用。  
  
**9、对Windows支持的友好程度**  
这一方面我没有直接的经验，感谢  @小菘Barry 提供的如下反馈：  
“ansible对windows的支持简直不忍直视，agentless只是对于linux的，windows要安装bug修复补丁，powershell还要3.0，还要安装python。还不如salt方便。”  
这一点供大家参考。  
  
我们自己目前是用的Ansible，但正在结合我们自己的DevOps平台，重新给Ansible开发一套WEB UI。

[ac7a953dd1698d6449296c43a2e24fac_b.jpg]: /images/20220710/f6a6de3eec8c4043ba22f60cf27198b8.png