转载

SaltStack/Ansible/Fabric 的选择

本站文章除注明转载外，均为本站原创或者翻译。
本站文章欢迎各种形式的转载，但请18岁以上的转载者注明文章出处，尊重我的劳动，也尊重你的智商；
本站部分原创和翻译文章提供markdown格式源码，欢迎使用文章源码进行转载；
本博客采用WPCMD 维护；
本文标题：SaltStack/Ansible/Fabric 的选择
本文链接： http://zengrong.net/post/2610.htm

运维自动化管理必须要提上日程了。因为 Python 语言的关系，我将选择的目标定在 SaltStack 、 Ansible 、 Fabric 上。

我的选择是 Salt 。

查看选择系列文章。

Fabric 和 Salt/Ansible 并非一个级别。它适合用来做较少的服务器管理。如果超过 10 台服务器，用它就不太合适了。况且，Fabric 可以很容易和其他系统整合在一起使用。

Salt 和 Ansible 倒是不相上下。下面做一些比较：

下面表格中的所有的实时数据采集时间为 2016-12-13 20:09:26 。

Key	Salt	Ansible	备注
公司支持	SaltStack	Ansible
开源	Salt	Ansible
Star	7140	20199
Opend Pull requests	43	621	可以从侧面说明社区解决问题的速度
Opend Issues	4026	621	可以从侧面说明产品稳定性
Contributors	1665	2301	可以从侧面说明社区活跃度

下面的判断是我根据互联网上到的信息总结而成。其中有些信息可能不准确、不可靠或已经过时，请自行判断。

Salt 和 Ansible 都使用 YAML 做为配置，且都支持 Server-Client 模式。Salt 默认就使用 ZeroMQ 队列，而 Ansible 默认使用 SSH 协议。 在默认情况下 ，Salt 会比 Ansible 快很多（根据测试，大约40倍）。而 Ansible 部署起来比 Salt 又方便很多（因为不用安装 Agent）。

注意我前面说到了 在默认情况下 。实际上， Salt 可以使用 salt ssh 基于 SSH 实现 agentless 部署。Ansible 也可以使用 fireball 模式来得到和 Salt 完全相同的速度。然而，Ansible 已经将 fireball 模式废弃了，更推荐使用 SSH 的 pipelining ，根据官方文档，这能大幅提升通过 SSH 部署的速度。

所以啊，说 Ansible 慢并不是很准确，说 Salt 无法 agentless 也未必。

关于 Agent，个人认为大可不必将其作为决定选择的条件。无论如何， Agent 的部署是很简单的。需要考虑的，应该是 Agent 的安全性。毕竟运维 Agent 权限那么高，本身就是一个大后门啊！！！

好的 Web UI 是非常非常非常重要的。

当我在搜寻 Salt 的 GUI 的时候，发现 salt-api 的文档 Outdated 了。后来找到了 halite ，发现官方又将其 DEPRECATED 了。最后才找到 SaltPad ，却发现它还只是个 Alpha 版本。这种更新速度也是让人醉了…… SaltStack Enterprise 的界面倒是看起来不错啊！就是不知道多少钱……

Ansible 的 Tower 看起来也不错，100 个 node 也只要 $5000 每年挺便宜的…… 另外有一个社区的开源替代版本 Semaphore 。

开源产品最重要的就是文档。从文档的卖相来看，两者都是不差的。但互联网上找到的大多数资料都提到了 Ansible 的文档比较乱，而且挺多错误。我没有仔细看过两者的文档，不发表评论。但再乱也乱不过Redmine 的文档吧？