saltstack官方文档——The Top File
来源:互联网 发布:常熟淘宝拍卖 编辑:程序博客网 时间:2024/06/05 15:24
转自:http://docs.saltstack.com/ref/states/top.html?highlight=top%20file
The Top File
The top file is used to map what SLS modules get loaded onto what minions via the state system. The top file creates a few general abstractions. First it maps what nodes should pull from which environments, next it defines which matches systems should draw from.
ENVIRONMENTS
- Environment
- A configuration that allows conceptually organizing state tree directories. Environments can be made to be self-contained or state trees can be made to bleed through environments.
The environments in the top file corresponds with the environments defined in the file_roots variable. In a simple, single environment setup you only have the base environment, and therefore only one state tree. Here is a simple example of file_roots in the master configuration:
file_roots: base: - /srv/salt
This means that the top file will only have one environment to pull from, here is a simple, single environment top file:
base: '*': - core - edit
This also means that /srv/salt has a state tree. But if you want to use multiple environments, or partition the file server to serve more than just the state tree, then the file_roots option can be expanded:
file_roots: base: - /srv/salt/base dev: - /srv/salt/dev qa: - /srv/salt/qa prod: - /srv/salt/prod
Then our top file could reference the environments:
dev: 'webserver*dev*': - webserver 'db*dev*': - dbqa: 'webserver*qa*': - webserver 'db*qa*': - dbprod: 'webserver*prod*': - webserver 'db*prod*': - db
In this setup we have state trees in three of the four environments, and no state tree in the base environment. Notice that the targets for the minions specify environment data. In Salt the master determines who is in what environment, and many environments can be crossed together. For instance, a separate global state tree could be added to the base environment if it suits your deployment:
base: '*': - globaldev: 'webserver*dev*': - webserver 'db*dev*': - dbqa: 'webserver*qa*': - webserver 'db*qa*': - dbprod: 'webserver*prod*': - webserver 'db*prod*': - db
In this setup all systems will pull the global SLS from the base environment, as well as pull from their respective environments.
Remember, that since everything is a file in Salt, the environments are primarily file server environments, this means that environments that have nothing to do with states can be defined and used to distribute other files.
A clean and recommended setup for multiple environments would look like this:
# Master file_roots configuration:file_roots: base: - /srv/salt/base dev: - /srv/salt/dev qa: - /srv/salt/qa prod: - /srv/salt/prod
Then only place state trees in the dev, qa and prod environments, leaving the base environment open for generic file transfers. Then the top.sls file would look something like this:
dev: 'webserver*dev*': - webserver 'db*dev*': - dbqa: 'webserver*qa*': - webserver 'db*qa*': - dbprod: 'webserver*prod*': - webserver 'db*prod*': - db
OTHER WAYS OF TARGETING MINIONS
In addition to globs, minions can be specified in top files a few other ways. Some common ones are compound matches and node groups.
Here is a slightly more complex top file example, showing the different types of matches you can perform:
base: '*': - ldap-client - networking - salt.minion 'salt-master*': - salt.master '^(memcache|web).(qa|prod).loc$': - match: pcre - nagios.mon.web - apache.server 'os:Ubuntu': - match: grain - repos.ubuntu 'os:(RedHat|CentOS)': - match: grain_pcre - repos.epel 'foo,bar,baz': - match: list - database 'somekey:abc': - match: pillar - xyz 'nag1* or G@role:monitoring': - match: compound - nagios.server
In this example top.sls, all minions get the ldap-client, networking and salt.minion states. Any minion with an id matching the salt-master* glob will get the salt.master state. Any minion with ids matching the regular expression ^(memcache|web).(qa|prod).loc$ will get the nagios.mon.web and apache.server states. All Ubuntu minions will receive the repos.ubuntu state, while all RHEL and CentOS minions will receive the repos.epel state. The minions foo, bar, and baz will receive the database state. Any minion with a pillar named somekey, having a value of abc will receive the xyz state. Finally, minions with ids matching the nag1* glob or with a grain named role equal to monitoring will receive the nagios.server state.
- saltstack官方文档——The Top File
- saltstack官方文档——Salt File Server
- saltstack官方文档——File Server Client API
- saltstack官方文档——Configuring the Salt Master
- saltstack官方文档——Configuring the Salt Minion
- saltstack官方文档——State Enforcement
- saltstack官方文档——Salt Syndic
- saltstack官方文档——Highstate data structure definitions
- saltstack官方文档——Python client API
- saltstack官方文档——Command Line Reference
- saltstack官方文档——Modules(自定义module)
- saltstack官方文档——Full list of builtin execution modules
- saltstack官方文档——Full list of builtin state modules
- Saltstack安装和基础配置官方文档
- Android 开发文档 程序基础——The manifest file
- Android File类 根据官方文档理解
- Android File类 根据官方文档理解
- Android File类 根据官方文档理解
- atof()函数实现
- 面向对象-对象通俗解释[Objective-C代码]
- android基础知识02——线程安全3:Message,MessageQueue,Handler,Looper
- ssh不使用密码登录Linux服务器
- vbaj中传递参数值方式,值传递和引用传递
- saltstack官方文档——The Top File
- jQuery设置文字样式
- PHP递归删除指定目录下的文件和目录
- iPhone开发——在tableViewTable中创建tableCell,不同分区含有不同数量的Cell
- 分割字符串 strtok(多个字符分割)
- (小说)疯狂的程序员
- Validate Binary Search Tree
- android基础知识02——线程安全4:HandlerThread
- SystemUI 概述