thorium complex reactor update1.

14.Thorium-Complex-Reactor.md

@@ -0,0 +1,253 @@
+# Thorium Complex Reactor
+
+> 注意
+>
+> Thorium是Salt的一项临时功能，如果事实证明该功能不可行，则可能会更改和除去。
+
+> 注意
+>
+> Thorium在2016.3.0版本中作为实验性功能添加到Salt中，从2016.3.0版开始，该功能被视为实验性功能，尚不能任何形式的功能支持做出保证。
+
+Salt Reactor反应器的设计初衷是基于侦听特定事件然后对其做出反应的想法。 该模型具有许多逻辑上的限制，例如，基于聚合数据或基于多个事件触发响应会非常困难（而且很容易破解）。
+
+Thorium反应堆旨在以一种非常优雅的方式缓解这一问题。 与其使用大量的Jinja例程或复杂的python sls文件，不如将数据聚合在一起，并且确定应该运行的内容与sls数据逻辑隔离，这使定义变得更加简洁。
+
+## Starting the Thorium Engine
+
+要启用Thorium引擎，请将以下配置添加到Salt Master或Minion配置文件的engine部分，然后重新启动守护程序：
+```yaml
+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`配置项来更改它。
+
+下面是显式地将根设置为默认值：
+```yaml
+thorium_roots:
+  base:
+    - /srv/thorium
+```
+`thorium_roots` 配置示例:
+```yaml
+thorium_roots:
+  base:
+    - /etc/salt/thorium
+```
+还可以通过`thoriumenv`或`thorium_top`设置将gitfs与Thorium一起使用。
+
+使用`thorium_top`的示例：
+```yaml
+thorium_top: salt://thorium/top.sls
+gitfs_provider: pygit2
+
+gitfs_remotes:
+  - git@github.com:user/repo.git:
+    - name: salt-backend
+    - root: salt
+    - base: master
+  - git@github.com:user/repo.git:
+    - name: thorium-backend
+    - root: thorium
+    - base: master
+    - mountpoint: salt://thorium
+```
+
+> 注意
+>
+> 使用此方法时，请不要忘记将挂载点放在此仓库提供的文件之前，例如top.sls：
+>
+> ```yaml
+> base:
+  '*':
+    - thorium.key_clean
+> ```
+
+使用thoriumenv的示例:
+```yaml
+thoriumenv: thorium
+gitfs_provider: pygit2
+
+gitfs_remotes:
+  - git@github.com:user/repo.git:
+    - name: salt-backend
+    - root: salt
+    - base: master
+  - git@github.com: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/`中相同的约定：
+```yaml
+<srv>:
+  <target>:
+    - <formula 1>
+    - <formula 2>
+    - <etc...>
+```
+例如， 一个 top.sls 使用一个标准的 base 环境和一个名为key_clean的 Thorium formula  , 那么看上去将是下面这样:
+```yaml
+base:
+  '*':
+    - key_clean
+```
+
+请注意，未使用Thorium top.sls中的目标。 它仅用来与其他top.sls文件遵守相同的约定。 请在您自己的Thorium top.sls中将此设置保留为“\*”。
+
+### Thorium Formula Files
+
+Thorium SLS文件由处理Salt状态文件的同一状态编译器处理。 这意味着可以使用诸如必备项、模板之类的功能。
+
+让我们看一个例子，然后讨论它的每个组成部分。 该公式使用Thorium来检测一个minion何时消失，然后在minion消失60秒后从主机中删除其密钥：
+
+```yaml
+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
+
+The above example was added in the 2016.11.0 release of Salt and makes use of the status beacon also added in the 2016.11.0 release. For the above Thorium state to function properly you will also need to enable the status beacon in the minion configuration file:
+
+beacons:
+  status:
+    - interval: 10
+
+This will cause the minion to use the status beacon to check in with the master every 10 seconds.
+The Thorium Register
+
+In order to keep track of information, Thorium uses an in-memory register (or rather, collection of registers) on the master. These registers are only populated when told to by a formula, and they normally will be erased when the master is restarted. It is possible to persist the registers to disk, but we'll get to that in a moment.
+
+The example above uses status.reg to populate a register for you, which is automatically used by the key.timeout function. However, you can set your own register values as well, using the reg module.
+
+Because Thorium watches the event bus, the reg module is designed to look for user-specified tags, and then extract data from the payload of events that match those tags. For instance, the following stanza will look for an event with a tag of my/custom/event:
+
+foo:
+  reg.list:
+    - add: bar
+    - match: my/custom/event
+
+When such an event is found, the data found in the payload dictionary key of bar will be stored in a register called foo. This register will store that data in a list. You may also use reg.set to add data to a set() instead.
+
+If you would like to see a copy of the register as it is stored in memory, you can use the file.save function:
+
+myreg:
+  file.save
+
+In this case, each time the register is updated, a copy will be saved in JSON format at /var/cache/salt/master/thorium/saves/myreg. If you would like to see when particular events are added to a list-type register, you may add a stamp option to reg.list (but not reg.set). With the above two stanzas put together, this would look like:
+
+foo:
+  reg.list:
+    - add: bar
+    - match: my/custom/event
+    - stamp: True
+
+myreg:
+  file.save
+
+If you would like to only keep a certain number of the most recent register entries, you may also add a prune option to reg.list (but not reg.set):
+
+foo:
+  reg.list:
+    - add: bar
+    - match: my/custom/event
+    - stamp: True
+    - prune: 50
+
+This example will only keep the 50 most recent entries in the foo register.
+Using Register Data
+
+Putting data in a register is useless if you don't do anything with it. The check module is designed to examine register data and determine whether it matches the given parameters. For instance, the check.contains function will return True if the given value is contained in the specified register:
+
+foo:
+  reg.list:
+    - add: bar
+    - match: my/custom/event
+    - stamp: True
+    - prune: 50
+  check.contains:
+    - value: somedata
+
+Used with a require requisite, we can call one of the wrapper modules and perform an operation. For example:
+
+shell_test:
+  local.cmd:
+    - tgt: dufresne
+    - func: cmd.run
+    - arg:
+      - echo 'thorium success' > /tmp/thorium.txt
+    - require:
+      - check: foo
+
+This stanza will only run if the check.contains function under the foo ID returns true (meaning the match was found).
+
+There are a number of other functions in the check module which use different means of comparing values:
+
+    gt: Check whether the register entry is greater than the given value
+
+    gte: Check whether the register entry is greater than or equal to the given value
+
+    lt: Check whether the register entry is less than the given value
+
+    lte: Check whether the register entry is less than or equal to the given value
+
+    eq: Check whether the register entry is equal to the given value
+
+    ne: Check whether the register entry is not equal to the given value
+
+There is also a function called check.event which does not examine the register. Instead, it looks directly at an event as it is coming in on the event bus, and returns True if that event's tag matches. For example:
+
+salt/foo/*/bar:
+  check.event
+
+run_remote_ex:
+  local.cmd:
+    - tgt: '*'
+    - func: test.version
+    - require:
+      - check: salt/foo/*/bar
+
+This formula will look for an event whose tag is salt/foo/<anything>/bar and if it comes in, issue a test.version to all minions.
+Register Persistence
+
+It is possible to persist the register data to disk when a master is stopped gracefully, and reload it from disk when the master starts up again. This functionality is provided by the returner subsystem, and is enabled whenever any returner containing a load_reg and a save_reg function is used.
+
+https://docs.saltstack.com/en/latest/topics/thorium/index.html#thorium-formula-files