mirror of
https://github.com/valitydev/salt.git
synced 2024-11-07 17:09:03 +00:00
9c63495e04
This completes the documentation audit begun in cf365f7
, using proper
backticks and :strong: tags to emphasize text, converting groups of
shell commands to bash code-block sections, etc. This also replaces the
use of \* with the easier-to-grok '*', which will hopefully reduce
confusion among new users.
194 lines
6.4 KiB
ReStructuredText
194 lines
6.4 KiB
ReStructuredText
=======================
|
|
States tutorial, part 1
|
|
=======================
|
|
|
|
The purpose of this tutorial is to demonstrate how quickly you can configure a
|
|
system to be managed by Salt States. For detailed information about the state
|
|
system please refer to the full :doc:`states reference </ref/states/index>`.
|
|
|
|
This tutorial will walk you through using Salt to configure a minion to run the
|
|
Apache HTTP server and to ensure the server is running.
|
|
|
|
.. include:: /_incl/requisite_incl.rst
|
|
|
|
Setting up the Salt State Tree
|
|
==============================
|
|
|
|
States are stored in text files on the master and transferred to the minions on
|
|
demand via the master's File Server. The collection of state files make up the
|
|
:term:`State Tree`.
|
|
|
|
To start using a central state system in Salt, the Salt File Server must first
|
|
be set up. Edit the master config file (:conf_master:`file_roots`) and
|
|
uncomment the following lines:
|
|
|
|
.. code-block:: yaml
|
|
|
|
file_roots:
|
|
base:
|
|
- /srv/salt
|
|
|
|
.. note::
|
|
|
|
If you are deploying on FreeBSD via ports, the ``file_roots`` path defaults
|
|
to ``/usr/local/etc/salt/states``.
|
|
|
|
Restart the Salt master in order to pick up this change:
|
|
|
|
.. code-block:: bash
|
|
|
|
pkill salt-master
|
|
salt-master -d
|
|
|
|
Preparing the Top File
|
|
======================
|
|
|
|
On the master, in the directory uncommented in the previous step,
|
|
(``/srv/salt`` by default), create a new file called
|
|
:conf_master:`top.sls <state_top>` and add the following:
|
|
|
|
.. code-block:: yaml
|
|
|
|
base:
|
|
'*':
|
|
- webserver
|
|
|
|
The :term:`top file` is separated into environments (discussed later). The
|
|
default environment is ``base``. Under the ``base`` environment a collection of
|
|
minion matches is defined; for now simply specify all hosts (``*``).
|
|
|
|
.. _targeting-minions:
|
|
.. admonition:: Targeting minions
|
|
|
|
The expressions can use any of the targeting mechanisms used by Salt —
|
|
minions can be matched by glob, PCRE regular expression, or by :doc:`grains
|
|
</topics/targeting/grains>`. For example:
|
|
|
|
.. code-block:: yaml
|
|
|
|
base:
|
|
'os:Fedora':
|
|
- match: grain
|
|
- webserver
|
|
|
|
Create an ``sls`` module
|
|
========================
|
|
|
|
In the same directory as the :term:`top file`, create an empty file named
|
|
``webserver.sls``, containing the following:
|
|
|
|
.. code-block:: yaml
|
|
|
|
apache: # ID declaration
|
|
pkg: # state declaration
|
|
- installed # function declaration
|
|
|
|
The first line, called the :term:`ID declaration`, is an arbitrary identifier.
|
|
In this case it defines the name of the package to be installed. **NOTE:** the
|
|
package name for the Apache httpd web server may differ depending on OS or
|
|
distro — for example, on Fedora it is ``httpd`` but on Debian/Ubuntu it
|
|
is ``apache2``.
|
|
|
|
The second line, called the :term:`state declaration`, defines which of the
|
|
Salt States we are using. In this example, we are using the :mod:`pkg state
|
|
<salt.states.pkg>` to ensure that a given package is installed.
|
|
|
|
The third line, called the :term:`function declaration`, defines which function
|
|
in the :mod:`pkg state <salt.states.pkg>` module to call.
|
|
|
|
.. admonition:: Renderers
|
|
|
|
States :term:`sls` files can be written in many formats. Salt requires only
|
|
a simple data structure and is not concerned with how that data structure
|
|
is built. Templating languages and `DSLs`_ are a dime-a-dozen and everyone
|
|
has a favorite.
|
|
|
|
Building the expected data structure is the job of Salt :doc:`renderers
|
|
</ref/renderers/index>` and they are dead-simple to write.
|
|
|
|
In this tutorial we will be using YAML in Jinja2 templates, which is the
|
|
default format. The default can be changed by editing
|
|
:conf_master:`renderer` in the master configuration file.
|
|
|
|
.. _`DSLs`: http://en.wikipedia.org/wiki/Domain-specific_language
|
|
|
|
Install the package
|
|
===================
|
|
|
|
Next, let's run the state we created. Open a terminal on the master and run:
|
|
|
|
.. code-block:: bash
|
|
|
|
% salt '*' state.highstate
|
|
|
|
Our master is instructing all targeted minions to run :func:`state.highstate
|
|
<salt.modules.state.highstate>`. When a minion executes a highstate call it
|
|
will download the :term:`top file` and attempt to match the expressions. When
|
|
it does match an expression the modules listed for it will be downloaded,
|
|
compiled, and executed.
|
|
|
|
Once completed, the minion will report back with a summary of all actions taken
|
|
and all changes made.
|
|
|
|
.. _sls-file-namespace:
|
|
.. admonition:: SLS File Namespace
|
|
|
|
Note that in the :ref:`example <targeting-minions>` above, the SLS file
|
|
``webserver.sls`` was referred to simply as ``webserver``. The namespace
|
|
for SLS files follows a few simple rules:
|
|
|
|
1. The ``.sls`` is discarded (i.e. ``webserver.sls`` becomes
|
|
``webserver``).
|
|
2. Subdirectories can be used for better organization.
|
|
a. Each subdirectory is represented by a dot.
|
|
b. ``webserver/dev.sls`` is referred to as ``webserver.dev``.
|
|
3. A file called ``init.sls`` in a subdirectory is referred to by the path
|
|
of the directory. So, ``webserver/init.sls`` is referred to as
|
|
``webserver``.
|
|
4. If both ``webserver.sls`` and ``webserver/init.sls`` happen to exist,
|
|
``webserver/init.sls`` will be ignored and ``webserver.sls`` will be the
|
|
file referred to as ``webserver``.
|
|
|
|
|
|
.. admonition:: Troubleshooting Salt
|
|
|
|
If the expected output isn't seen, the following tips can help to
|
|
narrow down the problem.
|
|
|
|
Turn up logging
|
|
Salt can be quite chatty when you change the logging setting to
|
|
``debug``:
|
|
|
|
.. code-block:: bash
|
|
|
|
salt-minion -l debug
|
|
|
|
Run the minion in the foreground
|
|
By not starting the minion in daemon mode (:option:`-d <salt-minion
|
|
-d>`) one can view any output from the minion as it works:
|
|
|
|
.. code-block:: bash
|
|
|
|
salt-minion &
|
|
|
|
Increase the default timeout value when running :command:`salt`. For
|
|
example, to change the default timeout to 60 seconds:
|
|
|
|
.. code-block:: bash
|
|
|
|
salt -t 60
|
|
|
|
For best results, combine all three:
|
|
|
|
.. code-block:: bash
|
|
|
|
salt-minion -l debug & # On the minion
|
|
salt '*' state.highstate -t 60 # On the master
|
|
|
|
Next steps
|
|
==========
|
|
|
|
This tutorial focused on getting a simple Salt States configuration working.
|
|
:doc:`Part 2 <states_pt2>` will build on this example to cover more advanced
|
|
:term:`sls` syntax and will explore more of the states that ship with Salt.
|