【DevOps】Ansible v.s. Salt (SaltStack) v.s. StackStorm

Chinese, Simplified

在过去的一个月里，我听取了对所有 3 种产品的开发人员的采访，并听到了“将 [Ansible/Salt/StackStorm] 视为粘合剂”的说法。现在，我是一个 DIY 爱好者，我可以放心地告诉大家，我的车库里没有 1 罐胶水。根据工作、材料和环境，我有 6 种不同的类型。这 3 个产品属于同一个阵营，它们都可以用来取得巨大的成功来实现非常不同的事情，最近一个很大的重叠是它们正在进入网络自动化领域。以下观点仅代表我个人，而不是我的雇主（他们出售了数十亿美元的网络基础设施和部署）。



我使用了所有 3 个产品，对 2 个（Salt 和 StackStorm）做出了重大贡献，并参与了对 Ansible 的贡献。坦率地说，我最不熟悉的产品是 Ansible，但我已经说过并从同事那里收集信息以在适当的时候填补空白。



如果你要跳到最后，看看我宣布哪个获胜者——你会失望的。考虑您的要求并尝试其中一种以上的产品。

一些问题要问自己：

  • 我需要支持哪些环境？我的服务器和网络设备的组合是什么？
  • 谁是我的用户？这是针对核心系统管理员类型、信息安全团队、开发人员的吗？
  • 我愿意做多少定制开发？

代理 v.s.无代理



这真的很重要，所以请注意。在本文中，我将重点关注设备自动化和编排。这些设备可能是路由器、交换机、防火墙、下一代波发射循环器，都没有关系。重要的是他们不会在操作系统中安装代理。 Ansible 拥有使用 SSH 作为传输的传统，因此非常适合 SSH 是最低公分母的端点配置世界。 SaltStack 是作为高速和安全的 Minion（代理）掌握通信的总线而诞生的，它也具有无代理模式。 StackStorm 是最后进入该领域的，并且在设计上远离任何一种选择，它通过面向 Chef、Puppet、Salt 的包支持基于代理的工具，以及它自己的基于 SSH 的远程控制和对调用 Ansible 剧本的本机支持。

 

API



另一个关键区别是 API，

  • Ansible 可用作 CLI，Ansible Tower（企业版）有一个 API，
  • StackStorm 有一个 CLI，但也有免费版本中所有组件和服务的 REST API，
  • Salt 有 CLI 和 REST API（默认情况下未启用），您还可以使用“Enterprise API”作为包含 RBAC 等功能的 Enterprise 产品的一部分。



Ansible



Ansible 是 Michael DeHaan 的创意，开发用于在大型环境中自动化繁琐的服务器管理任务。 Michael 曾在 RedHat 的新兴技术小组工作，在那里他创立了 Cobbler 等其他项目，然后在离开 RedHat 后继续创立 Ansible（尽管 Ansible 现在归 RedHat 所有）。从迈克尔关于 Ansible 基础的博客中，它的目的很明确；

“我们想在 Red Hat 创建另一个非常民主的开源项目，该项目可以拥有广泛的贡献者并解决新问题。我们又想到了busrpc。这个项目存在是因为它填补了 Cobbler 和 Puppet 之间的空白。 Cobbler 可以提供一个系统，而 Puppet 可以放置配置文件，但是因为 Puppet 过于声明性，你不能用它来做诸如重启服务器之类的事情或在两者之间执行所有“临时”任务”

这些临时任务演变成 Ansible 剧本，Ansible 模块生态系统迅速诞生并蓬勃发展。

设计



Ansible 很简单，这是一个主要优势（并且在查看其他 2 个时会变得清晰）。没有守护进程，没有数据库，安装要求非常低。您只需在 Linux 机器上安装 Ansible 即可。在静态文件中定义目标服务器，将其分组为有意义的部分，或者使用动态主机发现模块（如 Amazon EC2 或 OpenStack）根据 API 调用查找 VM。一旦你有了清单，你就可以构建主机或组特定的变量，你的剧本可以利用这些变量。这些再次保存在静态文本文件中。

然后 Ansible 将连接到您选择的主机或组并执行剧本。 playbook 是一系列 Ansible 模块，您希望在使用 YAML 编写的远程主机上执行这些模块。

当它连接到远程主机时，这有点像精心策划的军事演习，上车、干活然后下车。

Ansible 的工作原理是使用 SSH（或 Windows 的 WS-Man/WinRM）连接到服务器，复制 Python 代码，执行它，然后自行删除。



架构



Ansible 的架构很简单，你有在你的机器上运行的应用程序，你有在远程主机上运行的任务，通过 SSH 进行通信并通过 SCP/SFTP 传输文件。 Ansible 没有像其他 2 个产品那样的“服务器-客户端”架构，因此您可以在机器上并行执行任务，但不能跨多个服务器扩展（除非您使用 Tower）。

当 Ansible 管理远程机器时，它不会在这些机器上安装或运行软件，因此在迁移到新版本时如何升级 Ansible 没有真正的问题。



可扩展性



Ansible 模块真的很容易开发，与所有 3 个产品一样，如果您以后决定尝试将您的解决方案合并到产品的开源存储库中，而不是再次重构它，请阅读样式指南。

#!/usr/bin/python

import datetime
import json

date = str(datetime.datetime.now())
print json.dumps({
    "time" : date
})

ansible/hacking/test-module -m ./timetest.py

您应该会看到如下所示的输出：

{"time": "2012-03-14 22:13:48.539183"}

在模块中，您可以定义自己的“收集”阶段代码，以建立有关远程主机的“事实”，供您或其他模块使用。 这可能类似于查看安装的文件或配置以确定服务的设置方式。



企业支持



Ansible Tower 是企业版，它将命令行 Ansible 变成一个服务，具有 Web 界面、调度程序和通知系统。

Task Scheduler

它还具有用于云部署手册的 UI，因此您可以通过 UI 自动部署云基础架构，然后自动将这些 VM 添加到清单中。

值得注意的是，任务调度、云部署和服务器是 Salt 和 StackStorm 免费版本的功能。



网络支持



Ansible 的网络故事是三者中最成熟的，涵盖所有主要网络供应商和平台，借助 Ansible，您可以：

  • 通过使用网络平台特定的模块和脚本，自动配置从系统到核心服务访问的网络堆栈
  • 测试和验证现有网络状态，实施或利用收集过程来确定有关现有配置的事实
  • 持续合规以检查网络配置漂移

Ansible 支持 Arista、Cisco（所有可编程平台）、F5、Juniper 以及其他供应商。 Ansible 的独特之处在于，供应商支持主要由供应商提供和支持，而不是社区。目前，这表明 API 覆盖范围更广、功能更多、平台支持更新（支持更新版本）。



优势

 

  • 非常快速和简单的开始
  • 大量社区示例、文档和模块
  • Ansible Tower 为大型企业部署实施功能
  • 供应商支持的网络模块



弱点

 

  • 如果无人监管，操作员可以将剧本和 SSH 密钥完全保存在他们自己的笔记本电脑上。不完全是 Ansible 的错，但要密切关注这一点，
  • 没有事件驱动的自动化故事，你可以在剧本的持续时间内控制目标主机，就是这样，你不能有长时间运行的任务。

StackStorm



我从 v0.11（早期预测试版）一直使用 StackStorm，一直到最新的 v2.2。这是一个复杂而广泛的平台，就像 Salt 一样，需要一段时间才能向人们描述，并且经常会导致误解。我认为这既是优点也是缺点。这是一个弱点，因为它的复杂性可能会令人反感，并导致人们部署错误的解决方案，而 StackStorm 非常适合（通常人们从头开始编写自己的解决方案）。一旦你了解如何利用它的力量，它就会变得非常灵活。

StackStorm UI

设计



StackStorm 的核心是一个可插入的规则和执行引擎，它被设计为一个高度可配置的 IFTTT（if-this-then-that）服务。您可以告诉 StackStorm 对已发生的事件做出反应，然后运行一个简单的“操作”（命令）或复杂的工作流。工作流有 2 种风格，ActionChain（他们专有的工作流 DSL）或使用 OpenStack Mistral——一种基于 YAML 的工作流引擎。

StackStorm 还提供“chatops”服务，您可以在其中通过聊天平台（例如 Slack）中的事件或消息触发您的工作流程。

StackStorm 的核心命名法是；

  • 传感器是用于入站或出站集成的 Python 插件，分别接收或监视事件。当来自外部系统的事件发生并被传感器处理时，StackStorm 触发器将被发送到系统中。
  • 触发器是外部事件的 StackStorm 表示。有通用触发器（例如计时器、网络钩子）和集成触发器（例如 Sensu 警报、更新 JIRA 问题）。可以通过编写传感器插件来定义新的触发器类型。
  • 操作（Actions ）是 StackStorm 出站集成。有通用操作（ssh、REST 调用）、集成（OpenStack、Docker、Puppet）或自定义操作。操作是 Python 插件或任何脚本，通过添加几行元数据使用到 StackStorm 中。操作可以由用户通过 CLI 或 API 直接调用，或者作为规则和工作流的一部分使用和调用。
  • 规则将触发器映射到操作（或工作流），应用匹配条件并将触发器有效负载映射到操作输入。
  • 工作流将动作拼接成“超级动作”，定义顺序、转换条件和传递数据。大多数自动化不仅仅是一个步骤，因此需要多个操作。工作流，就像“原子”动作一样，在动作库中可用，可以手动调用或由规则触发。
  • 包（Packs）是内容部署的单位。它们通过对集成（触发器和操作）和自动化（规则和工作流）进行分组来简化 StackStorm 可插拔内容的管理和共享。 StackStorm 社区提供了越来越多的包。用户可以创建自己的包，在 Github 上分享，或提交到 StackStorm Exchange。
  • 手动或自动操作执行的审计跟踪与触发上下文和执行结果的完整详细信息一起被记录和存储。

设计



StackStorm 由许多服务组成，它们利用消息队列（rabbit）和数据存储（mongo）来保存状态和通信。 StackStorm 也有一个 WebUI（是的，即使在免费版本中），它使您能够配置规则、运行临时操作并检查审计跟踪。



架构

architecture

与 Ansible 和 Salt 不同，StackStorm 不是为端点配置或通信而设计的。 StackStorm 有 Salt、Chef、Puppet 和 Ansible 的包，所以如果你想使用 Chef 作为代理和配置管理系统，然后利用 StackStorm 调用基于 API 的服务，如 Sensu 或 Kubernetes，这很容易实现并且显而易见。对于 Salt，你仍然有在 minion 或 master 上执行的这个概念，如果你想调用 Kubernetes API，哪个机器调用 API 没有实际意义。网络设备配置也是如此。



MongoDB 可以使用有据可查的模式进行扩展，RabbitMQ 也可以。服务本身都被设计为 HTTP/RESTful API，并且可以进行负载平衡以进行横向扩展。根据您的需要，这些角色可以压缩为单个服务器或分布在多个服务器中。



我真的很喜欢 StackStorm 可扩展性系统，它绝对是其他 2 个产品的关键优势。 StackStorm 扩展点称为包，它们是自包含的，可以存储在 Git 中并通过包级 Python 虚拟环境管理自己的依赖项。安装包时，您指定 Git URL 或 HTTP URL、（可选）凭据和 StackStorm 将下载、配置和安装包。

如果 StackStorm 是一种编程语言，它将是强类型的。对于操作，您指定所有输入的类型，对于触发器，您指定字段和类型。这使得很容易知道 3rd 方扩展将返回什么，并且是 StackStorm 独有的。

与 Salt 和 Ansible 不同，StackStorm 没有捆绑任何扩展，它们都必须单独安装，这使得部署更轻，依赖项也很轻。

在为 StackStorm 开发集成时，您可以将传感器、操作和工作流构建到一个定义中。 Salt 和 Ansible 模块是独立的。因此，如果您对 say Salt 的扩展包括信标、执行模块和状态模块，那么除了名称和作者之外，它们不共享任何内容。这在管理 pip 依赖项时可能会很麻烦。

StackStorm 通过每个包都有自己的 requirements.txt 以及描述包的目的、要求和版本的 YAML 文件来解决这个问题。您可以内联升级包，它将保留现有配置。与 Ansible 和 Salt 不同，Packs 还包含模板化配置，其中模块配置格式仅保留在文档中，因此更容易出现用户错误。此外，当开发人员没有费心记录配置选项是什么时，您通常会扫描模块代码。

另一个独特的功能是 ChatOps “别名”（聊天命令）内置在包中。因此，如果您安装 NAPALM 包作为示例，它会自动安装 NAPALM 的所有聊天命令。



企业支持



StackStorm 是 Apache-2 许可的开源产品，托管在 GitHub 上。 StackStorm 归博科所有（最近被剥离，StackStorm 部分归极进网络所有）。

如果您获得 StackStorm 许可，您将购买名为“Brocade Workflow Composer”的产品，获得附加功能以及企业级支持。我使用的生产部署已获得许可，我发现他们的支持团队响应迅速且知识渊博。您还可以获得 RBAC，您可以在其中指定谁有权运行什么的操作级别。

Brocade Workflow Composer

网络支持



如果您使用的是 Brocade VLX 或 SDX，那么您很幸运，正如您所期望的那样，它们得到了很好的支持。

2017 年 4 月，他们合并了对 NAPALM 库的支持，这是一个用于 Cisco、Juniper、Arista 和其他公司的跨平台抽象 Python 包。 您可以使用 NAPALM 集成配置路由、接口、BGP 对等互连和其他一些漂亮的功能。 Matt Oswalt（O'Reilly 网络自动化书籍的合著者）写了一篇关于进展的不错的博客。

https://youtu.be/M7Zi2HbFelQ

优势

 

  • 免费的默认 Web UI 易于使用，并且几乎不需要 Python 或 DevOps 知识。
  • ChatOps 集成是内置的，开箱即用（使用 Slack，只需部署 API 密钥）并支持许多其他聊天平台。
  • 一旦你学会了 OpenStack Mistral 真的很强大，你可以跨越多个 DevOps 工具，轻松创建分支和循环，而无需
  • Brocade Workflow Composer 是让非开发人员利用该系统的好方法



弱点

 

  • 与 Salt 和 Ansible 相比，没有可用的扩展包范围。首先检查您的系统和 API 是否可用，还要检查包中有哪些功能。
  • 工作流系统 OpenStack Mistral 的文档仍然很糟糕，YAQL 查询语法中有很多尝试和错误。



Salt



首先，Salt 是产品，SaltStack 是公司。所以当我提到 Salt 时，我指的是 Salt Open，开源版本。

Salt 有一个庞大的命名法，一开始（当我说第一次时，我指的是第一年）它可能真的让人不知所措。 Salt 有很多作用，所以通常当你听到 Salt 粉丝将它与 Ansible 进行比较时，你会得到“是的，但它做得更多”的回应。与 StackStorm 类似，这适用于和反对 Salt。一旦你知道盐矿是什么，这很明显，但如果我只是告诉你从盐矿中获取谷物，你会认为我指的是托尔金小说。



设计



Salt 诞生于分布式远程执行系统，用于在远程节点或“minions”上单独或通过任意选择标准或“目标”执行命令和查询数据。

Salt 已扩展为配置管理系统，能够在定义的状态下维护远程节点（例如，确保安装特定的包和运行特定的服务）。 Salt 中有很多组件，我确定我错过了其他组件！

  • master，运行核心服务以与 Salt Minion 通信的服务器。它还包含用于在 Minion 之间进行加密的密钥库。
  • minions，代理运行一个微型版本的 Salt，用于本地执行和与 master 的通信。
  • 引擎（engines），Salt 引擎是利用 Salt 的长期运行的外部系统进程。
  • 状态或公式（states, or formulas），包含 YAML 和模板化数据的文件以配置 Minion。模板引擎也非常灵活。它不仅限于 Jinja，还包括 chetah、genshi、mako（对于那些来自 Puppet 背景的人来说非常重要）、wempy 甚至纯蟒蛇。

可以使用谷物（grains）、支柱（pillars ）或标识符（identifiers）来定位小兵（Minions ）（代理或常规）。还有其他定位插件（您可以基于 SQL 查询或 KVP 存储等开发自己的插件）。

  • 谷物（grains），Salt 带有一个接口来获取有关底层系统的信息。这被称为颗粒界面，因为它提供了带有信息颗粒的盐。为操作系统、域名、IP 地址、内核、操作系统类型、内存和许多其他系统属性收集 Grain。谷物接口可用于 Salt 模块和组件，以便正确的 salt minion 命令在正确的系统上自动可用。
  • 支柱（pillars），支柱是 Salt 的接口，旨在提供可分发给 Minion 的全局值。支柱是一种自由形式的数据资源（可以是 JSON、YAML 或您需要的任何格式），可以存储在文件中，也可以存储在外部。这是 Salt 的独特属性，允许与共享数据存储有价值的其他系统（例如 ITSM 或资产注册）集成。

对于数据获取，您还可以从 minion 返回数据并将其存储在盐矿中，以用于其他任务，例如基于模板的状态配置。与 Ansible（仅支持 YAML）不同，它可以采用多种格式。



架构



Salt 的架构基于中心辐射式方法。一些非常大的部署有多主，但这种情况很少见。部分由于轻量级消息总线 ZeroMQ，主节点可以轻松扩展到数千个节点。其他部署模型是

  • 无主设置，以及
  • 等级大师（Hierarchical masters）能够使用合成器在它们之间进行通信。

master 包含状态文件，您通常会将其放入共享存储卷中。这些设置在树中，以便您可以使用目标来指定要配置的服务器组和要部署的环境/应用程序。

Salt

Salt 基于事件的系统正在使用信标。与 StackStorm 的传感器和触发系统类似，Salt 的信标将事件发送到消息总线中，然后可以在反应器中（在主节点上）进行处理。与 StackStorm 相比，反应堆中的规则引擎相当粗糙，因为您通常在触发事件的信标背后触发状态或执行命令。但是，信标在 Minion 上运行，因此如果您在服务器上检测事件，这是直接的。因为 StackStorm 和 Ansible 是无代理的，所以这是 Salt 的一个独特功能。

钍（Thorium），盐的复杂反应器在上一个版本中是实验性的，可能会在未来版本中得到支持。它增加了对事件聚合和更复杂规则的支持。



可扩展性



Salt 中的所有内容都是可扩展的，直到在 CLI 中显示执行结果的模块。这对 Salt 来说是一大优势，因为您可以轻松开发自己的更改，而无需维护主项目的并行分支。 Salt 中的每个功能也是可插拔的。

可扩展性最常见的场景是开发状态模块（描述应如何配置软件或服务）或执行模块（与 API 或系统对话的代码）。状态和执行模块都可以用相对较少的样板来编写，有很好的文档记录，并且内置了可靠的单元测试运行程序。您可以使用 PyTest 对模块进行单元测试，而无需在主机上或运行主机，以进行集成测试你应该在 Linux 上，尽管通过一些黑客攻击你可以在 OSX 上运行它们（Windows 是不可能的，就像 StackStorm 和 Ansible 一样）。

您可以维护自己的独立包，也可以直接为 GitHub 上的 Salt 项目做出贡献。为主要项目做出贡献的最大缺点是您需要等待每个发布周期，以便用户能够轻松安装您的模块。按照目前的节奏，大约每 3 到 5 个月一次，因此虽然 Salt 是“包括电池”，但它也有缺点。

Salt 还有一个包管理器，SPM，主要用于捆绑他们的配置管理（状态文件）公式。您可以使用它来打包模块以解决我将在弱点中提到的缓慢发布周期（尽管这不是很好的文档）。

盐在过去几年中发展非常迅速，并发生了一些重大变化。因此，社区开发的模块之间可能存在不一致。我还发现，虽然不是 Salt 独有的，但社区提供的模块测试不佳。

企业支持



“Salt Open”是开源版本，您可以许可 Salt Enterprise，它带有一些简洁的功能，例如：

  • 用于定位、执行、符合“高状态”以及与 LDAP 集成的 Web UI，
  • ServiceNow 集成，使您能够配置新服务器并应用来自 ServiceNow ITSM 集成的状态，
  • RBAC 与 LDAP 集成（自然），
  • “企业 API”，它将企业功能包装到 REST API 中。



网络支持



因为 Salt 依赖于消息总线，而 ZeroMQ 有许多依赖项，通常需要一个完整的 OS 网络设备管理，所以不是 Salt 的明显用途。在上一个版本中，Salt 大大改进了对“代理仆从”的支持。 Proxy minion 是一个虚拟的 minion，它是一个可以在任何地方运行的进程，以便通过 SSH、HTTP 或其他传输机制远程控制设备。它利用与常规 minion 相同的功能，但也有一些特殊性。为了避免与 Puppet 代理（它是一个中央机器，所有请求都通过它）混淆，它只是一个与您的目标设备相关联的进程，因此每个 minion 一个单独的进程。它通常是轻量级的，消耗大约 40MB 内存。您可以通过开发可在 Minion 上执行的 Python 模块来开发代理 Minion。 Salt 团队在去年的 SaltConf 上演示了这个。

目前支持的网络平台有：

  • JunOS (Juniper)
  • NXOS (Cisco)
  • Cisco NSO (Cisco’s NETCONF orchestrator)
  • NAPALM

salt_enterprise

由于 Cloudflare 的一些非常聪明的工程师，Salt 最近合并到了 NAPALM 支持中。 NSO 和 NAPALM 有相似之处，但由于 NSO 承担来自思科的许可成本，您需要考虑尽早采取哪条道路。

https://youtu.be/99jHvkVM0Dk

优势

 

  • Salt 支持基于代理和无代理（salt-ssh）
  • ZeroMQ 为大型部署提供超高性能
  • 基于代理的架构允许将信标部署在基于 Windows 或 Linux 的主机上，并允许在本地检测事件
  • 一些非常大的部署，例如LinkedIn 大规模使用
  • Salt 可以通过其强大的可扩展性轻松融入现有的数据库或 API 集。



弱点

 

  • 对于快速移动的环境，内核中内置的可扩展性发布太少
  • 模块不能干净地声明自己的依赖项，这意味着您必须管理单个虚拟环境和 pip 依赖项



结论



事件驱动与否？



这是这 3 款产品最大的不同，Salt 和 StackStorm 都有事件驱动的故事。 StackStorm 具有您可以编写的服务（传感器）和可以引发的强类型事件以及复杂的规则引擎。 Salt 有信标，可以在代理和中央主机上运行的服务，如果你想检测本地机器上的事件，这是一个独特的功能。 Ansible 的开源版本不允许（也不会尝试）允许您响应事件。



社区支持



我见过网络供应商专门针对 Ansible 开发模块，而对于其他平台（除了用于 StackStorm 的 Brocade），他们都是社区贡献的。 Ansible 当然对网络平台有最广泛的支持。虽然，随着 NAPALM 和 NSO 被引入 StackStorm 和 Salt，这改变了事情，因为它们都支持 Arista、JunOS（瞻博网络）、Cisco APIC-EM、NXOS 等。



开始的时间



Ansible 的优势在于最少的配置量（基本没有）。它在网络领域的流行可能是由于网络管理员习惯于使用 CLI 之类的东西来管理远程设备而无需部署任何额外的服务器来运行软件的简单性和熟悉性。如果您有很多小的、孤立的站点（例如商业分支机构），那么您应该考虑您的架构是否会崩溃。我的雇主为一些大型连锁超市管理网络，当农村地区的商店连接不可靠时，我会犹豫是否拥有一个集中的主人。

数据配置存储



Salt 的独特之处在于它的密钥库都是可插拔的。如果您想从 Hashicorp Vault 获取密码或密钥，这很容易。如果您想将谷物数据存储在 SQL 数据库中，它同样是开箱即用的。考虑访问或输入您的目标数据需要哪些其他系统和平台。



安全



比较 Ansible 和 Salt，Salt 有自己的密钥库用于代理通信，而 Ansible 使用 SSH 进行传输。管理不善的 Ansible 环境通常是存储在管理员笔记本电脑上的一堆私钥（请不要这样做）。 Salt 为模板、状态或谷物中的安全数据提供了独特的功能，这些数据能够存储在外部安全数据存储中。 StackStorm 确实将数据保存在 MongoDB 中，在您投入生产之前，您的安全团队当然需要对其进行审核。



培训



除非你想成为这个平台的唯一维护者，否则你需要教育一些同事。 Salt 和 Ansible 都出版了详细的书籍，而 StackStorm 没有。 Salt 和（RedHat）Ansible 提供培训解决方案，几乎完全在美国，StackStorm 还没有。 Salt 和 Ansible 有关于 PluralSight 的课程，但它们非常基础。



许可



Salt 和 StackStorm 都是 Apache-2 许可的，Ansible 是 GPLv3。如果您不太熟悉 OSS 许可，我推荐“TLDR Legal”的网站。 SuSE 使用 Salt 作为示例来构建系统管理产品，部分原因是其 OSS 许可的灵活性。



技能



有趣的是（尽管我非常关注这一点），Ansible 获得了全球网络管理员和 DevOps 工程师的良好思想分享。你肯定会发现招聘 Ansible 工程师比 Salt 或 StackStorm 容易得多。但是 DevOps 工程师仍然像母鸡一样罕见，因此无论平台如何，您都将支付高昂的费用。



我应该选择哪种胶水？



请尝试至少 2 个平台并做出明智的决定。

我之前曾在博客中讨论过这一点，但是使用 DevOps 工具，人们可以在学习工具的同时发现自动化的奇迹，然后虔诚地坚持使用该工具。



就像第一次发现巧克力的孩子一样，您不应该只相信那短暂的快乐纯粹是吉百利的功劳。

原文：https://medium.com/@anthonypjshaw/ansible-v-s-salt-saltstack-v-s-stacks…

本文：https://jiagoushi.pro/node/1651

  • 82 次浏览
SEO Title
Ansible v.s. Salt (SaltStack) v.s. StackStorm