有时我的盐师会在salt '*' test.ping等待倒下的仆从回复时挂起一段时间。有没有办法查看已连接的仆从列表，无论它们是否响应test.ping？

我正在考虑推出一种新的配置管理工具来取代我们自己开发的解决方案。事实上的标准是 Chef 和 Puppet，它们都是以 Ruby 为中心的（尽管显然可以用于部署非 Ruby 环境）。我们绝大多数的开发都是用 Python 完成的，我们的内部部署工具大量使用Fabric。因此，我正在学习Salt，因为它也是 Python，尽管它不如 Chef 或 Puppet 成熟。但由于我对这些选项不够熟悉，我发现很难进行比较。

除了较小的社区之外，我会通过使用 Salt 而不是 Puppet/Chef 来放弃任何重要的东西吗？

更新

我发布这个问题已经六个月了。尽管它已关闭，但它已被观看了 1,000 多次，所以我想我会评论我的经历。

我最终决定使用 Puppet，因为它有一个更大的社区。然而，这是一次非常令人沮丧的经历，主要是由于复杂的 Puppet 配置语法。因为我现在有了比较两者的参考框架，所以我最近又看了看 Salt——我不会回去了。非常非常酷。我最喜欢的东西：

• 推和拉配置模型的无缝集成。Puppet 使用拉模型（节点定期轮询服务器以获取更新）并有一个名为 Marionette 的姊妹组件用于推送更改。两者对我都很重要，我更喜欢 Salt 的工作原理。当你有很多节点时，Salt 的执行速度也会快得多。

• 配置语法使用 YAML，它只是一种使用缩进和项目符号的简单文本格式。您也可以通过模板选择使用其他配置格式。根据我的经验，这使 Salt 的学习和维护难度提高了大约 10 倍。

• 基于Python。这是我最初开始研究 Salt 的最大原因。这最终成为我留下来的次要原因之一。但是，如果您是像我们这样的 Python 商店，则可以更轻松地开发 Salt 插件。

更成熟的配置管理 (CM) 系统（如 Puppet 和 Chef）使用基于拉取的方法：客户端定期轮询集中主节点以获取更新。其中一些也提供了一种无主方法（因此，基于推送），但声明它“不适用于生产”（Saltstack）或“可扩展性较差”（Puppet）。我所知道的唯一一个从一开始就基于推送的系统是亚军 Ansible。

基于拉的系统的具体可扩展性优势是什么？为什么据说添加更多 pull-masters 比 push-agents 更容易？

例如，agiletesting.blogspot.nl写道：

在“拉”系统中，客户端相互独立地联系服务器，因此整个系统比“推”系统更具可扩展性

另一方面，Rackspace 证明他们可以使用基于推送的模型处理 15K 系统。

infastructures.org写道：

我们发誓使用拉式方法来维护基础架构，使用 SUP、CVSup、rsync 服务器或 cfengine 等工具。不是将更改推送给客户端，每个单独的客户端计算机都需要负责在启动时轮询黄金服务器，并在之后定期轮询，以保持自己的 rev 级别。在采用这个观点之前，我们开发了大量基于 ssh、rsh、rcp 和 rdist 的基于推送的脚本。我们在 r-commands（或 ssh）中发现的问题是：当您运行基于 r-command 的脚本将更改推送到您的目标机器时，很可能如果您有 30 多个目标主机，其中一个将在任何给定的时间下来。维护委托机器的列表变成了一场噩梦。在编写代码来纠正这个问题的过程中，你最终会得到精心设计的包装器代码来处理：死主机超时；记录和重试死主机；分叉并运行并行作业以尝试在合理的时间内访问许多主机；最后检测并防止在所有出站 rsh 会话中耗尽源计算机上所有可用 TCP 套接字的情况。然后，您仍然面临着将您刚才所做的所有内容放入安装映像中的问题，以便将来安装所有新主机，以及为任何已死且明天必须重建的主机重复此操作。在我们为实现基于 r-command 的复制而遇到的麻烦之后，我们发现它只是不值得。我们不打算再次使用 r-commands 或任何其他推送机制来管理基础设施。它们的扩展性不如基于拉动的方法。分叉并运行并行作业以尝试在合理的时间内访问许多主机；最后检测并防止在所有出站 rsh 会话中耗尽源计算机上所有可用 TCP 套接字的情况。然后，您仍然面临着将您刚才所做的所有内容放入安装映像中的问题，以便将来安装所有新主机，以及为任何已死且明天必须重建的主机重复此操作。在我们实现基于 r-command 的复制遇到麻烦之后，我们发现它不值得。我们不打算再次使用 r-commands 或任何其他推送机制来管理基础设施。它们的扩展性不如基于拉动的方法。分叉并运行并行作业以尝试在合理的时间内访问许多主机；最后检测并防止在所有出站 rsh 会话中耗尽源计算机上所有可用 TCP 套接字的情况。然后，您仍然面临着将您刚才所做的所有内容放入安装映像中的问题，以便将来安装所有新主机，以及为任何已死且明天必须重建的主机重复此操作。在我们为实现基于 r-command 的复制而遇到的麻烦之后，我们发现它只是不值得。我们不打算再次使用 r-commands 或任何其他推送机制来管理基础设施。它们的扩展性不如基于拉动的方法。最后检测并防止在所有出站 rsh 会话中耗尽源计算机上所有可用 TCP 套接字的情况。然后，您仍然面临着将您刚才所做的所有内容放入安装映像中的问题，以便将来安装所有新主机，以及为任何已死且明天必须重建的主机重复此操作。在我们实现基于 r-command 的复制遇到麻烦之后，我们发现它不值得。我们不打算再次使用 r-commands 或任何其他推送机制来管理基础设施。它们的扩展性不如基于拉动的方法。最后检测并防止在所有出站 rsh 会话中耗尽源计算机上所有可用 TCP 套接字的情况。然后，您仍然面临着将您刚才所做的所有内容放入安装映像中的问题，以便将来安装所有新主机，以及为任何已死且明天必须重建的主机重复此操作。在我们实现基于 r-command …

在我目前的工作场所，我负责管理两台 VMware 主机、一台 OpenBSD 物理机、三台 Debian 虚拟机和六台 Windows Server 虚拟机（2008/2012）。

我正在考虑实施配置管理工具，例如 Puppet 或 Chef。这是否合理，或者学习该工具的开销是否会超过收益？可管理性和实施成本之间的临界点在哪里？

我无法调用 sls 文件的单个状态。

整个 sls 文件有效

这有效：

salt-ssh w123 state.sls monitoring

这有效：

salt-ssh w123 state.show_sls monitoring

上述输出中的一项：

monitoring_packages:
    ----------
    __env__:
        base
    __sls__:
        monitoring.packages
    pkg:
        |_
          ----------
          pkgs:
              - python-psutil
        - installed
        |_
          ----------
          order:
              10000

我试过的

现在我只想调用monitoring_packages，而不是整个 sls 文件：

失败：

salt:/srv # salt-ssh w123 state.sls_id monitoring_packages  monitoring
w123:
    Data failed to compile:
----------
    No matching sls found for 'monitoring' in env 'base'

失败：

salt:/srv # salt-ssh w123 state.single monitoring.monitoring_packages
w123:
    TypeError encountered executing state.single: single() takes at least …

如何使用状态文件清除 salt-minion 上的目录？我想*.conf在/etc/supervisord/conf.d/设置其他主管服务之前删除所有文件。

以下top.sls配置无效：

/etc/supervisor/conf.d/*:
  file.absent

file.remove 因不可用而失败。

我正在开始一个新项目，并考虑使用Ansible或Salt进行部署自动化，也许还有更复杂的编排（服务器管理和联合）。

对于 Salt，我想知道它与Graphite、Zenoss或Ganglia之间是否存在任何集成……使用 Salt 0mq连接将数据从 Salt“ minions”中继到监控/图形数据库/收集器。

有没有其他人看过这个？

我有两个 ssh 密钥，我试图将它们部署到我的一个仆从。但我似乎无法部署它。它出错了。这是init.sls在支柱：

/xxx/yyy/zzz/id_rsa:
  file.managed:
    - source: salt://private/id_rsa

/xxx/yyy/zz/id_rsa.pub:
  file.managed:
    - source: salt://private/id_rsa.pub

这是我的init.sls状态：

ssh:
  file.managed:
    - name: {{ pillar['private'] }}

我一定是做错了什么（显然），但我不确定是什么。有什么建议？

在minion上运行state.apply或state.highstate可能会导致输出数百行。有时只有一个仆从就足够了。

...
Summary for my_minion
--------------
Succeeded: 112 (changed=78)
Failed:      6
Warnings:    1
--------------
Total states run:     118
Total run time:     4.958 s

有没有办法在输出中只显示失败和警告？

我想做的是为每个 openvpn 用户生成多个配置文件。我在支柱中有 IP 地址和其他配置。

例如：

openvpn:
  - user1:
    ip: 1.2.3.4
    config:
      - line1
      - line2

在 SLS 中，我想做一些类似的事情：

{% for vpnuser in salt['pillar.get']('openvpn') %}
/etc/openvpn/ccd/{{ vpnuser }}:
  file.managed:
    - template: jinja
    - source: salt://openvpn/ccdtemplate
{% endfor %}

在 ccdtemplate 中，我想根据用户和存储在柱子中的该用户的配置数据生成配置。

但是因此我需要从状态中知道变量“vpnuser”的内容。

是否可以将变量从状态传递到 jinja 模板？