Saltstack Quick Start Simple Summary

saltstack is written using python open source automated deployment and management tools , with good scalability and excellent execution efficiency , simple configuration , can work on multiple platforms , often described as Func enhanced version + Puppet lite .

saltsatck Advantages: First, fast , based on message queues + threads , run through multiple devices , are milliseconds ; second, very flexible , the source code is python , easy to understand and customize the module ; Finally, simple commands , powerful .

Preface: a long time ago, there are only a few hosts, of course, do not need any automated paste tool, but with the increasingly low cost of hardware today, casually dozens of servers, by hand is not impossible, but repeated over and over again without too much technical operation must make people crazy, so it is necessary to choose a batch operation can be deployed automation tools such as Pupet, ansible, rundeck, faric and other tools are quite a few, in view of the limited level of saltstack a little slippery. ansible, rundeck, faric and other tools less, in the way of the level of limited, temporary saltstack a little slip, a simple summary of the basic concepts, operations and so on.

Reference environment centos 6.5

Installation:

The latest seems to be 2015.8.1 if installed with pip

Master Installation

Minion Installation

You need to configure the firewall if it is turned on, cf./en/latest/topics/tutorials/#iptables

After the master and minion start up respectively, the minion side will go to the master to apply for authentication.

master execution:

Each minion client has a minion_id i.e. minion-id-1 minion-id-2 above is the client's minion_id The default is to get the client's hostname, and the minion-id cannot be repeated!!!!

Note: If you want to make changes, you need to modify the /etc/salt/minion_id configuration file on the client side, which will only be generated after salt-minion is started.

Salt-key commands

Note: After deletion, if you need to re-authenticate, just restart the client

Salt Configuration File

Two important configuration parameters are file_roots (defining directories for the environment), nodegroups (defining groups)

The main configuration file is in /etc/salt/master (master side)

/etc/salt/minion (minion side)

Note: master end configuration file is the default will load all /etc/salt// (this directory does not exist by default, you need to create their own) directory of all the configuration files ending in .conf, in order to be more readable, I will be all the custom parameters for each single creation of a configuration file, such as environment variables, you can set up the production, testing, development environments, respectively, in the next point is hosting application level categorization, according to the specific environment, specific settings.

As described in the above configuration, a total of four environments are defined, respectively, base, apache, nginx, mysql, etc., the role of environment variables will be described below, mainly with the use of sls files

The directories of the sls configuration files for different environments are placed in the corresponding directories, for example, the sls file for the base environment can be placed either in /data/salt/base or in /data/salt/base/sls, of which the sls file is what will be described later on

Next, configure the grouping information for all minions, defining group names according to usage or different ip classifications.

As mentioned above there are four groups defined above

Note: pay attention to the above format, salt almost all configuration files follow two spaces for a recursive way (i.e., file_root below the empty two are its parameters, two it parameter below the empty two space and it parameter parameter parameters, write the configuration file will be more comprehensive later), and can not be used tab key to fill in the full!!!!!.

Salt common commands:

Salt syntax

salt [client id, i.e. target] [module name, e.g. state, cmd. are actually modules of salt] [action]

The first salt command that touches saltstack must be, primarily, used to probe the client's survival status

Note: commonly used two modules are mainly state, cmd two modules, respectively, the corresponding function is state (state, will be described in detail later, what is the state), and cmd (remote execution, and the use of this module is the general method)

Let's start by describing how the target, goal, or client id is matched

True means normal, no response of course means that the client did not start or did not authenticate successfully or so on.

There are five main ways to designate goals

I: Global, the default match for salt, recognizes wildcards commonly used in terminals, such as * for all

E.g., salt '*'

II: List, list, need -L to specify.

E.g., salt -L 'foo,bar' where foo,bar is the full minion_id

III: Regular expression, need to be specified by -E.

For example, salt -E 'pre[1-7]' will match pre1, pre2...pre7, and will also match minion_id containing 1-7, e.g. pre-11,pre7.

e.g., salt -E ^pre[1-7]$ or salt pre[1-7]

IV: Mixed mode, need to be specified by -C. Inside can have both regular expressions and lists, etc.

salt -C "apache* or E@ngin*" Match any tomcat, or mon.

V: Grouping, you need to specify -N, where the group name is the configuration information configured in the /etc/salt// file above.

e.g., salt -N apache

Then there are the modules, mainly state, cmd, cp modules

Note: To learn about a module's functionality or specific parameters you can

salt \* [module name, e.g. cmd]

That is, salt \* cmd will list the relevant operations and examples.

Remote command execution

Remote command execution is probably the most common operation, such as obtaining the ip addresses of all minions, viewing files in the same directory, adding an environment variable to /etc/profile and refreshing the environment variable, and so on.

cmd module

Mainly use the run method of this module, the

is used as follows.

salt \* 'ls /root'

As shown above, all the clients are selected, and the master side uses the module to distribute all the 'ls /root' commands inside '', where the single quote '' can also be replaced by double quotes "", and the role of the quotes is to pass the quoted commands to salt-master, and then master distributes them to all minions for execution, and the above commands will list all the The above command will list all the files in the /root directory on the minion side.

Note: The commands inside the quotation marks are no different from the commands on any other machine, the only difference is that the command executed by salt is sh by default, while our common shell is bash, for example, in bash, ll is an alias for ls -l, and sh does not make an alias for ll, so the commands inside the quotation marks will not be found if you use the ll command, you will get a message that the command cannot be found.

cmd has several useful parameters that can be highlighted in the

cwd Defines the directory, i.e., the working directory, in which the command is executed.
As:

runas, which defines the user who will execute this command, and which user will be used to execute this command.
As:

Then going to the client reveals that there is a file file in the /tmp/ directory owned by nobody

And then the state module.

The main methods used are sls, highstate, and show_sls.

When talking about the state module you first have to understand the sls file.

Sls files end in .sls and are placed in the specified environment directory, i.e., the mentioned directories /data/salt/base /data/salt/base/sls or /data/salt/apache/sls, etc.

Note: If there are two identical sls files in these two directories, then the first environment directory configured by file_root will be file_root, i.e.

For example, the environment.

base:

will execute the sls file in /data/salt/base because it's on the previous line

The basic format of the sls file is as follows:

Example 1

Example 2

As shown above, in fact, Example 1 and Example 2 is to achieve the same effect, only written in a different way
Like example one, since there is no - name: /tmp/ttt20 so, it will go to the first line of the identifier as name
While the testfile in example 2 can be named whatever you want, as long as it is not the same as any other identifier in that file.

The above example achieves the function of copying the /srv/salt/files/tst file to the client's /tmp/ttt20 location, and replacing it if it exists, or prompting is correct state if it already exists and is the same, i.e., it is already the correct state.

And then there's.

There is and can only be one file in each individual salt environment, this file is the entry file for the environment, which records the corresponding sls file of the target host
As:

base:

minion-id-1:
- test1
- test2

minion-id-2:
- test1
- test3

Take tomcat-1 for example

It matches the

- test1
- test2

The above is a total of 2 sls configuration files, i.e. matching that environment, the file
So when the state module is executed, it will retrieve these corresponding configuration files and execute the contents of that configuration file.
Note: As mentioned earlier, the space in front of these parameters can not be filled with the tab key or written less, otherwise it will report an error, and then if the configuration file is When calling this configuration file, just write xxxx, that is, its filename, with no suffix.

Take test1 for example

The function is to call the file module to compare the file:// (where, salt:// is for the environment's file_root directory, i.e. /data/salt/base) with the target's /tmp/ file, and update it if it doesn't match.

and the owner of this file is root mask code 644, if the target directory does not exist, create it.

Now back to the highstate, sls, show_sls method

Execute as follows

The above meanings are in order

1. Find a file in the current environment and execute it

2. Match all the sls files in the current environment and execute them.

3. View the contents of the current environment file execution. but not on the client.

Note: The above specifically mentioned is in the current environment, by default, salt will only look for the execution of the base environment sls file, will not be executed in other environments of the configuration file, so in different environments, you need to specify the configuration environment to be executed, for example, apache environment, just the execution of apache's sls file, then you need to declare the saltenv=apache as follows