前言
Saltstack 和 Ansible 最初都是作为执行引擎构建的。也就是说，如果需要，它们允许在一个或多个远程系统上并行执行命令。
- Ansible 支持在多台计算机上执行任意命令行命令。它还支持执行模块。一个Ansible模块基本上是写在一定Ansible友好的方式一个Python模块。大多数标准的Ansible模块都是同等的。这意味着你告诉他们你希望系统进入的状态，并且模块尝试使系统看起来像这样。Ansible 有 Playbook 的概念 。Playbook 是一个文件，为一组主机定义了一系列模块执行。Playbook 可以改变执行主机模块的方式。这样就可以协调多台计算机，例如在升级应用程序之前将它们从负载平衡器中取出。
- Saltstack 有两种类型的模块；execution (执行)模块和 state (状态)模块。执行模块是简单地执行某些操作的模块，它可以是命令行执行或下载文件。状态模块更像 Ansible 模块，其中参数定义状态，然后模块尝试实现该结束状态。通常，状态模块在大多数工作中都使用执行模块。状态模块是使用 state 执行模块执行的。状态模块还支持在称为 SLS 文件的文件中定义状态。在 top.sls 文件中定义了哪些状态适用于哪些主机 。
- Playbook 和 SLS文件（通常）都是用 YAML 编写的。作为一个旁注，我想指出一个远程执行引擎对于诸如在多台机器上启动特定操作之类的任务非常有用。
结构
Salt 围绕一个Salt Master 和多个启动时连接到该主节点的 Salt Minions 构建。通常，命令是在主命令行上发出的。然后，Master 将那些命令分派给 Minions。最初，Minions 发起一个由加密密钥交换组成的握手，之后它们具有持久的加密 TCP 连接。因此可以快速到达 Minions。还缓存各种数据以加快执行速度。支持 ZeroMQ 库进行通信。Salt 还支持使用 SSH 而不是使用 Salt SSH 的 ZeroMQ 。但是请注意，它是 Alpha 软件（我还没有尝试过）。
Ansible 是无主从概念的，它使用 SSH 作为其主要通信层。这意味着速度较慢，但也因为无主从，可能会使运行安装程序和测试 Ansible Playbook 更加容易。有人说它也更安全，因为它不需要其他服务器应用程序。这在下方的“安全性”可以详细了解该内容。Ansible 也支持 ZeroMQ 版本，但需要初始 SSH 连接才能进行设置。我尝试了一下，说实话，我并没有看到有很明显的提速。我想可能是在大型的 Playbook 和有更多的主机才可以看到明显效果吧。要列举机器，建议你使用一个 Ansible Inventory 文件，该 Inventory 文件基本上包含按组分组的主机列表，还具有添加到组或单个主机的属性。你可以有多个库存文件，例如，一个用于登台，一个用于生产。结构简单清晰。
社区
Ansible 项目的其余部分似乎不是社区的努力，而是迈克尔·德哈恩（Michael DeHaan）的单人秀。好消息是所有问题都会得到相应的回应。迄今为止，Salt 已被证明是一个更受欢迎的社区。问题可能要花大约 4 天的时间才能得到答复，但似乎大多数问题最终也都会得到跟进。我的明确印象是，Salt 在受欢迎和协作方面拥有更成熟的社区。
速度
尽管你可能认为只有几台服务器时速度并不重要，但我认为你是错的。能够快速迭代始终很重要。启动缓慢会降低你的速度。Ansible 始终使用 SSH 发起连接。太慢了，它的 ZeroMQ 实现（如前所述）确实有帮助，但是初始化仍然很慢。Salt 默认使用 ZeroMQ，它是很快的。如前所述，Salt 可以缓存文件以更快地重新执行。
编排
Ansible 和 Salt都支持编排。我想说编排规则通常更容易获得 Ansible 的概述。基本上，一个 Playbook 分为几组任务，每个组与一组主机（或一个主机组）匹配。每个组按顺序按时间顺序执行。任务的执行顺序也是如此。Salt 支持 事件和 事件的监控。这意味着 Salt 执行可以触发另一台计算机上的事件。Salt 的执行引擎还可以实现诸如监控之类的功能，而未来的发展将非常有趣。Ansible 因其简单性而在这里获胜。Salt 之所以能胜任，是因为它能够对群集变化做出持续的反应。Salt 和 Ansible 都还支持在服务器窗口上执行任务。这对于确保服务始终可用非常有用。
安全
Ansible 使用 SSH 进行传输。SSH 是经过测试的协议。只要正确配置了SSH 服务器，我相信大多数人会认为 SSH 客户端是安全的。Ansible 还可以轻松地将多个非 root 用户连接到单个主机。如果你对进程运行非常挑剔， root 则应评估 Ansible。也就是说，Ansible 支持使用 sudo 来执行其模块。Salt 使用 AES 实现和密钥处理，需要安装 Minions。它为此使用了 PyCrypto 软件包。安全性是相当容易维护。还需要注意的重要一点是，root 默认情况下，Salt 运行其 Master 和 Minions 。这可以更改，但是显然如果你不是 root 用户，则很难安装 Debian 软件包等。我强烈建议，对于主服务器，可以将其配置为允许该 salt 命令为非 root 用户。
可审核性
在谈论安全性时，我也认为可审核性很重要。在这里，Salt 大赢家。Salt 执行的每次执行都会在主服务器上保存 X 天。这使调试变得很容易，而且还可以查看是否发生了异常的事情。
部署方式
Ansible 在这里绝对容易。无需部署。当然，Salt 支持 SSH，但文档主要采用 ZeroMQ。但是，SSH 仍然很慢。设置 Minions 的一件好事是它们是连接到主节点的 Minions。这样可以快速轻松地引导大量新机器。Salt 引导脚本 对于引导非常有用，并且轻而易举。它处理许多不同的分布，并且有据可查。
学习曲线
Ansible 在这里赢了。更容易上手和理解。主要是因为设置几个环境变量并开始执行你的 Playbook 以外，不需要做其他事情。Salt 可以在无主模式下运行。这使得它更容易启动和运行。但是，出于生产（和稳定性）的考虑，我建议启动并运行一个实际的 Master。
升级
升级 Salt 取决于安装方式。对于基于 Debian 的发行版，有一个 apt 存储最新 Debian 软件包的存储库。所以升级很简单 apt-get upgrade。对于 Ubuntu，有一个 PPA。两个存储库均得到积极维护。升级 Ansible 更加简单。你只需执行 git fetch && git checkout <tag> 而已。
文献资料
从文档开始，这两个项目都具有启动和运行，开发模块和配置设置所需的所有信息。Ansible 历史上比 Salt 拥有更好的文档结构。也就是说，最近在结构化 Salt 文档方面付出了巨大的努力。
结论
Ansible
优点
- Ansible 无代理部署和通信
- CLI 支持几乎所有编程语言
- 使用在 Linux 发行版中无所不在的 Python
- 使用 SSH / SSH2 的出色安全性
- 附加的塔式仪表板允许对节点/资源进行可视化管理（在商业版本中可用）
缺点
- 有时容易出现性能问题
- 缺乏内省（即查看 Playbook 变量值）
Salt
优点
- 由于具有多主机功能，因此可快速扩展，非常有弹性且高效
- 使用 Minions 比 Ansible 提供更多的选择和灵活性
- 尚无 GUI（目前正在开发中）
缺点
- 强迫用户学习 Python 或 PyDSL
- 未开发的 GUI
- 小型部署不如无代理通信那样高效
Ansible 是对自动化服务器配置和部署的出色介绍。它很容易启动和运行，并且具有出色的文档。展望未来，Salt 的可扩展性，速度和体系结构都不错。对于云部署，我发现 Salt 架构更合适。云部署将来我会毫不犹豫地使用 Salt，当然小型项目只有几台机器，建议还是 Ansible。综上所述，你应该在做出决定之前先对两个项目进行调整。他们的设置和测试相当快。
