按特定顺序包含多个盐状态答案

【问题标题】：Include multiple salt states in specific order按特定顺序包含多个盐状态
【发布时间】：2022-08-03 18:19:15
【问题描述】：

我想将多个现有的盐状态组合成一个新的状态，它们需要以特定的顺序执行。

SaltStack documentation 解释说可以包含盐状态。据我了解，包含的状态将在 sls 文件的其余部分之前运行。例子：

include:
  - config-pulled
  - service-restarted

使用此示例，我希望 service-restarted 在 config-pulled 之后执行，并且仅在 config-pulled 成功时执行。

但不保证多个包含状态的执行顺序。文档说： ... If you need to guarantee order of execution, consider using requisites.

我可以想象直接在 include 上使用 requisities。例如：

include:
  - config-pulled
  - service-restarted:
      require:
        - config-pulled

但这不起作用。

问题

在包含状态时如何使用必需项？
我必须改用orchestrate script 吗？

这似乎相关，但我不明白解决方案是什么：github.com/saltstack/salt/issues/11893
有没有办法在不执行状态的情况下导入状态？然后可以使用require 使所有状态可用并定义它们的执行顺序
嗯，再想一想，我不想对 sls 文件中的状态名称做出假设。 sls 文件应被视为“黑匣子”。因此，使用 require 从 sls 文件中对导入的状态进行排序并不是最优的，因为必须对 sls 文件中使用的 id 做出假设。
我现在正在使用编排脚本。我没有找到解决此问题的其他方法。

标签： salt-stack

【解决方案1】：

包括不是状态。所以必需品不适用于他们。

至于你指向的票，它变成了https://docs.saltproject.io/en/latest/ref/states/all/salt.states.test.html#salt.states.test.noptest.nop，这只是一个不做任何事情的状态。

为了处理你所说的，你会做类似的事情

include:
  - http
  - libvirt

run_http:
  test.nop:
    - require:
      - sls: http

run_libvirt:
  test.nop:
    - require:
      - test: run_http
      - sls: libvirt

【讨论】：

includes are not states。从句法的角度来看，这可能是正确的。但从概念上讲，我认为执行多个状态会产生一个新状态，即它们的组合。因此，执行顺序可能是相关的。 SaltStack 缺乏创建这样的组合是 IMO 的严重缺乏。请注意，编排脚本（尽管可以解决我手头的问题）本身并不是盐状态，因此不会实现这种组合（因为不能以相同的方式包含/组合它）。
Thereby, the execution order may be relevant。示例：config-pulled.sls 从 git 存储库中提取。它是一个有效的盐状态（幂等等）。 service-restarted.sls 重新启动服务。同样，它是一个有效的盐状态。现在我想撰写config-pulled-then-service-restarted.sls。如果在拉取配置之前重新启动服务，则服务可能会错过更改的配置。因此，组合中的执行顺序是相关的。编辑：我改变了原来的问题和你的答案来使用这个真实的例子。
你的答案不起作用。在我的测试中， test.nop 部分按要求的顺序执行。但包含不是（至少在盐打印的输出中）。这确实是有效的，因为仍然没有声明必须在service-restarted 之前执行config-pulled。因此，以下顺序是可能的：(config-pulled, service-restarted, run_config_pulled, run_service_restarted), (service-restarted, config-pulled, run_config_pulled, run_service_restarted), (config-pulled, run_config_pulled, service-restarted, run_service_restarted)
@mihca Salt 并不缺少这样的组合。这正是sls 的含义。可以使用编排来显式地对这些组合进行排序，或者您可以像本示例中那样通过nop 状态的传递排序来执行此操作。
@whytewolf 您的示例似乎确实不正确，因为当一个状态具有多个先决条件时，除了“都在此之前”之外，没有定义它们必须运行的顺序。

【解决方案2】：

您不必使用 orch，您可以使用 onchanges 必备条件和 test.succeed_with_changes。

盐测试3004.2

总结一下这个演示，onchanges 默认禁止test.succeed_with_changes 的执行，除非给定状态（tests.config-pulled）发生变化。 onchanges_in 反过来做同样的事情并禁止服务器重新加载，除非 test.succeed_with_changes 被修改（在盐意义上）。

例子：

/srv/salt
├── tests
│   ├── config-pulled.sls
│   ├── init.sls
│   └── service-restarted.sls

config-pulled.sls

 config-pulled:
   file.managed:
     - name: /tmp/config
     - contents: 1000
 # uncomment random to simulate a change (or change 1000 just over)
 #    - contents: {{ range(1000, 9999) | random }}

service-restarted.sls

 service-restarted:
   cmd.run:
     - name: echo service-restarted

init.sls

 include:
   - tests.config-pulled
   - tests.service-restarted
 
 demo:
   test.succeed_with_changes:
     - onchanges:
       - sls: tests.config-pulled
     - onchanges_in:
       - sls: tests.service-restarted

这种方法可能会变得有点难以维护。

一种完全不同的方法是重组 sls。我通常将服务器安装和重新加载与自定义（两个单独的 sls）分开，因此当我必须处理配置时，我在任何/所有管理 conf 的 sls 之上包括“安装和重新加载”一个（通常为init.sls）导入状态并使用require_in 配置我的配置状态，例如：

myconf:
  file.managed:
    - [...]
    - require_in:
      - cmd: rndc-reload

或者

myconf:
  file.managed:
    - [...]
     - require_in:
      - service: haproxy

注意：这种方法可以很好地扩展到多个状态，甚至 sls 可以使用这种机制管理配置，并且在设置所有配置后，守护程序只会重新加载一次。

【讨论】：