SaltStack/Ansible/Fabric 的选择

  • 2016-12-19 更新: 增加一些对 Salt 文档的理解
  • 2017-04-16 更新: 增加一些对 SaltStack 简单上手

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

我的选择是 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 可以从侧面说明社区活跃度

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

Agent

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 部署的速度。

例如,Salt 文档的 Agentless Salt 中就提到了:

You can use Salt agentless to run Salt commands on a system without installing a Salt minion. The only requirements on the remote system are SSH and Python.

这已经和 Ansible 的部署方式相同了。更有趣的是,Salt 还提供了对 Ansible Inventory 支持!

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

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

Web UI

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

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

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

文档

开源产品最重要的就是文档。从文档的卖相来看,两者都是不差的。但互联网上找到的大多数资料都提到了 Ansible 的文档比较乱,而且挺多错误。但再乱也乱不过 Redmine 的文档吧?

仔细看过 Salt 的文档后,发现它的设计是真心不错:saltstack 简单上手

Windows 支持

Salt 有 良好的 Windows 操作系统支持

Ansible 从 1.7 版本才加入 Windows 支持 ,由于 Windows 默认没有 SSH 的缘故,它依赖 PowerShell remoting 来实现远程管理,要求必须使用 Linux 机器来控制 ,在控制机器上需要安装 pywinrm 包。有趣的是,从 Ansible 2.0 开始,一些配置中均去掉了 ssh 字样。例如 ansible_ssh_user, ansible_ssh_host, ansible_ssh_port 改名成了 ansible_user, ansible_host, ansible_post 。这应该也是为了迎合 Windows 服务器的需要吧?

从这一点来看,如果集群中有 Windows 服务器,应该尽量选择 Salt 。

Why Salt?

这个问题不好回答,说凭感觉又不合适。我想我应该是考虑了文档风格、模版语法风格、社区活跃性这三点吧。

其实起决定性的是 Windows 服务器支持。咦,我好像透露了什么……

参考

全文完