我目前正在尝试向管理层推销“DevOps”，我正在研究的事情之一是配置管理工具。对我们来说，最重要的事情之一是我们拥有一个具有高可用性和良好故障转移行为的系统。
- 对于 CF-Engine 来说这不是问题，因为每个节点都可以配置为服务器运行，并且如果服务器不可用，运行将继续。
- 对于 Puppet，您可以选择 Master/Masterless 模式以及它们的优点和缺点。
- 对于 Chef 来说，初始运行需要主服务器来获取策略，但是此后，如果主服务器不可用，则任何运行都将继续使用当前策略。
- 对于 Salt，如果主服务器发生故障，则不会强制执行配置，因为所有操作都在主服务器上完成
- 对于 Ansible（如 salt），如果主服务器发生故障，则不再强制执行配置，因为所有操作都由主服务器完成
我没有将 Windows PowerShell DSC 包括在此列表中，因为我当前的用户案例是我将使用 PowerShell DSC 来协助管理 Windows 系统，并使用 Puppet、Chef、Ansible、Salt 或 CF-Engine 作为总体管理工具
我想知道我对每种工具的理解是否正确，如果不正确，为什么？
答案1
我将仅对我有经验的进行评论，即 Puppet 和 Ansible。我省略了一些细节。
如果需要，两者都可以设置为无代理运行或仅在本地运行。要仅在本地使用它们，您显然需要某种方式将所需的清单/剧本传输到目标机器并在那里运行它们。
谈到 Puppet 与主机的使用，您可以使用负载均衡器与后面的实际主机实现冗余。
相反，在 Ansible 中没有主概念，只要您有办法访问剧本，每台可以使用 ssh/powershell 连接到受管理机器的机器都可以。也许您指的是 Ansible Tower，它使用数据库进行操作，如果需要，您可以对其进行集群化。
这给我们带来了两种情况下的真正冗余，即实际脚本。在几乎所有情况下，我都看到它们保留在 git 存储库中，因此它本质上是冗余的，只需克隆它，您就可以获得任意数量的“主”副本。
希望这可以帮助。
答案2
如果你看一下salt，那么构成master和minions之间工作连接的唯一信息是：
- Minion 可以以某种方式解析 Master 的 IP
- /etc/salt/pki/master 目录中的 minions 公钥
如果您的 salt master 死机，系统将继续运行而不会产生任何影响。但您说得对，在 master 死机时，您无法对配置进行任何更改。所以问题是您能多快恢复它？
您可以简单地重新安装主服务器并启动它 - 您可以再次接受您的 minions 密钥（或重新安装潜在的备份），并且您仍处于与旧主服务器相同的位置。如果您无法重复使用同一台机器，那么您需要以某种方式将 minions 指向新的主服务器。
数据库中没有可能损坏或消失的状态数据。对我来说，这就是它的美妙之处。它是一个覆盖层，不会挤进去。而不是——换个方式举例——像 juju，当你的数据库消失时，你的系统就像被斩首了一样，你必须重新安装。
还有多主控和 Syndic在 Salt 中 - 高可用性是其开发中的一个长期主题。
答案3
为了完善上述内容，Chef（如果使用chef-client，chef-solo则为纯本地服务器，没有可能发生故障的服务器组件）每次运行时都需要服务器。有多种方法可以在发生中断时使用缓存数据，但这绝对不是默认行为，甚至不是容易的。我们建议您在冗余/集群系统中运行 Chef Server，每个故障区域一个集群。查看 chef-backend 产品以进行集群，查看 Facebook 的 Grocery Delivery 以进行多服务器同步。
答案4
因此首先，我要感谢 jscott、Fredi、user378016 和 coderanger 的所有回答。
回答我自己的问题
- 对于 CF-Engine 来说这不是问题，因为每个节点都可以配置为服务器运行，并且如果服务器不可用，运行将继续。
CF-Engine 网站上对这些内容都有详细记录，您可以在此处找到示例：https://cfengine.com/learn/how-cfengine-works/
- 对于 Puppet，您可以选择 Master/Masterless 模式以及它们的优点和缺点。
Puppet 有多种模式，正如 Fredi 所指出的那样，模式只有一种。然而，经过进一步挖掘，Puppet 非常灵活，并且具有可支持主模式和无主模式的良好功能。
- 对于 Chef 来说，初始运行需要主服务器来获取策略，但是此后，如果主服务器不可用，则任何运行都将继续使用当前策略。
所以这并不完全正确，当运行在服务器模式下（不使用 chef-solo）时，每次运行都需要连接到主服务器。正如所提到的，有一些方法可以进行后备缓存，这些方法具有一些有趣的潜力，也许值得进一步研究。
- 对于 Salt，如果主服务器发生故障，则不会强制执行配置，因为所有操作都在主服务器上完成
因此感谢用户 378016 的确认，我认为提供的答案确实很好地回答了这个问题（永久链接：https://serverfault.com/a/805791/225383）
- 对于 Ansible（如 salt），如果主服务器发生故障，则不再强制执行配置，因为所有操作都由主服务器完成
因此，Ansible 是一个棘手的问题（再次感谢 Fredi 的回答）。它的优点在于只需在一台服务器上安装 Ansible 软件。存储在此“主服务器”上的剧本不一定在主服务器上运行，但可以通过 SSH 应用于其他服务器。当然，这要求您希望配置的所有这些框都可以通过 SSH 访问，并满足某些先决条件（如剧本中所述）。在某些情况下，并不总是那么理想。
编辑：我应该补充一点，Ansible 可以以类似于 puppet-masterless、chef-solo 的方式运行，通过在要管理的节点上安装 Ansible 并让它从 git 之类的地方提取配置，然后在本地应用该配置。
对于那些对我所推荐的方向感兴趣的人，我推荐 CF-Engine、Chef 或 Puppet。虽然 Ansible 和 Salt 都很有趣，但对于我的用户案例来说，它并不是最佳解决方案，因为我需要能够确保无论如何都要执行策略，并且要有良好的报告指标，依赖 SSH 始终可用并不是一个真正的选择（是的，虽然我们可以在每个盒子上安装服务器组件或某种调度程序来强制配置，但这似乎与它们最初的架构背道而驰）。
全部这些产品都非常好，并且各有优缺点，在这种情况下，我觉得 Ansible 和 Salt 不仅因为上述原因而不合适，还有其他各种原因。