SaltStack在使用中经常被问到的一些问题

FREQUENTLY ASKED QUESTIONS - Salt在使用中经常被问到的一些问题

注：您也可以参考在Github上维护的一份相同资料 SaltStack faq

IS SALT OPEN-CORE? - Salt是完全开源的吗？

不，但Salt 100％致力于开源，包括我们所有的API。它是在Apache 2.0许可下开发的，允许在开源和私有项目中使用。

稍微扩展一下：

关于“开放核心”的实际定义存在很多争论。从我们的角度来看，Salt是开源的，因为

1. 它是一个独立的产品，任何人都可以免费使用。
2. 它是公开开发的，不断地从社区接受了很多人为项目做出的贡献。
3. Salt本身没有任何仅限于SaltStack公司才能分发的独立专有产品功能。
4. 由于我们的Apache 2.0许可证，Salt可以用作项目甚至专有管理工具的基础设施。
5. 我们的API是开放的并且有文档记录（任何缺乏的文档都是疏忽造成的，而不是SaltStack公司的故意决定）并且可供任何人使用。

SaltStack公司确实生产及使用Salt及其库的专有产品，如公司可以免费使用，但我们是通过APIs来实现的，而不是通过创建Salt分支并为付费客户创建不同的闭源版本。

I THINK I FOUND A BUG! WHAT SHOULD I DO? - 我找到了一个bug!我该怎么办?

salt-users邮件列表以及salt IRC频道都可以成为有用的资源，以确认其他人是否正在查看问题并协助立即调试。

要向Salt项目报告错误，请按照 报告错误的说明 进行操作。

WHAT PORTS SHOULD I OPEN ON MY FIREWALL? - 我应该在防火墙上打开哪些端口？

Minions需要能够连接到Master服务的TCP端口4505和4506，Minions不需要打开任何入站端口。有关防火墙设置的更多详细信息，请访问此处。

I’M SEEING WEIRD BEHAVIOR (INCLUDING BUT NOT LIMITED TO PACKAGES NOT INSTALLING THEIR USERS PROPERLY)

我在使用中看到了一些奇怪的行为（包括但不限于没有正确安装他们的用户属性）。

这通常是由SELinux引起的。尝试禁用SELinux或将其置于许可模式，看看奇怪的行为是否消失。

MY SCRIPT RUNS EVERY TIME I RUN A STATE.APPLY. WHY? - 我的脚本在每次执行state.apply时都会运行，为什么？

您可能正在使用cmd.run而不是cmd.wait。 cmd.wait状态仅在其正在观察的状态发生更改时才会运行。

cmd.run状态每次都会运行相应的命令（除非它被except或onlyif参数阻止运行）。

更多详细信息可以在cmd状态的文档中找到。

WHEN I RUN TEST.PING, WHY DON’T THE MINIONS THAT AREN’T RESPONDING RETURN ANYTHING? RETURNING FALSE WOULD BE HELPFUL.

当我执行test.ping测试时，为什么那些没有响应的目标节点不能立即返回一点什么？ 返回错误会有所帮助。

当你运行test.ping时，Master会告诉Minions运行命令/函数，并监听返回数据，并在收到数据时将其打印到屏幕上。 如果它没有收到任何回复，它没有任何东西可以显示该Minion。

有几种方法可以获取没有响应的Minions的信息。 一种是在运行salt命令时使用verbose（-v）选项，因为对于任何超时的Minions，它将显示“Minion did not return”。

salt -v '*' pkg.install zsh

另外一个选择是使用 manage.down 运行器:

salt-run manage.down

• 这个salt runner可谓是专职为发现和处理失联minons所设计的。

此外，如果Master处于高负载状态，CLI可能会选择退出而不显示所有目标Minions的返回数据。 但是，这并不意味着minions没有返回数据; 这只意味着Salt CLI等待响应超时。 一旦作业完成，Minions仍会将其返回数据发送回Master。 如果CLI输出中缺少任何预期的Minions，则jobs.list_jobs运行器可用于显示已运行的作业的作业ID，jobs.lookup_jid运行器可用于获取该作业的返回数据。

salt-run jobs.list_jobs
salt-run jobs.lookup_jid 20130916125524463507

如果您发现在CLI上经常缺少Minion返回数据，而只能通过作业运行器找到它，那么这可能表明可能需要在Master配置文件中增加worker_threads值。 此外，使用-t选项运行Salt CLI命令将使Salt在CLI命令退出之前等待更长时间以返回数据。 例如，以下命令将等待最多60秒以便Minions返回：

salt -t 60 '*' test.ping

HOW DOES SALT DETERMINE THE MINION’S ID? - Salt是怎样确定Minion的ID？

如果没有显式配置Minion id（使用id参数），Salt将根据主机名确定id。 具体如何确定这一点在操作系统之间略有不同，这里将详细介绍。

I’M TRYING TO MANAGE PACKAGES/SERVICES BUT I GET AN ERROR SAYING THAT THE STATE IS NOT AVAILABLE. WHY?

我正在尝试管理软件包/服务，但我得到一个错误，说这是不可用的状态。 为什么？

Salt检测Minion的操作系统，并根据检测到的内容分配正确的软件包或服务管理模块。 但是，对于某些自定义的实现和OS衍生产品，此检测会失败。 在这种情况下，应该在我们的tracker跟踪器上打开一个问题，其中包含以下信息：

1. 以下命令的输出：

salt <minion_id> grains.items | grep os

2. /etc/lsb-release 文件的内容，如果在Minion节点上有这个文件。

WHY AREN’T MY CUSTOM MODULES/STATES/ETC. AVAILABLE ON MY MINIONS? - 为什么我的定制模块/状态以及其它配置，在我管理的Minions上无效？

当运行saltutil.sync_modules或saltutil.sync_all时，自定义模块将被同步到Minions。

同样，当运行saltutil.sync_states或saltutil.sync_all时，自定义状态将同步到Minions。

当触发一个 highstate 时，它们也会被同步到Minions。

从2019.2.0版本开始，以及2017.7.7和2018.3.2各自的发布周期中，state.apply/state.sls的sync参数可用于在运行单个SLS文件时同步自定义类型。

其他自定义类型（渲染器、输出器等）也具有类似的行为，有关详细信息，请参阅saltutil模块的文档。

当minion连接到master时，这个reactor实例可用于自动同步自定义类型，以帮助解决这个鸡与蛋的问题。

MODULE x ISN’T AVAILABLE, EVEN THOUGH THE SHELL COMMAND IT USES IS INSTALLED. WHY?

模块x不可用，即使它使用的shell命令已安装，为什么？

这很可能是PATH路径定义问题。 您是否自定义编译了模块所需的软件？RHEL/CentOS等系统特别是会使用/etc/init.d/functions覆盖root用户的路径，并将其设置为/sbin:/usr/sbin:/bin:/usr/bin，使得安装到/usr/local/bin中的软件对Salt不可用 。 在版本2014.1.0中，Salt为这些与PATH相关的问题提供了更好的解决方案，但重新编译软件以将其安装到PATH中的某个位置应该在此期间解决问题。 或者，您可以使用file.symlink状态在可用的PATH路径中创建一个符号链接。

/usr/bin/foo:
  file.symlink:
    - target: /usr/local/bin/foo

CAN I RUN DIFFERENT VERSIONS OF SALT ON MY MASTER AND MINION? - 我可以在Master和Minion节点上运行不同版本的Salt吗？

这取决于版本。 通常，建议Master和Minion版本匹配。

升级Salt时，应始终首先升级Master服务器。 对于运行比他们的Master更新版本的Salt Minions的向后兼容性不能得到保证。

只要有可能，将保留新主人和旧奴才之间的向后兼容性。 通常，此策略的唯一例外是出现安全漏洞。

最近的向后兼容性被破坏的例子包括0.17.1版本（由于安全修复而导致所有向后兼容性被破坏）和2014.1.0版本（保留了2014.1.0版本masters和0.17版本minions之间的兼容性，但打破了2014.1版本的minions和更早版本masters之间的兼容性）。

DOES SALT SUPPORT BACKING UP MANAGED FILES? - Salt是否支持为被管理的文件做备份？

是的。 Salt提供了一个易于使用的file.managed状态的附加功能，允许您通过backup_mode备份文件，backup_mode可以基于每个状态配置，或者在minion配置文件中配置（请注意，如果在minion配置文件中设置，这将作为使用的默认方法，不过您仍然需要指定应该备份哪些文件！）。

IS IT POSSIBLE TO DEPLOY A FILE TO A SPECIFIC MINION, WITHOUT OTHER MINIONS HAVING ACCESS TO IT?

是否有可能将文件部署到特定的minion，而其他minions都不能访问它？

Salt文件服务器尚不支持访问控制，但仍可以执行此操作。从Salt 2015.5.0开始，file_tree external pillar可用，并允许将文件的内容作为Pillar数据加载。这个外部pillar能够将Pillar值分配给各个minions和节点分组。有关如何进行此设置的详细信息，请参阅说明文档。

一旦设置了external pillar，就可以使用contents_pillar参数通过file.managed状态将数据推送到minion：

/etc/my_super_secret_file:
  file.managed:
    - user: secret
    - group: secret
    - mode: 600
    - contents_pillar: secret_files:my_super_secret_file

在此示例中，源文件将位于minion的file_tree路径下面名为secret_files的目录中。 指定pillar变量的语法与用于pillar.get的语法相同，冒号表示嵌套字典。

警告

使用file.managed状态部署二进制内容仅在Salt 2015.8.4和更新版本中受支持。

WHAT IS THE BEST WAY TO RESTART A SALT MINION DAEMON USING SALT AFTER UPGRADE?

在升级后使用Salt来重新启动Salt Minion的服务进程的最佳方法是什么？

更新salt-minion软件包需要重新启动salt-minion服务。 但是在状态运行期间重新启动服务会中断Minion运行状态的进程并将结果发送回Master服务器。 一种常见的解决方法是通过发出调用service.restart函数的salt-call命令来安排在后台重新启动Minion服务。 这可以防止Minion立即与Master断开连接。 否则你会得到Minion did not return. [Not connected]的信息。

UPGRADE WITHOUT AUTOMATIC RESTART - 升级Minion版本的过程中阻止服务发生自动的重启

首先，在您的SLS文件中执行Minion升级似乎是很简单的state状态管理。 但在默认情况下，在安装软件包之后，Debian GNU/Linux，Ubuntu及其衍生产品等操作系统会重启服务。 为了防止这种情况，我们需要创建一个策略层，以防止Minion服务在升级后立即重启：

{%- if grains['os_family'] == 'Debian' %}

Disable starting services:
  file.managed:
    - name: /usr/sbin/policy-rc.d
    - user: root
    - group: root
    - mode: 0755
    - contents:
      - '#!/bin/sh'
      - exit 101
    # do not touch if already exists
    - replace: False
    - prereq:
      - pkg: Upgrade Salt Minion

{%- endif %}

Upgrade Salt Minion:
  pkg.installed:
    - name: salt-minion
    - version: 2016.11.3{% if grains['os_family'] == 'Debian' %}+ds-1{% endif %}
    - order: last

Enable Salt Minion:
  service.enabled:
    - name: salt-minion
    - require:
      - pkg: Upgrade Salt Minion

{%- if grains['os_family'] == 'Debian' %}

Enable starting services:
  file.absent:
    - name: /usr/sbin/policy-rc.d
    - onchanges:
      - pkg: Upgrade Salt Minion

{%- endif %}

RESTART USING STATES - 通过States重启Minions服务

现在我们可以应用下面的解决方法以可靠的方式重新启动Minion。 以下示例适用于类UNIX操作系统：

{%- if grains['os'] != 'Windows' %}
Restart Salt Minion:
  cmd.run:
    - name: 'salt-call service.restart salt-minion'
    - bg: True
    - onchanges:
      - pkg: Upgrade Salt Minion
{%- endif %}

请注意，执行升级时，并不总是需要在Windows操作系统上重新启动salt-minion服务。 安装程序会停止salt-minion服务、删除它、删除\ salt\bin目录的内容、安装新代码、重新创建salt-minion服务，并启动它（默认情况下）。 但是，如果在升级或安装后变更了minion配置，则在升级过程中需要重新启动服务的步骤。 如果需要重启minions，可以按如下方式编辑上述状态：

Restart Salt Minion:
  cmd.run:
{%- if grains['kernel'] == 'Windows' %}
    - name: 'C:\salt\salt-call.bat service.restart salt-minion'
{%- else %}
    - name: 'salt-call service.restart salt-minion'
{%- endif %}
    - bg: True
    - onchanges:
      - pkg: Upgrade Salt Minion

但是，在类UNIX操作系统上需要更高级的技巧来从旧版本的Salt（2016.3.0之前）升级，后者不支持在后台执行命令。 在将所有其他状态应用于早于2016.11.0的Salt版本之后，您还可能需要使用无主模式安排重新启动Minion服务。 这允许Minion保持与Master的连接，以便能够将最终结果报告给Master，同时服务在后台重新启动。 此状态应该最后运行或监视pkg状态更改来被触发：

Restart Salt Minion:
  cmd.run:
{%- if grains['kernel'] == 'Windows' %}
    - name: 'start powershell "Restart-Service -Name salt-minion"'
{%- else %}
    # fork and disown the process
    - name: |-
        exec 0>&- # close stdin
        exec 1>&- # close stdout
        exec 2>&- # close stderr
        nohup salt-call --local service.restart salt-minion &
{%- endif %}

RESTART USING REMOTE EXECUTIONS - 通过远程执行模块重启Minions服务

通过命令行重启Minion服务:

salt -G kernel:Windows cmd.run_bg 'C:\salt\salt-call.bat service.restart salt-minion'
salt -C 'not G@kernel:Windows' cmd.run_bg 'salt-call service.restart salt-minion'

SALTING THE SALT MASTER - 使用Salt来配置Salt Master

为了通过state状态管理Master服务器的配置，Salt master也可以设置“salted”配置，以便在Salt master和Salt minions上都强制执行状态控制。 Salting Salt master要求在与Salt master主机上也安装一个Salt minion服务。 安装Salt minion后，必须将minion配置文件指向本地Salt master：

master: 127.0.0.1

一旦盐主人用盐奴隶“腌制”，它就像任何其他奴才一样被瞄准。 如果盐渍主人的仆从正在奔跑，那么仆从可以通过任何通常的盐命令进行瞄准。 此外，salt-call命令可以执行操作以在salted master上强制执行状态，而不需要minion运行。

有关salting the Salt master的更多信息可以在salt本身的salt-formula中找到：

https://github.com/saltstack-formulas/salt-formula

使用执行模块或状态应用重新启动salt-master服务可以使用与上述Salt minion相同的方式完成。

IS TARGETING USING GRAIN DATA SECURE? - 使用Grain数据定位目标Minions安全吗

由于可以由有权访问本地系统上的minion配置文件的用户设置grain，因此可以认为grain不如Salt中的其他标识符安全。 在针对敏感操作或根据grains数据设置pillar值时要小心。

唯一可以安全使用的grains是grain['id']，其中包含的是Minion ID。

如果可能，您应直接使用Minion ID定位敏感操作和数据。 如果系统的Minion ID发生变化，Salt Master的公钥必须由Salt Master的管理员重新接受，这样就不会受到冒充攻击。

WHY DID THE VALUE FOR A GRAIN CHANGE ON ITS OWN? - 为什么一个Grain的值改变了？

这通常是操作系统发行版本中更改的结果，该更改取代或删除Salt用于检测grain的内容。 幸运的是，当发生这种情况时，您可以使用Salt来使用类似于以下的命令来修复它：

salt -G 'grain:ChangedValue' grains.setvals "{'grain': 'OldValue'}"

• 把指定grain的值更改为和原有一致的值

建议您提交一个描述该更改的issue问题，以便可以在Salt中修复它。