大多数技术系统的基础架构是由计算机组成，该架构中的每台计算机都扮演着与其他计算机相似的角色。 这些机器相互协作以创建应用程序的技术栈。
为了有效地管理这些计算机设备，管理员需要能够为这些计算机或计算机分组创建角色。 例如，一组为前端Web流量提供服务的计算机可能具有某些角色，这些角色指示这些计算机都应都安装了Apache Web服务器软件包，并且Apache服务应始终处于运行状态。
在Salt中，包含网络上的计算机分组与应用于它们的配置角色之间的映射关系的文件称为top file文件。
默认情况下，顶级文件的名称为top.sls，之所以如此命名是因为它们始终存在于包含状态文件的目录层次结构的“顶部”中。 该目录层次结构称为state tree状态树。
Top file文件包含三个组成部分：
- 环境：状态树目录，其中包含一组用于配置系统的状态文件。
- 目标：一组机器，将对它们应用一组状态。
- 状态文件：应用于目标的状态文件列表。 每个状态文件都描述了要在目标计算机上配置和实施的一个或多个状态。
这三个组件之间的关系如下：
- 环境包含目标
- 目标包含状态
将这些概念放在一起，我们可以描述一个场景，在该场景中，所有以web开头的ID的minions都被应用了apache状态：
base: # Apply SLS files from the directory root for the 'base' environment
'web*': # All minions with a minion_id that begins with 'web'
- apache # Apply the state file named 'apache.sls'环境是目录层次结构，其中包含顶级文件和一组状态文件。
环境可以以多种方式使用，但是也可以根本不需要使用它们。 实际上，部署Salt的最常见方法是使用称为base的单一环境。 建议用户仅在有一个用例专门要求多个状态树版本的用例场景时才创建多个环境。
每个环境都是在Salt master配置文件变量file_roots中定义。
在最常见的单环境设置中，只有基本环境在file_roots中定义，并且状态树只有一个目录路径。
file_roots:
base:
- /srv/salt在上面的示例中，顶级文件将只有一个要提取的环境。
接下来是放在/srv/salt/top.sls中的一个简单的单环境顶层文件，说明了对于名为base的环境，所有minions都将应用名为core.sls和edit.sls的状态文件。
base:
'*':
- core
- edit假设像上面配置了file_roots，Salt将在/srv/salt目录中查找core.sls和edit.sls。
在某些情况下，团队可能希望创建版本化的状态树，这些状态树可用于在将状态部署到生产中之前在隔离的系统集（例如暂存环境）中测试Salt配置。
对于这种情况，可以使用多个环境来完成此任务。
要创建多个环境，可以扩展file_roots选项：
file_roots:
dev:
- /srv/salt/dev
qa:
- /srv/salt/qa
prod:
- /srv/salt/prod在上面，我们声明了三种环境：dev，qa和prod。 每个环境都有一个分配给它的目录。
我们的顶级文件引用了以下环境：
dev:
'webserver*':
- webserver
'db*':
- db
qa:
'webserver*':
- webserver
'db*':
- db
prod:
'webserver*':
- webserver
'db*':
- db如上所示，顶层文件现在声明了三个环境，并且为每个环境定义了目标表达式，以将minions映射到状态文件。 例如，所有具有以字符串webserver开头的ID的minions都将为其分配所请求环境中的webserver状态。
通过这种方式，可以先在/srv/salt/dev中的状态文件中对状态进行建议的更改，然后将其复制到/srv/salt/qa将该状态文件移至QA，然后将其应用于开发Web服务器 。
除非使用以下描述的方法覆盖，否则顶层文件默认会将minions分配到一个环境中。顶层文件中的环境必须匹配有效的文件服务器环境（也就是saltenv），以便将任何状态应用于该minion。使用默认的文件服务器后端时，环境是在file_roots中定义。
可以使用state.show_top函数查看将在给定环境中应用于minion的状态。
通过在minion配置文件中设置环境值，可以将minions固定到特定环境。这样，一个minion只会从其分配到的环境请求文件。
也可以在运行时通过将环境传递给salt，salt-call或salt-ssh命令来动态选择环境。最常见的做法是使用saltenv参数对状态模块中的函数进行处理。例如，要在prod环境中仅使用顶层文件和SLS文件对所有minions运行highstate状态，请运行：salt '*' state.highstate saltenv = prod。
注意：并非所有函数都支持将saltenv用作参数，请参见文档中的各个函数文档进行验证。
如果仅将一个SLS分配给系统，如本例所示，则可使用下面的简写方法：
base:
'*': global
dev:
'webserver*': webserver
'db*': db
qa:
'webserver*': webserver
'db*': db
prod:
'webserver*': webserver
'db*': db在上面的示例中，请注意所有目标表达式都使用了glob匹配。 Top file文件（自版本2014.7.0起）中的默认匹配类型实际上是 compound matcher（复合匹配器），而不是CLI中的全局匹配器。
单个glob通过复合匹配器时，其行为与glob匹配相同，因此在大多数情况下，两者是无法区分的。 但是，在某些情况下，一个minion ID中包含空格。 虽然不建议在minion ID中包含空格，但是Salt不会阻止您这样做。 但是，由于复合表达式是逐词进行解析的，因此，如果一个minion ID包含空格，它将无法匹配。 在这种情况下，有必要明确使用全局匹配器：
base:
'minion 1':
- match: glob
- foo可以在top file文件中为目标表达式设置的可用匹配类型如下表所示：
| Match Type | Description |
|---|---|
| glob | Full minion ID or glob expression to match multiple minions (e.g. minion123 or minion*) |
| pcre | Perl-compatible regular expression (PCRE) matching a minion ID (e.g. web[0-3].domain.com) |
| grain | Match a grain, optionally using globbing (e.g. kernel:Linux or kernel:*BSD) |
| grain_pcre | Match a grain using PCRE (e.g. kernel:(Free |
| list | Comma-separated list of minions (e.g. minion1,minion2,minion3) |
| pillar | Pillar match, optionally using globbing (e.g. role:webserver or role:web*) |
| pillar_pcre | Pillar match using PCRE (e.g. role:web(server |
| pillar_exact | Pillar match with no globbing or PCRE (e.g. role:webserver) |
| ipcidr | Subnet or IP address (e.g. 172.17.0.0/16 or 10.2.9.80) |
| data | Match values kept in the minion's datastore (created using the data execution module) |
| range | Range cluster |
| compound | Complex expression combining multiple match types (see here) |
| nodegroup | Pre-defined compound expressions in the master config file (see here) |
下面是一个稍微复杂一些的top file文件示例，其中应用了上述一些匹配类型：
# All files will be taken from the file path specified in the base
# environment in the ``file_roots`` configuration value.
base:
# All minions which begin with the strings 'nag1' or any minion with
# a grain set called 'role' with the value of 'monitoring' will have
# the 'server.sls' state file applied from the 'nagios/' directory.
'nag1* or G@role:monitoring':
- nagios.server
# All minions get the following three state files applied
'*':
- ldap-client
- networking
- salt.minion
# All minions which have an ID that begins with the phrase
# 'salt-master' will have an SLS file applied that is named
# 'master.sls' and is in the 'salt' directory, underneath
# the root specified in the ``base`` environment in the
# configuration value for ``file_roots``.
'salt-master*':
- salt.master
# Minions that have an ID matching the following regular
# expression will have the state file called 'web.sls' in the
# nagios/mon directory applied. Additionally, minions matching
# the regular expression will also have the 'server.sls' file
# in the apache/ directory applied.
# NOTE!
#
# Take note of the 'match' directive here, which tells Salt
# to treat the target string as a regex to be matched!
'^(memcache|web).(qa|prod).loc$':
- match: pcre
- nagios.mon.web
- apache.server
# Minions that have a grain set indicating that they are running
# the Ubuntu operating system will have the state file called
# 'ubuntu.sls' in the 'repos' directory applied.
#
# Again take note of the 'match' directive here which tells
# Salt to match against a grain instead of a minion ID.
'os:Ubuntu':
- match: grain
- repos.ubuntu
# Minions that are either RedHat or CentOS should have the 'epel.sls'
# state applied, from the 'repos/' directory.
'os:(RedHat|CentOS)':
- match: grain_pcre
- repos.epel
# The three minions with the IDs of 'foo', 'bar' and 'baz' should
# have 'database.sls' applied.
'foo,bar,baz':
- match: list
- database
# Any minion for which the pillar key 'somekey' is set and has a value
# of that key matching 'abc' will have the 'xyz.sls' state applied.
'somekey:abc':
- match: pillar
- xyz当执行highstate状态并指定环境时（使用环境配置选项或在执行highstate状态时通过传递saltenv），则该环境的顶层文件是唯一用于将状态分配给minions的顶层文件，并且仅有来自状态指定的环境将运行。
本节的其余部分适用于在未指定环境的情况下执行highstate状态的情况。
在未指定环境的情况下，minion将在每个环境中查找顶级文件，并且将处理每个顶级文件以确定在minions上运行哪些的SLS文件。默认情况下，来自每个环境的top file文件将合并在一起。在具有许多环境的配置中（例如，在GitFS中，每个分支和标签都被视为不同的环境），这可能会导致意外结果，因为来自旧标签的SLS文件会导致失效的SLS文件包含在highstate状态中。在这种情况下，将top_file_merging_strategy设置为same以强制每个环境使用其自己的顶层top file文件可能会有所帮助。
top_file_merging_strategy: same另一种选择是将state_top_saltenv设置为特定环境，以确保不考虑其他环境中的任何顶级文件：
state_top_saltenv: base使用GitFS，可以简单地分别管理每个环境的顶层文件，和/或在执行highstate状态时手动指定环境，以避免任何复杂的合并场景，也可能会有所帮助。 gitfs_env_whitelist和gitfs_env_blacklist也可以用于从GitFS隐藏不需要的分支和标签，以减少正在活跃的top files文件的数量。
当使用多个环境时，不必为每个环境创建一个顶层文件。最容易维护的方法是使用放置在base环境中的单个顶级文件。但是，这在GitFS中通常是不可行的，因为分支/标记很容易导致额外的顶级文件。但是，当仅使用默认（根）文件服务器后端时，base环境中的单个顶级文件是配置highstate状态的最常见方法。
以下minion配置选项会影响未指定环境时top file文件的编译方式，建议遵循以下四个链接的解释以了解有关这些选项如何工作的更多信息：
对于以下方案，请进行以下配置：
/etc/salt/master:
file_roots:
base:
- /srv/salt/base
dev:
- /srv/salt/dev
qa:
- /srv/salt/qa/srv/salt/base/top.sls:
base:
'*':
- base1
dev:
'*':
- dev1
qa:
'*':
- qa1/srv/salt/dev/top.sls:
base:
'minion1':
- base2
dev:
'minion2':
- dev2
qa:
'*':
- qa1
- qa2注意：就这些示例而言，在
qa环境中没有top file文件。
在这种情况下，highstate是使用saltenv=dev调用的，或者是minion具有环境属性：在minion配置文件中设置的dev。 结果将是只有来自dev环境的dev2 SLS成为highstate状态的一部分，并将其应用于minion2，而minion1将不对其应用任何状态。
如果指定了base环境，则结果将是只有base环境中的base1 SLS会成为highstate状态的一部分，并且它将应用于所有minions。
如果指定了qa环境，则highstate状态将退出并显示错误。
在这种情况下，假设首先评估了base环境的top file文件，则base1，dev1和qa1状态将应用于所有minions。 例如，如果未在/srv/salt/base/top.sls中定义qa环境，则由于没有用于qa环境的顶层文件，因此不会应用来自qa环境的状态。
在版本2016.11.0中进行了更改： 在以前的版本中，“same”并不能完全按照以下说明工作（请参阅 此处）。 现在，此问题已得到纠正。
在这种情况下，base环境中的base1将应用于所有minions。 另外，来自dev环境的dev2应用于minion2。
如果未设置default_top（或将其设置为base，这恰好是默认值），则来自qa环境的qa1将应用于所有minions。 如果将default_top设置为dev，则来自qa环境的qa1和qa2都将应用于所有minions。
New in version 2016.11.0.
在这种情况下，将应用所有top files文件中的所有配置状态。 从base环境来看，base1将应用于所有minions，而base2仅应用于minion1。 从dev环境中，dev1将应用于所有minions，而dev2仅应用于minion2。 最后，在qa环境中，qa1和qa2状态都将应用于所有minions。 请注意，即使qa1出现两次，也不会两次应用qa1状态。