目前市场上主流的开源自动化配置管理工具有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台服务器的连通性，结果对比：

可以看出使用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效率更高一些。

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还可以。

7、第三方工具的丰富程度
ansibe有一个galaxy站点：Ansible Galaxy
这个站点集合了很多第三方开发的Role/Playbook。

salt好像没有这样的集中站点，好像得自己去github搜了。
（如果有谁知道有这样的站点，麻烦告知一下）

8、现有用户使用的规模
根据rightscale的调研报告：
Ansible在2015年有10%的用户选用，而2016年有20%的用户选用。
Saltstack在2015年有6%的用户选用，而2016年有9%的用户选用。


我们自己目前是用的Ansible，但正在结合我们自己的DevOps平台，重新给Ansible开发一套WEB UI。

在 60 台左右的 Ubuntu 14.04 服务器上使用过 Ansible，在此之前用了一段时间 Saltstack，Ansible的文档完全是文档的反面教材，相反 Saltstack就好多了，API也有。Ansible 很多危险的 Playbook 指令都是在自己的 VPS上试过后才敢在生产环境用，不过好在 Ansible 源码还挺好懂的，有空可以看看，遇到坑一定要去看源码，playbook 模块可以抽出来单独用，写python脚本来操作，ssh登录被误操作锁住的问题确实存在，刚开始我有一次用ansible操作防火墙失误把所有生产机登录端口全锁了，好在所有机器上面都装了 Saltstack，用Saltstack 命令把端口解禁了（当时真是吓尿了），其实二者配合起来使用完全没有问题，Saltstack 的API可以探索探索，做个服务器监控什么的，ansible 对我来说更像便携武器，ad-hoc执行临时命令，非常方便。我比较期待的是一个操作回滚功能，好像二者都没有，一个问题是在包含较多task的playbook执行失败时，如何从失败的那个task开始重新执行的问题，不知道有没有人知道。

其实，我决这两个东西都是有各自的优点。

就是看那个东西更新符合你们的业务状况，

比如我公司的业务就是有一个中心的跳板机，是通向所以server的，这让我使用ansible非常方便，不在每个server上去装client端。

ssh被禁，你可以要求执行的时候，输入密码也行啊