Salt in 10 minutes
SaltStack - a system of configuration management and remote operations.
At the moment, I’m studying this system and since there is such an opportunity I decided to translate articles from the official website and post here for now enough enthusiasm. Because our organization uses mainly Red Hat and Centos, I will translate parts related to these operating systems.
This article is a translation of the official documentation. At the bottom of the page you will find a link to the source in English. language.
Install salt-master, salt-minion from the official SaltStack repository on RHEL / CENTOS
Install salt-minion, salt-master and other Salt components:
Salt works on the topology of Master (server) / Minion (client). Minions connect to the master on TCP ports 4505,4506 .
The default configuration of the Wizard is suitable for the vast majority of installations. Salt Master is managed by local service managers:
On systems with systemd (new Debian, OpenSuse, Fedora, Centos, RHEL):
On systems with Upstart (Ubuntu, older Fedora / RHEL):
Alternatively, the Wizard can be launched directly through the command line as a daemon:
The wizard can also be run in debug mode, thus greatly increasing the output of commands:
The wizard accepts incoming connections on TCP ports 4505,4506 .
At startup, Mignon by default searches the network for a host with hostname salt. If found, then Mignon initiates the process of handshaking and key authentication with the Master. This means that the easiest way to configure this is to configure the internal DNS to resolve the salt name in the IP Wizard.
If this approach does not suit you, then you can make changes to / etc / salt / minion :
or
A minion can function with or without a Master. This guide assumes that the Minion will be connected to the Master, for information on how to start the Minion without the Master, see here .
After the Wizard can be found, you can start the Minion in the same way as the Wizards:
On systems with systemd (new Debian, OpenSuse, Fedora, Centos, RHEL):
On systems with Upstart (Ubuntu, older Fedora / RHEL):
Like a demon:
In the background with the debug option:
When the Minion starts, it generates an id if it was not generated during the previous launch and caches in / etc / salt / minion_id by default. This is the name by which the Minion will try to authenticate to the Master. The following steps are taken to try to find a value other than localhost:
If the above methods did not produce an id other than localhost, then a sorted list of IP addresses (excluding the range 127.0.0.0/8) on the Minion is checked. The first to use is a publicly routable IP address, if there is at least one. Otherwise, the first private routable IP address is used.
If nothing works, then localhost is used as a fallback.
Now that Mignon is running, it will generate cryptographic keys and try to connect to the wizard. The next step is to return to the Master and accept the new public key of Minion.
Salt authenticates the Minions using the public encryption key and authentication. In order for the Minion to start accepting commands from the Master, its key must be accepted by the Master.
The salt-key command is used to manage all keys on the wizard. To view all keys that are on the wizard:
The keys that were accepted, rejected and are pending acceptance will be displayed. The easiest way to accept a minion key is to accept all pending keys:
Keys must be verified! Display the fingerprint of the Master key by running salt-key -F master on the Master. Copy the master.pub fingerprint from the Local Keys section and then set this value to master_finger in the configuration.
Copy the value of the master.pub fingerprint from the Local Keys section and set master_finger in the Minion configuration file as the parameter . Save and restart the salt-minion service .
On the Wizard , run salt-key -f minion_id to print the Minion public key fingerprint that was accepted by the Wizard. In Minion, run salt-call key.finger --local to print the fingerprint of the Minion key.
On the Wizard:
At the Minion:
If they match, then accept the key with the command:
Now that the minion is connected to the Master and authenticated, the Master can send commands to the Minion. Salt commands allow you to perform an extensive set of functions for specific Minions or groups of Minions. Salt commands consist of command options, a description of the goal, a function of execution, and function arguments.
A simple command looks like this:
An asterisk (*) defines a target that identifies all Minions. test.ping tells the minions to run the test.ping function . In the case of test.ping, test refers to the execution module . ping refers to the ping function contained in the above module.
The result of this command will be the notification of the Master that all minions have completed test.ping in parallel and the result will be returned.
This is actually not ICMP ping, but rather a simple function that returns True . Using test.ping is a good way to confirm that the minion is connected.
Each Minion registers itself with a unique ID. This ID is hostname by default, but can also be explicitly set in the Mignon config using the id parameter .
Of course, there are hundreds of other modules that can be called just like test.ping . The following example returns disk usage on all Minions.
Salt comes with an extensive library of functions available to execute and Salt functions are self-documenting. To see what functions are available in the Minions, execute the sys.doc function:
It will show a very large list of available functions and documentation on them.
These features cover everything from package management to managing database servers. They include a powerful API management system, which is the basis for managing the configurations of Salt and many other aspects of Salt.
The cmd module contains functions that are executed in the Minions, such as cmd.run and cmd.run_all :
pkg functions automatically map the local package manager to the corresponding functions. This means pkg.install will install packages through yum on the Red Hat system, through apt on the Debian system, etc.:
The network.interfaces function displays a list of all the interfaces in the Minion, along with their IP addresses, masks, MAC addresses, etc.:
The default output format used for most Salt commands is called nested , but there are several other ways that can be used to change the output. For example, the pprint method can be used to display the returned data using the python pprint module:
A complete list of Salt output methods as well as output examples can be found here .
The examples above described running commands from the Wizard using the salt command, but for diagnostics it may be more efficient to go to the Minion via ssh and use salt-call .
This allows you to see the Minion messages related to the executable command (which are not part of the output that you see when you run the salt command), which makes it unnecessary to use the tail -f / vat / log / salt / command . More information about salt-call can be found here .
Salt uses a system called Grains to build static Minion data. This data includes information about the OS, CPU architecture, and much more. The grains system is used by Salt to deliver platform data to many partners and users.
Grains can also be a static set, making it easy to assign values to Minions for grouping and management.
It is common practice to assign grains to the Minions to indicate which role or roles are possible for the Minion. These static grains can be set in the Minion configuration file or through the grains.setval function.
Salt allows you to specify Minions as a target by a large number of criteria.
or
or
There are many other ways besides the main ones:
Regular Expressions
Using pcre-compatible regular expressions
Grains
Data-based target grains: Targeting with Grains
Pillar
Data-based target pillar: Targeting with Pillar
IP IP-
based target address / subnet / range
Compound
Multi-based target goals: Targeting with Compound
Nodegroup
Target with nodegroups: Targeting with Nodegroup
Many functions can apply arguments that can be passed:
This example passes the vim argument to the pkg.install function . Many functions can have more complex arguments than just a string, arguments processed through YAML, allowing the transfer of more complex data:
In this case, Salt translates the string 'foo: bar' into the dictionary "{'foo': 'bar'}"
→ Source
At the moment, I’m studying this system and since there is such an opportunity I decided to translate articles from the official website and post here for now enough enthusiasm. Because our organization uses mainly Red Hat and Centos, I will translate parts related to these operating systems.
This article is a translation of the official documentation. At the bottom of the page you will find a link to the source in English. language.
SALT Installation
Install salt-master, salt-minion from the official SaltStack repository on RHEL / CENTOS
sudo yum install https://repo.saltstack.com/yum/redhat/salt-repo-latest-2.el7.noarch.rpm
Attention! If installing on Red Hat Enterprise Linux 7 with disabled (not subscribed to) RHEL Server Releases or RHEL Server Optional Channel repositories, add the CentOS 7 GPG key URL to the yum configuration of the SaltStack repository to install the base packages.[saltstack-repo] name=SaltStack repo for Red Hat Enterprise Linux $releasever baseurl=https://repo.saltstack.com/yum/redhat/$releasever/$basearch/latest enabled=1 gpgcheck=1 gpgkey=https://repo.saltstack.com/yum/redhat/$releasever/$basearch/latest/SALTSTACK-GPG-KEY.pub https://repo.saltstack.com/yum/redhat/$releasever/$basearch/latest/base/RPM-GPG-KEY-CentOS-7
sudo yum clean expire-cacheInstall salt-minion, salt-master and other Salt components:
sudo yum install salt-master salt-minion salt-ssh salt-syndic salt-cloud salt-api
Launch SALT
Salt works on the topology of Master (server) / Minion (client). Minions connect to the master on TCP ports 4505,4506 .
The default configuration of the Wizard is suitable for the vast majority of installations. Salt Master is managed by local service managers:
On systems with systemd (new Debian, OpenSuse, Fedora, Centos, RHEL):
systemctl start salt-master
On systems with Upstart (Ubuntu, older Fedora / RHEL):
service salt-master start
Alternatively, the Wizard can be launched directly through the command line as a daemon:
salt-master -d
The wizard can also be run in debug mode, thus greatly increasing the output of commands:
salt-master -l debug
The wizard accepts incoming connections on TCP ports 4505,4506 .
Search for SALT MASTER
By default, the configuration files are in the / etc / salt directory . Most platforms adhere to this scheme, but platforms such as FreeBSD and Windows locate this file elsewhere.
At startup, Mignon by default searches the network for a host with hostname salt. If found, then Mignon initiates the process of handshaking and key authentication with the Master. This means that the easiest way to configure this is to configure the internal DNS to resolve the salt name in the IP Wizard.
If this approach does not suit you, then you can make changes to / etc / salt / minion :
master: hostname_master
or
master: IP_master
Setting SALT MINION
A minion can function with or without a Master. This guide assumes that the Minion will be connected to the Master, for information on how to start the Minion without the Master, see here .
After the Wizard can be found, you can start the Minion in the same way as the Wizards:
On systems with systemd (new Debian, OpenSuse, Fedora, Centos, RHEL):
systemctl start salt-minion
On systems with Upstart (Ubuntu, older Fedora / RHEL):
service salt-minion start
Like a demon:
salt-minion -d
In the background with the debug option:
salt-minion -l debug
When the Minion starts, it generates an id if it was not generated during the previous launch and caches in / etc / salt / minion_id by default. This is the name by which the Minion will try to authenticate to the Master. The following steps are taken to try to find a value other than localhost:
- The socket.getfqdn () function is executed
- Checks / etc / hostname (not on Windows)
- Checked / etc / hosts (% WINDIR% \ system32 \ drivers \ etc \ hosts on Windows)
If the above methods did not produce an id other than localhost, then a sorted list of IP addresses (excluding the range 127.0.0.0/8) on the Minion is checked. The first to use is a publicly routable IP address, if there is at least one. Otherwise, the first private routable IP address is used.
If nothing works, then localhost is used as a fallback.
The Minion id can be set manually using the id parameter in the Minion configuration file. If this parameter is specified, it will override all other id sources.
Now that Mignon is running, it will generate cryptographic keys and try to connect to the wizard. The next step is to return to the Master and accept the new public key of Minion.
Using SALT-KEY
Salt authenticates the Minions using the public encryption key and authentication. In order for the Minion to start accepting commands from the Master, its key must be accepted by the Master.
The salt-key command is used to manage all keys on the wizard. To view all keys that are on the wizard:
salt-key -L
The keys that were accepted, rejected and are pending acceptance will be displayed. The easiest way to accept a minion key is to accept all pending keys:
salt-key -A
Keys must be verified! Display the fingerprint of the Master key by running salt-key -F master on the Master. Copy the master.pub fingerprint from the Local Keys section and then set this value to master_finger in the configuration.
# salt-key -F master
Local Keys:
master.pem: 6c:a0:e8:b0:84:36:59:86:b6:49:c3:fb:87:a4:c4:e9
master.pub: d9:c6:e0:42:76:e5:82:f7:13:6a:65:ee:cb:f3:2e:aa
Copy the value of the master.pub fingerprint from the Local Keys section and set master_finger in the Minion configuration file as the parameter . Save and restart the salt-minion service .
On the Wizard , run salt-key -f minion_id to print the Minion public key fingerprint that was accepted by the Wizard. In Minion, run salt-call key.finger --local to print the fingerprint of the Minion key.
On the Wizard:
# salt-key -f foo.domain.com
Unaccepted Keys:
foo.domain.com: 39:f9:e4:8a:aa:74:8d:52:1a:ec:92:03:82:09:c8:f9
At the Minion:
# salt-call key.finger --local
local:
39:f9:e4:8a:aa:74:8d:52:1a:ec:92:03:82:09:c8:f9
If they match, then accept the key with the command:
salt-key -a foo.domain
Sending the first teams
Now that the minion is connected to the Master and authenticated, the Master can send commands to the Minion. Salt commands allow you to perform an extensive set of functions for specific Minions or groups of Minions. Salt commands consist of command options, a description of the goal, a function of execution, and function arguments.
A simple command looks like this:
salt '*' test.ping
An asterisk (*) defines a target that identifies all Minions. test.ping tells the minions to run the test.ping function . In the case of test.ping, test refers to the execution module . ping refers to the ping function contained in the above module.
Attention! Actuators are Salt workhorses. They perform work in the system by performing various tasks, such as file manipulation and restart services.
The result of this command will be the notification of the Master that all minions have completed test.ping in parallel and the result will be returned.
This is actually not ICMP ping, but rather a simple function that returns True . Using test.ping is a good way to confirm that the minion is connected.
Each Minion registers itself with a unique ID. This ID is hostname by default, but can also be explicitly set in the Mignon config using the id parameter .
Of course, there are hundreds of other modules that can be called just like test.ping . The following example returns disk usage on all Minions.
salt '*' disk.usage
Familiarity with the features
Salt comes with an extensive library of functions available to execute and Salt functions are self-documenting. To see what functions are available in the Minions, execute the sys.doc function:
salt '*' sys.doc
It will show a very large list of available functions and documentation on them.
Attention! Module documentation may also be available on the site .
These features cover everything from package management to managing database servers. They include a powerful API management system, which is the basis for managing the configurations of Salt and many other aspects of Salt.
Attention!
Salt comes with a large number of system plugins. Functions that are accessible by means of salt commands are called executive modules .
Useful features
The cmd module contains functions that are executed in the Minions, such as cmd.run and cmd.run_all :
salt '*' cmd.run 'ls -l /etc'pkg functions automatically map the local package manager to the corresponding functions. This means pkg.install will install packages through yum on the Red Hat system, through apt on the Debian system, etc.:
salt '*' pkg.install vimAttention! Some custom Linux builds and derivatives of some distributions are not correctly defined by Salt. If the above command returns an error like pkg.install is not available then you can override pkg provider. This process is described here .
The network.interfaces function displays a list of all the interfaces in the Minion, along with their IP addresses, masks, MAC addresses, etc.:
salt '*' network.interfacesCHANGING THE OUTPUT FORMAT
The default output format used for most Salt commands is called nested , but there are several other ways that can be used to change the output. For example, the pprint method can be used to display the returned data using the python pprint module:
root@saltmaster:~# salt myminion grains.item pythonpath --out=pprint
{'myminion': {'pythonpath': ['/usr/lib64/python2.7',
'/usr/lib/python2.7/plat-linux2',
'/usr/lib64/python2.7/lib-tk',
'/usr/lib/python2.7/lib-tk',
'/usr/lib/python2.7/site-packages',
'/usr/lib/python2.7/site-packages/gst-0.10',
'/usr/lib/python2.7/site-packages/gtk-2.0']}}A complete list of Salt output methods as well as output examples can be found here .
SALT-CALL
The examples above described running commands from the Wizard using the salt command, but for diagnostics it may be more efficient to go to the Minion via ssh and use salt-call .
This allows you to see the Minion messages related to the executable command (which are not part of the output that you see when you run the salt command), which makes it unnecessary to use the tail -f / vat / log / salt / command . More information about salt-call can be found here .
Grains (GRAINS)
Salt uses a system called Grains to build static Minion data. This data includes information about the OS, CPU architecture, and much more. The grains system is used by Salt to deliver platform data to many partners and users.
Grains can also be a static set, making it easy to assign values to Minions for grouping and management.
It is common practice to assign grains to the Minions to indicate which role or roles are possible for the Minion. These static grains can be set in the Minion configuration file or through the grains.setval function.
Target selection
Salt allows you to specify Minions as a target by a large number of criteria.
salt ‘larry1, larry2, curly1’ test.pingor
salt ‘larry*’ test.pingor
salt ‘*1’ test.pingThere are many other ways besides the main ones:
Regular Expressions
Using pcre-compatible regular expressions
Grains
Data-based target grains: Targeting with Grains
Pillar
Data-based target pillar: Targeting with Pillar
IP IP-
based target address / subnet / range
Compound
Multi-based target goals: Targeting with Compound
Nodegroup
Target with nodegroups: Targeting with Nodegroup
Passing arguments
Many functions can apply arguments that can be passed:
salt ‘*’ pkg.install vimThis example passes the vim argument to the pkg.install function . Many functions can have more complex arguments than just a string, arguments processed through YAML, allowing the transfer of more complex data:
salt ‘*’ test.echo ‘foo: bar’In this case, Salt translates the string 'foo: bar' into the dictionary "{'foo': 'bar'}"
Attention! Any line that contains a newline character will not be processed in YAML.
→ Source
