Salt offers an interface to manage the configuration or "state" of the Salt minions. This interface is a fully capable mechanism used to enforce the state of systems from a central manager.
State management, also frequently called Software Configuration Management (SCM), is a program that puts and keeps a system into a predetermined state. It installs software packages, starts or restarts services or puts configuration files in place and watches them for changes.
Having a state management system in place allows one to easily and reliably configure and manage a few servers or a few thousand servers. It allows configurations to be kept under version control.
Salt States是Salt模块的扩展,我们之前讨论过:doc:'remote execution </topics/tutorials/modules>'教程。而不是调用一次性完成一个系统的状态,它可以很容易地定义,然后执行。
Salt状态系统包含了很多组件。作为一个用户,理解SLS和渲染器系统也是必要的。但作为一名开发人员,了解Salt和如何写状态程序也是需要的。
注解
States are compiled and executed only on minions that have been targeted. To execute functions directly on masters, see runners.
主系统使用的状态系统叫SLS系统. SLS代表Saltstack State.
Salt状态是一些文件,其中包含有关如何配置Salt 子节点的信息。 这些状态被存在一个目录树下,可以用许多不同的格式来写。
文件的内容和方法的规定尽可能简单,同时允许最大的灵活性。文件中提出和包含了子节点需要如何配置的信息。
SLS files are laid out in the Salt file server.
A simple layout can look like this:
top.sls
ssh.sls
sshd_config
users/init.sls
users/admin.sls
salt/master.sls
web/init.sls
The top.sls
file is a key component. The top.sls
files
is used to determine which SLS files should be applied to which minions.
The rest of the files with the .sls
extension in the above example are
state files.
Files without a .sls
extensions are seen by the Salt master as
files that can be downloaded to a Salt minion.
States are translated into dot notation. For example, the ssh.sls
file is
seen as the ssh state and the users/admin.sls
file is seen as the
users.admin state.
Files named init.sls
are translated to be the state name of the parent
directory, so the web/init.sls
file translates to the web
state.
In Salt, everything is a file; there is no "magic translation" of files and file types. This means that a state file can be distributed to minions just like a plain text or binary file.
The Salt state files are simple sets of data. Since SLS files are just data they can be represented in a number of different ways.
The default format is YAML generated from a Jinja template. This allows for the states files to have all the language constructs of Python and the simplicity of YAML.
State files can then be complicated Jinja templates that translate down to YAML, or just plain and simple YAML files.
The State files are simply common data structures such as dictionaries and lists, constructed using a templating language such as YAML.
这儿有一个salt 状态的模板:
vim:
pkg.installed: []
salt:
pkg.latest:
- name: salt
service.running:
- names:
- salt-master
- salt-minion
- require:
- pkg: salt
- watch:
- file: /etc/salt/minion
/etc/salt/minion:
file.managed:
- source: salt://salt/minion
- user: root
- group: root
- mode: 644
- require:
- pkg: salt
这小结将确认vim安装,salt的安装和更新,salt-master salt-minion守护进程正在运行和salt minion的配置文件适当的位置。它还将确保一切都部署在正确的顺序和当侦听到文件更新时,salt服务将被重启。
The top file controls the mapping between minions and the states which should be applied to them.
The top file specifies which minions should have which SLS files applied and which environments they should draw those SLS files from.
The top file works by specifying environments on the top-level.
Each environment contains globs to match minions. Finally, each glob contains a list of lists of Salt states to apply to matching minions:
base:
'*':
- salt
- users
- users.admin
'saltmaster.*':
- match: pcre
- salt.master
This above example uses the base environment which is built into the default Salt setup.
The base environment has two globs. First, the '*' glob contains a list of SLS files to apply to all minions.
The second glob contains a regular expression that will match all minions with an ID matching saltmaster.* and specifies that for those minions, the salt.master state should be applied.
Some Salt states require that specific packages be installed in order for the
module to load. As an example the pip
state
module requires the pip package for proper name and version parsing.
In most of the common cases, Salt is clever enough to transparently reload the modules. For example, if you install a package, Salt reloads modules because some other module or state might require just that package which was installed.
On some edge-cases salt might need to be told to reload the modules. Consider
the following state file which we'll call pep8.sls
:
python-pip:
cmd.run:
- name: |
easy_install --script-dir=/usr/bin -U pip
- cwd: /
pep8:
pip.installed:
- require:
- cmd: python-pip
上面的实例安装需要安装'pip'和“setuptools”的'easy_install'工具来安装‘pep8’: 'pip <salt.states.pip_state>', 正如前面说的那样,要求'pip'安装到整个系统中.让我们执行这个状态。
salt-call state.sls pep8
执行输出应该类似于:
----------
State: - pip
Name: pep8
Function: installed
Result: False
Comment: State pip.installed found in sls pep8 is unavailable
Changes:
Summary
------------
Succeeded: 1
Failed: 1
------------
Total: 2
如果你再次执行这个状态,输出应该是:
----------
State: - pip
Name: pep8
Function: installed
Result: True
Comment: Package was successfully installed
Changes: pep8==1.4.6: Installed
Summary
------------
Succeeded: 2
Failed: 0
------------
Total: 2
Since we installed pip using cmd
, Salt has no way
to know that a system-wide package was installed.
On the second execution, since the required pip package was installed, the state executed correctly.
注解
Salt does not reload modules on every state run because doing so would greatly slow down state execution.
所以我们如何解决缓慢的状态?"重载模块"!
reload_modules
is a boolean option recognized by salt on all available
states which forces salt to reload its modules once a given state finishes.
The modified state file would now be:
python-pip:
cmd.run:
- name: |
easy_install --script-dir=/usr/bin -U pip
- cwd: /
- reload_modules: true
pep8:
pip.installed:
- require:
- cmd: python-pip
让我们来运行一次:
salt-call state.sls pep8
The output is:
----------
State: - pip
Name: pep8
Function: installed
Result: True
Comment: Package was successfully installed
Changes: pep8==1.4.6: Installed
Summary
------------
Succeeded: 2
Failed: 0
------------
Total: 2