Skip to content

Latest commit

 

History

History
248 lines (204 loc) · 8.84 KB

14.Thorium-Complex-Reactor.md

File metadata and controls

248 lines (204 loc) · 8.84 KB
Raw

Thorium Complex Reactor

注意

Thorium是Salt的一项临时功能，如果事实证明该功能不可行，则可能会更改和除去。

注意

Thorium在2016.3.0版本中作为实验性功能添加到Salt中，从2016.3.0版开始，该功能被视为实验性功能，尚不能任何形式的功能支持做出保证。

Salt Reactor反应器的设计初衷是基于侦听特定事件然后对其做出反应的想法。 该模型具有许多逻辑上的限制，例如，基于聚合数据或基于多个事件触发响应会非常困难（而且很容易破解）。

Thorium Reactor旨在以一种非常优雅的方式缓解这一问题。 与其使用大量的Jinja例程或复杂的python sls文件，不如将数据聚合在一起，并且确定应该运行的内容与sls数据逻辑隔离，这使定义变得更加简洁。

Starting the Thorium Engine

要启用Thorium引擎，请将以下配置添加到Salt Master或Minion配置文件的engine部分，然后重新启动守护程序：

engines:
  - thorium: {}

Thorium Modules

由于其专业性，Thorium使用了自己的模块集。 但是，这些模块中的许多模块都是为包装更常用的Salt子系统而设计的。 这些模块是：

  • local: Execution modules
  • runner: Runner modules
  • wheel: Wheel modules

Thorium还附带了其他模块。 其中一些将在本文档的后面部分突出显示。

Writing Thorium Formulas

像其他一些Salt子系统一样，Thorium也使用自己的目录结构。 该结构的默认位置是/srv/thorium/，但是可以使用master配置文件中的thorium_roots配置项来更改它。

下面是显式地将根设置为默认值：

thorium_roots:
  base:
    - /srv/thorium

thorium_roots 配置示例:

thorium_roots:
  base:
    - /etc/salt/thorium

还可以通过thoriumenv或thorium_top设置将gitfs与Thorium一起使用。

使用thorium_top的示例：

thorium_top: salt://thorium/top.sls
gitfs_provider: pygit2

gitfs_remotes:
  - [email protected]:user/repo.git:
    - name: salt-backend
    - root: salt
    - base: master
  - [email protected]:user/repo.git:
    - name: thorium-backend
    - root: thorium
    - base: master
    - mountpoint: salt://thorium

注意

使用此方法时，请不要忘记将挂载点放在此仓库提供的文件之前，例如top.sls：

base:

'*': - thorium.key_clean

使用thoriumenv的示例:

thoriumenv: thorium
gitfs_provider: pygit2

gitfs_remotes:
  - [email protected]:user/repo.git:
    - name: salt-backend
    - root: salt
    - base: master
  - [email protected]:user/repo.git:
    - name: thorium-backend
    - root: thorium
    - saltenv:
      - thorium:
        - ref: master

注意

使用此方法时，所有状态都将在定义的环境下运行，例如top.sls：

thorium: '*': - key_clean

The Thorium top.sls File

Thorium使用其自己的top.sls文件，该文件遵循与/srv/salt/中相同的约定：

<srv>:
  <target>:
    - <formula 1>
    - <formula 2>
    - <etc...>

例如， 一个 top.sls 使用一个标准的 base 环境和一个名为key_clean的 Thorium formula , 那么看上去将是下面这样:

base:
  '*':
    - key_clean

请注意，未使用Thorium top.sls中的目标。 它仅用来与其他top.sls文件遵守相同的约定。 请在您自己的Thorium top.sls中将此设置保留为“*”。

Thorium Formula Files

Thorium SLS文件由处理Salt状态文件的同一状态编译器处理。 这意味着可以使用诸如必备项、模板之类的功能。

让我们看一个例子，然后讨论它的每个组成部分。 该公式使用Thorium来检测一个minion何时消失，然后在minion消失60秒后从主机中删除其密钥：

statreg:
  status.reg

keydel:
  key.timeout:
    - delete: 60
    - require:
      - status: statreg

此公式中有两个节，其ID为statreg和keydel。 第一个节statreg告诉Thorium在其register中跟踪minion状态信标。 稍后我们将详细讨论register。

第二个节，keydel，是执行实际工作的节。 它使用密钥模块将到期时间（使用超时功能）应用于minion。 因为delete设置为60，所以这是60秒的到期时间。 如果一个minion至少每60秒没有签到一次，它将从master中删除其密钥。 此特定功能还允许您使用拒绝而不是删除，如果未在指定的时间段内签入，则允许拒绝一个minion而不是将其删除。

此节中还有一个必需性的要求。 它指出除非成功调用statreg代码块中的status.reg函数，否则不会调用key.timeout函数。

Thorium Links to Beacons

上述示例是在2016.11.0版本的Salt中添加的，并利用了同样在2016.11.0版本中添加的状态信标。 为了使上述Thorium状态正常运行，您还需要在minion配置文件中启用状态信标：

beacons:
  status:
    - interval: 10

这将导致minion每隔10秒使用状态信标向master节点检入一次。

The Thorium Register

为了跟踪信息，Thorium在master主机上使用了一个内存中的寄存器（或更确切地说，是寄存器的集合）。 仅在通过公式通知时填充这些寄存器，并且通常在重新启动master时将其擦除。 可以将寄存器持久化到磁盘上，这个稍后我们将进行介绍。

上面的示例使用status.reg为您填充一个寄存器，该寄存器由key.timeout函数自动使用。 但是，您也可以使用reg模块设置自己的寄存器值。

由于Thorium监视事件总线，因此reg模块旨在查找用户指定的标签，然后从与这些标签匹配的事件的有效负载中提取数据。 例如，以下节将查找带有my/custom/event标签的事件：

foo:
  reg.list:
    - add: bar
    - match: my/custom/event

当发现此类事件时，在bar的有效负载字典键中找到的数据将存储在名为foo的寄存器中。 该寄存器会将数据存储在列表中。 您也可以使用reg.set将数据添加到set()中。

如果您想查看寄存器存储在内存中的副本，可以使用file.save函数：

myreg:
  file.save

在这种情况下，每次更新寄存器时，副本将以JSON格式保存在/var/cache/salt/master/thorium/saves/myreg。 如果您想查看何时将特定事件添加到列表类型寄存器中，可以将标记选项添加到reg.list中（而不是reg.set中）。 将以上两个节放在一起，看起来就像：

foo:
  reg.list:
    - add: bar
    - match: my/custom/event
    - stamp: True

myreg:
  file.save

如果您只想保留一定数量的最新寄存器条目，则还可以在reg.list中添加一个prune选项（而不是reg.set）：

foo:
  reg.list:
    - add: bar
    - match: my/custom/event
    - stamp: True
    - prune: 50

此示例仅将50个最新条目保留在foo寄存器中。

Using Register Data

如果您不对其进行任何操作，则将数据放入寄存器是没有用的。 检查模块旨在检查寄存器数据并确定其是否与给定参数匹配。 例如，如果给定值包含在指定的寄存器中，则check.contains函数将返回True：

foo:
  reg.list:
    - add: bar
    - match: my/custom/event
    - stamp: True
    - prune: 50
  check.contains:
    - value: somedata

通过使用require必要性条件，我们可以调用包装器模块之一并执行操作。 例如：

shell_test:
  local.cmd:
    - tgt: dufresne
    - func: cmd.run
    - arg:
      - echo 'thorium success' > /tmp/thorium.txt
    - require:
      - check: foo

仅当foo ID下的check.contains函数返回true（表示找到匹配项）时，此节才会运行。

检查模块中还有许多其他功能，它们使用不同的比较值方法：

  • gt：检查寄存器条目是否大于给定值
  • gte：检查寄存器项是否大于或等于给定值
  • lt：检查寄存器项是否小于给定值
  • lte：检查寄存器项是否小于或等于给定值
  • eq：检查寄存器条目是否等于给定值
  • ne：检查寄存器项是否不等于给定值

还有一个名为check.event的函数，它不检查寄存器。 而是直接查看事件总线上即将出现的事件，如果该事件的标记匹配，则返回True。 例如：

salt/foo/*/bar:
  check.event

run_remote_ex:
  local.cmd:
    - tgt: '*'
    - func: test.version
    - require:
      - check: salt/foo/*/bar

此公式将查找标签为salt/foo/<anything>/bar的事件，如果该事件出现，则向所有minions发出test.version。

Register Persistence

当master正常停止时，可以将寄存器数据持久保存到磁盘，而当master再次启动时，可以将其从磁盘重新加载。 此功能由returner子系统提供，每当使用任何包含load_reg和save_reg函数的返回器时，便会启用此功能。