Understanding SaltStack State Compiler Ordering - 理解State状态编译的顺序

原文链接: https://docs.saltstack.com/en/latest/ref/states/compiler_ordering.html

注意:本教程是中级教程。 假定你对状态系统和编写salt公式已经有一些基本的了解。

您也可以参考在Github上维护的这一份技术资料:Understanding State Compiler Ordering

Salt的状态系统旨在不牺牲简单性的前提下提供配置管理系统的所有功能。 本教程旨在帮助用户详细了解Salt如何定义状态执行的顺序。

编写本教程是为了说明自0.17.0版本起Salt的行为。

Compiler Basics - 编译器的基础知识

要深入了解状态编译的顺序,有关状态编译器的一些非常基础的知识非常有帮助。

High Data and Low Data - 高级数据与低级数据

在YAML中定义Salt公式时,编译器将要表示的数据称为“High Data - 高级数据”。 最初将数据加载到编译器时,它是一个大型python字典,可以通过运行以下命令查看该字典:

salt '*' state.show_highstate

然后,将这种“High Data - 高级数据”结构编译为“Low Data - 低级数据”。 低级数据相当于是在Salt的配置管理系统中创建单个执行动作,是要执行的单状态调用的有序列表。 一旦低级数据被编译,就可以看到评估顺序的结果了。

执行以下命令查看低级数据:

salt '*' state.show_lowstate

注意:状态执行模块包含许多用于评估状态系统的函数,非常值得一读! 这些例程在调试状态或帮助加深人们对Salt状态系统的理解时非常有用。

例如,一个这样写的状态:

apache:
  pkg.installed:
    - name: httpd
  service.running:
    - name: httpd
    - watch:
      - file: apache_conf
      - pkg: apache

apache_conf:
  file.managed:
    - name: /etc/httpd/conf.d/httpd.conf
    - source: salt://apache/httpd.conf

上面的状态配置将会产生像下面这样的 json 格式的High Data数据:

扫描二维码关注公众号,回复: 7627643 查看本文章
{
    "apache": {
        "pkg": [
            {
                "name": "httpd"
            },
            "installed",
            {
                "order": 10000
            }
        ],
        "service": [
            {
                "name": "httpd"
            },
            {
                "watch": [
                    {
                        "file": "apache_conf"
                    },
                    {
                        "pkg": "apache"
                    }
                ]
            },
            "running",
            {
                "order": 10001
            }
        ],
        "__sls__": "blah",
        "__env__": "base"
    },
    "apache_conf": {
        "file": [
            {
                "name": "/etc/httpd/conf.d/httpd.conf"
            },
            {
                "source": "salt://apache/httpd.conf"
            },
            "managed",
            {
                "order": 10002
            }
        ],
        "__sls__": "blah",
        "__env__": "base"
    }
}

随后的Low Data数据看起来像这样:

[
    {
        "name": "httpd",
        "state": "pkg",
        "__id__": "apache",
        "fun": "installed",
        "__env__": "base",
        "__sls__": "blah",
        "order": 10000
    },
    {
        "name": "httpd",
        "watch": [
            {
                "file": "apache_conf"
            },
            {
                "pkg": "apache"
            }
        ],
        "state": "service",
        "__id__": "apache",
        "fun": "running",
        "__env__": "base",
        "__sls__": "blah",
        "order": 10001
    },
    {
        "name": "/etc/httpd/conf.d/httpd.conf",
        "source": "salt://apache/httpd.conf",
        "state": "file",
        "__id__": "apache_conf",
        "fun": "managed",
        "__env__": "base",
        "__sls__": "blah",
        "order": 10002
    }
]

这个教程讨论了Low Data数据评估和state状态运行时。

Ordering Layers - 定义执行顺序的层次

Salt定义了2个在状态运行时中评估命令执行顺序的接口,并通过多次传递来最终定义这个执行顺序。

Definition Order - 定义顺序的功能系统

注意:通过将Master配置文件中的state_auto_order选项设置为False,可以禁用“定义顺序”的系统功能。

排序的最高层次是“定义顺序”系统。 定义顺序系统功能是在Salt公式中定义状态的执行顺序。 在不包含include语句或top文件的基本状态上,这非常简单明了,因为状态只是从文件的顶部开始排序的,但是include系统开始为定义顺序引入更多的一些规则。

回顾上面显示的"Low Data" 和 “High Data” ,"order"键已透明地添加到数据中以启用“定义顺序”的功能。

The Include Statement - Include语句

基本上,如果公式中包含一个include语句,则被包含的公式将在包含它们的公式的内容之前运行。 另外,include语句的值是一个列表,因此将按照包含它们的顺序依次加载它们。

在下面的例子中:

foo.sls

include:
  - bar
  - baz

bar.sls

include:
  - quo

baz.sls

include:
  - qux

在上述情况下,如果调用了state.apply foo,则将按以下顺序加载公式:

  1. quo
  2. bar
  3. qux
  4. baz
  5. foo

The order Flag - Order关键字标志

"定义顺序"的功能系统是在后台透明地执行,但是还可以使用状态中的order标志显式地覆盖该顺序:

apache:
  pkg.installed:
    - name: httpd
    - order: 1

该"order"标志将超越"definition order"系统,这使得创建总是首先得到执行。指定在最后执行或在特定阶段执行的状态变得非常简单,一个很好的例子是定义了许多必须在任何其他操作之前设置的软件包存储库, 或需要使用order:lastorder:-1在状态运行结束时运行的最终检查操作。

当显式设置了order标志时,"definition order"系统将省略为该状态设置执行顺序,而直接使用定义的order标志。

Lexicographical Fall-back - 回退至字典顺序

Salt状态将始终以相同顺序执行。 在版本0.17.0中引入“定义顺序”功能之前,是先根据状态名称按字典顺序对所有内容进行排序,然后对函数进行排序,然后按id排序。

这是Salt确保状态始终以相同顺序运行的方式,无论它们部署在何处,附加的定义顺序方法使这种顺序更易于遵循。

字典顺序仍然适用,但是仅在两个顺序语句发生冲突时才有效。 这意味着,如果为多个状态分配了相同的顺序号,它们将退回到字典顺序,以确保每次执行时仍按有限顺序进行。

注意:如果启用了state_auto_order:False,则order键不会自动设置,而字典顺序则可以从其他键派生。

Requisite Ordering - 依赖性顺序

Salt状态是完全声明性的,它们被编写来声明系统应处于的状态。 这意味着组件可能要求其他组件已成功设置。 与其他管理系统不同,Salt中的Requisite系统是在运行时进行评估。

还为此建立了一个requisite系统,以确保执行顺序不会改变,对于给定的状态集始终是相同的。 这是通过使用以完全可预测的顺序处理状态的运行时而不是像其他声明性配置管理系统那样使用基于事件循环的系统来完成的。

Runtime Requisite Evaluation - 运行时依赖性的评估

找到组件后,将评估Requisite系统,并且始终以相同顺序评估Requisite条件。 该解释之后将举一个示例,原始解释起初可能有点令人头晕,因为它创建了线性相关性评估序列。

“Low Data数据”是一个有序列表或字典,状态运行时会按照字典在列表中的排列顺序评估每个字典。 在评估单个字典时,将检查必备条件,并按顺序对必备条件进行评估,先进行require ,然后是 watch ,最后做 prereq检查。

注意:如果在require_in和watch_in之类的语句中使用Required,则将在运行时评估之前将其编译为require和watch语句。

每个条件都包含一个有序的条件列表,这些条件在字典列表中查找然后执行。 一旦评估并执行了所有需求,就可以安全地运行需求的状态(如果未满足需求,则不运行)。

这意味着必须始终以相同的顺序评估需求,这再次确保了Salt状态系统的核心设计原则之一,以确保执行结果始终是有限的。

Simple Runtime Evaluation Example - 简单的状态执行顺序评估分析示例

给定上述“低数据”后,将按以下顺序评估状态:

  1. 执行pkg.installed以确保已安装apache软件包,该软件包不包含任何必需项,因此是要执行的第一个定义状态。
  2. 评估service.running状态但未执行,发现了监视条件,因此按顺序读取它们,运行时首先检查文件,查看其尚未执行,然后调用要评估的文件状态。
  3. 文件状态是评估并执行了的,因为它像pkg状态一样不包含任何必要条件。
  4. 继续评估服务状态,然后检查pkg必要条件,并确定满足该条件,并且满足所有条件,现在执行服务状态。

Best Practice - 最佳实践

Salt的最佳实践是选择一种方法并坚持下去,因为所有条件都创建了清晰,可追溯的依赖关系并适用于大多数可移植的公式,所以使用所有关联的条件编写正式的states状态。 为了完成与经典命令式系统运行类似的操作,可以省略所有的必要性条件,然后在master配置中将failhard选项设置为True,这将在发生第一次故障时停止所有状态的运行。

最后,使用Requisite必要条件将创建非常紧密且细粒度的状态,不使用必要条件将使完整序列运行且编写起来稍微容易一些,并且对执行的控制要少得多。

猜你喜欢

转载自blog.csdn.net/watermelonbig/article/details/102492637