【SaltStack官方版】—— states教程, part 4

STATES TUTORIAL, PART 4

本教程建立在第1部分、第2部分、第3部分涵盖的主题上。建议您从此开始。这章教程我们将讨论更多 sls 文件的扩展模板和配置技巧。

This part of the tutorial will show how to use salt's file_roots to set up a workflow in which states can be "promoted" from dev, to QA, to production.

本教程的这一部分将展示如何使用salt的file_roots来设置一个工作流程，在这个工作流程中，状态可以从开发，QA到生产“推广”。

salt fileserver path inheritance

Salt's fileserver allows for more than one root directory per environment, like in the below example, which uses both a local directory and a secondary location shared to the salt master via NFS:

salt的文件服务器允许每个环境有多个根目录，就像下面的例子一样，它使用本地目录和通过nfs共享给salt master的辅助位置：

# In the master config file (/etc/salt/master)
file_roots:
  base:
    - /srv/salt
    - /mnt/salt-nfs/base

Salt's fileserver collapses the list of root directories into a single virtual environment containing all files from each root. If the same file exists at the same relative path in more than one root, then the top-most match "wins". For example, if /srv/salt/foo.txt and /mnt/salt-nfs/base/foo.txt both exist, then salt://foo.txt will point to /srv/salt/foo.txt.

Salt的文件服务器将根目录列表压缩到包含每个根目录中的所有文件的单个虚拟环境中。如果同一文件存在于多个根中的相同路径中，则最顶部的匹配项为“wins”。例如，如果/srv/salt/foo.txt和/mnt/salt-nfs/base/foo.txt都存在，则salt：//foo.txt将指向/srv/salt/foo.txt。

注意
When using multiple fileserver backends, the order in which they are listed in the fileserver_backend parameter also matters. If both roots and git backends contain a file with the same relative path, and roots appears before git in the fileserver_backend list, then the file in roots will "win", and the file in gitfs will be ignored.
当使用多个文件服务器后端时，它们在fileserver_backend参数中列出的顺序也很重要。 如果根目录和git后端都包含具有相同相对路径的文件，并且根目录位于fileserver_backend列表中的git之前，则根目录中的文件将“win”，并且gitfs中的文件将被忽略。
A more thorough explanation of how Salt's modular fileserver works can be found here. We recommend reading this.
关于Salt的模块化文件服务器如何工作的更全面的解释可以在这里(File Server Backends)找到。 我们推荐阅读。

environment configuration

Configure a multiple-environment setup like so:

像这样配置一个多环境设置：

file_roots:
  base:
    - /srv/salt/prod
  qa:
    - /srv/salt/qa
    - /srv/salt/prod
  dev:
    - /srv/salt/dev
    - /srv/salt/qa
    - /srv/salt/prod

Given the path inheritance described above, files within /srv/salt/prod would be available in all environments. Files within /srv/salt/qa would be available in both qa, and dev. Finally, the files within /srv/salt/dev would only be available within the dev environment.

给定上面描述的路径继承，/srv/salt/prod中的文件将在所有环境中可用。 /srv/salt/qa中的文件在qa和dev中均可用。最后，/srv/salt/dev中的文件只能在dev环境中使用。

Based on the order in which the roots are defined, new files/states can be placed within /srv/salt/dev, and pushed out to the dev hosts for testing.

根据定义根的顺序，可以将新文件/状态放置在/ srv / salt / dev中，并推送到开发主机进行测试。

Those files/states can then be moved to the same relative path within /srv/salt/qa, and they are now available only in the dev and qa environments, allowing them to be pushed to QA hosts and tested.

那些文件/状态可以被移动到/ srv / salt / qa中相同的相对路径，现在它们只能在dev和qa环境中使用，从而可以将它们推送到qa主机并进行测试。

Finally, if moved to the same relative path within /srv/salt/prod, the files are now available in all three environments.

最后，如果移动/srv/salt/prod中相同的相对路径，则这三个文件现在都可用于所有三种环境。

requesting files from specific fileserver environments

(从特定文件服务器环境请求文件)

See here for documentation on how to request files from specific environments.

有关如何从特定环境请求文件的文档，请参阅此处。

PRACTICAL EXAMPLE

As an example, consider a simple website, installed to /var/www/foobarcom. Below is a top.sls that can be used to deploy the website:

作为一个例子，考虑一个简单的网站，安装到/var/www/foobarcom. 以下是可用于部署网站的top.sls：

/srv/salt/prod/top.sls:

[root@SaltMaster1(10.182.88.136)]$~:>more /srv/salt/prod/top.sls 
base:
  'web*prod*':
    - webserver.foobarcom
qa:
  'web*qa*':
    - webserver.foobarcom
dev:
  'web*dev*':
    - webserver.foobarcom

Using pillar, roles can be assigned to the hosts:

使用pillar，可以将角色分配给主机：

/srv/pillar/top.sls:

1 [root@SaltMaster1(10.182.88.136)]$~:>mkdir -pv /srv/pillar
2 [root@SaltMaster1(10.182.88.136)]$~:>more /srv/pillar/top.sls 
3 se:
4   'web*prod*':
5     - webserver.prod
6   'web*qa*':
7     - webserver.qa
8   'web*dev*':
9     - webserver.dev

/srv/pillar/webserver/prod.sls:

1 [root@SaltMaster1(10.182.88.136)]$~:>mkdir -pv /srv/pillar/webserver
2 [root@SaltMaster1(10.182.88.136)]$~:>more  /srv/pillar/webserver/prod.sls 
3 erver_role: prod

/srv/pillar/webserver/qa.sls:

[root@SaltMaster1(10.182.88.136)]$~:>more  /srv/pillar/webserver/qa.sls 
webserver_role: qa

/srv/pillar/webserver/dev.sls:

[root@SaltMaster1(10.182.88.136)]$~:>more /srv/pillar/webserver/dev.sls
erver_role: dev

And finally, the SLS to deploy the website:

最后，通过SLS文件来部署网站：

/srv/salt/prod/webserver/foobarcom.sls:

{% if pillar.get('webserver_role', '') %}
/var/www/foobarcom:
  file.recurse:
    - source: salt://webserver/src/foobarcom
    - env: {{ pillar['webserver_role'] }}
    - user: www
    - group: www
    - dir_mode: 755
    - file_mode: 644
{% endif %}

Given the above SLS, the source for the website should initially be placed in /srv/salt/dev/webserver/src/foobarcom.

鉴于上述SLS，网站的源码应放置在/srv/salt/dev/webserver/src/foobarcom中。

First, let's deploy to dev. Given the configuration in the top file, this can be done using state.apply:

首先，让我们部署到dev环境。鉴于top文件中的配置，这可以使用state.apply完成：

salt --pillar 'webserver_role:dev' state.apply

However, in the event that it is not desirable to apply all states configured in the top file (which could be likely in more complex setups), it is possible to apply just the states for the foobarcom website, by invoking state.apply with the desired SLS target as an argument:

但是，如果不希望应用top文件中配置的所有状态（这可能在更复杂的设置中可能），则可以仅通过调用state.apply来应用foobarcom网站的状态希望的SLS目标作为参数：

salt --pillar 'webserver_role:dev' state.apply webserver.foobarcom

Finally, once the site has been tested in qa, then the files can be moved from /srv/salt/qa/webserver/src/foobarcom to /srv/salt/prod/webserver/src/foobarcom, and deployed using the following:

最后，一旦该网站已经在qa中进行了测试，则可以将文件从/srv/salt/qa/webserver/src/foobarcom移动到/srv/salt/prod/webserver/src/foobarcom, 并使用以下方法进行部署：

salt --pillar 'webserver_role:prod' state.apply webserver.foobarcom

Thanks to Salt's fileserver inheritance, even though the files have been moved to within /srv/salt/prod, they are still available from the same salt:// URI in both the qa and dev environments.

感谢Salt的fileserver继承性，即使文件已经移动到/srv/salt/prod中，它们仍然可以从qa和dev环境中的相同salt：// URI获得。

继续学习途径：

The best way to continue learning about Salt States is to read through the reference documentation and to look through examples of existing state trees. Many pre-configured state trees can be found on GitHub in the saltstack-formulas collection of repositories.

继续学习有关Salt Staes的最好方法是阅读参考文献并查看现有状态树的例子。许多预先配置的状态树可以在GitHub的saltstack-formula集合中找到。

If you have any questions, suggestions, or just want to chat with other people who are using Salt, we have a very active community and we'd love to hear from you.

如果您有任何问题，建议，或者只是想与其他使用Salt的人聊天，我们有一个非常活跃的社区，我们很乐意听取您的意见。

In addition, by continuing to the Orchestrate Runner docs, you can learn about the powerful orchestration of which Salt is capable.