Salt in 10 minutes
SaltStack - configuration management system and remote operations.
At the moment I am studying this system and since there is such an opportunity, I decided to translate articles from the official site and promote it here until there is enough enthusiasm. Since Red Hat and Centos are mainly used in our organization, I will translate the parts related to these operating systems.
This article is a translation of official documentation. At the bottom of the page you will find a link to the source in English. language.
Installing salt-master, salt-minion from the official SaltStack repository on RHEL / CENTOS
')
Install salt-minion, salt-master and other Salt components:
Salt works on topology Master (server) / Minion (client). Minions connect to the master on TCP ports 4505,4506 .
The default configuration 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 via 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, the Minion by default searches the network for a host with a hostname salt. If found, then Minion 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 name of the salt in the IP Wizard.
If this approach does not suit you, 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 Master can be found, you can launch Minion in the same way as the Master:
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 run and caches in / etc / salt / minion_id by default. This is the name by which the Minion will try to authenticate on the Master. The following steps are taken to try to find a value other than localhost:
If the above methods do not produce an id other than localhost, then a sorted list of IP addresses (excluding the range 127.0.0.0/8) is checked on the Minion. The first is the publicly-routable IP address, if there is at least one. Otherwise, the first privately routable IP address is used.
If nothing worked, then localhost is used as a fallback.
Now that Minion is running, it will generate cryptographic keys and try to connect to the master. The next step is to go back to the Master and accept the new Minion public key.
Salt authenticates Minions using public key encryption and authentication. In order for Mignon to start accepting commands from the Master, his key must be accepted by the Master.
The salt-key command is used to manage all keys on the wizard. To view all the keys that are on the wizard:
Keys that have been accepted, rejected and awaiting acceptance will be displayed. The easiest way to accept the key of the minion is to accept all deferred keys:
Keys must be checked! Print the master key fingerprint by running salt-key -F master on the master . Copy the master.pub fingerprint from the Local Keys section and then set this value as master_finger in the configuration.
Copy the thumbprint value master.pub from the Local Keys section and set the master_finger parameter in the Minion configuration file. Save and restart the salt-minion service .
On the Wizard , run salt-key -f minion_id to print the imprint of the Minion public key, which was accepted by the Wizard. On the Minion, run salt-call key.finger --local to print the Minion key fingerprint.
On the Master:
On Mignon:
If they match, then accept the key with the command:
Now that the minion is connected to the master and is authenticated, the master can send commands to the minion. Salt commands allow you to perform an extensive set of functions for specific Minions or Minion groups. Salt commands consist of command options, a description of the target, 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 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 is an alert to the Wizard that all the minions have completed test.ping in parallel and the return of the result.
This is not really ICMP ping, but rather a simple function that returns True . Using test.ping is a good way to confirm that Minion is connected.
Each Minion registers itself with a unique ID. This ID is by default the hostname, but can be explicitly specified in the Minion config also by the id parameter.
Of course, there are hundreds of other modules that can be simply called test.ping . The following example returns disk usage on all Minions.
Salt comes with an extensive library of functions available to perform and Salt functions are self-documenting. To see which features are available on the Minions, run the sys.doc function:
It will show a very large list of available functions and documentation on them.
These functions cover everything from package management to database server management. They include a powerful API management system that is the basis for managing Salt configurations and many other Salt parties.
The cmd module contains functions that are performed on Minions, such as cmd.run and cmd.run_all :
The pkg functions automatically match the local package manager with the corresponding functions. This means pkg.install will install packages via yum on the Red Hat system, via apt on the Debian system, etc .:
The network.interfaces function lists all interfaces on the Minion, along with their IP addresses, masks, MAC addresses, etc .:
The default output format used for most Salt commands is nested (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 withdrawal methods, as well as examples of output can be found here .
The examples above described launching commands from the Wizard using the salt command, but in diagnostics it may be more effective to go to Minion via ssh and use the salt-call .
This allows you to see Minion messages related to the command being executed (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 control.
It is common practice to assign grains to Minions in order to indicate what role or roles are possible for Minion. These static grains can be set in the Minion configuration file or via 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
Target based on grains data: Targeting with Grains
Pillar
Target based on pillar data: Targeting with Pillar
IP
Target based on IP address / subnet / range
Compound
A goal based on several goals: Targeting with Compound
Nodegroup
Target with nodegroups: Targeting with Nodegroup
Many functions can use arguments that can be passed:
This example passes the vim argument to the pkg.install function. Many functions may have more complex arguments than just a string, arguments processed via YAML, allowing you to transfer more complex data:
In this case, Salt translates the string 'foo: bar' into the dictionary "{'foo': 'bar'}"
→ Source
At the moment I am studying this system and since there is such an opportunity, I decided to translate articles from the official site and promote it here until there is enough enthusiasm. Since Red Hat and Centos are mainly used in our organization, I will translate the parts related to these operating systems.
This article is a translation of official documentation. At the bottom of the page you will find a link to the source in English. language.
SALT installation
Installing 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! When installing on Red Hat Enterprise Linux 7 with disconnected (not subscribed to) RHEL Server Releases or RHEL Server Optional Channel repositories, add the CentOS 7 GPG key URL to the SaltStack yum repository configuration 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-cache
Install salt-minion, salt-master and other Salt components:
sudo yum install salt-master salt-minion salt-ssh salt-syndic salt-cloud salt-api
Running SALT
Salt works on topology Master (server) / Minion (client). Minions connect to the master on TCP ports 4505,4506 .
The default configuration 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 via 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 SALT MASTER
By default, the configuration files are in the / etc / salt directory. Most platforms follow this scheme, but platforms such as FreeBSD and Windows have this file in other places.
At startup, the Minion by default searches the network for a host with a hostname salt. If found, then Minion 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 name of the salt in the IP Wizard.
If this approach does not suit you, you can make changes to / etc / salt / minion :
master: hostname_master
or
master: IP_master
SALT MINION setting
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 Master can be found, you can launch Minion in the same way as the Master:
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 run and caches in / etc / salt / minion_id by default. This is the name by which the Minion will try to authenticate on the Master. The following steps are taken to try to find a value other than localhost:
- The socket.getfqdn () function is executed.
- Checked by / etc / hostname (not on Windows)
- Checks / etc / hosts (% WINDIR% \ system32 \ drivers \ etc \ hosts on Windows)
If the above methods do not produce an id other than localhost, then a sorted list of IP addresses (excluding the range 127.0.0.0/8) is checked on the Minion. The first is the publicly-routable IP address, if there is at least one. Otherwise, the first privately routable IP address is used.
If nothing worked, 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 set, it will override all other id sources.
Now that Minion is running, it will generate cryptographic keys and try to connect to the master. The next step is to go back to the Master and accept the new Minion public key.
Using SALT-KEY
Salt authenticates Minions using public key encryption and authentication. In order for Mignon to start accepting commands from the Master, his key must be accepted by the Master.
The salt-key command is used to manage all keys on the wizard. To view all the keys that are on the wizard:
salt-key -L
Keys that have been accepted, rejected and awaiting acceptance will be displayed. The easiest way to accept the key of the minion is to accept all deferred keys:
salt-key -A
Keys must be checked! Print the master key fingerprint by running salt-key -F master on the master . Copy the master.pub fingerprint from the Local Keys section and then set this value as 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 thumbprint value master.pub from the Local Keys section and set the master_finger parameter in the Minion configuration file. Save and restart the salt-minion service .
On the Wizard , run salt-key -f minion_id to print the imprint of the Minion public key, which was accepted by the Wizard. On the Minion, run salt-call key.finger --local to print the Minion key fingerprint.
On the Master:
# 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
On Mignon:
# 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 first teams
Now that the minion is connected to the master and is authenticated, the master can send commands to the minion. Salt commands allow you to perform an extensive set of functions for specific Minions or Minion groups. Salt commands consist of command options, a description of the target, 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 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! Executive modules 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 is an alert to the Wizard that all the minions have completed test.ping in parallel and the return of the result.
This is not really ICMP ping, but rather a simple function that returns True . Using test.ping is a good way to confirm that Minion is connected.
Each Minion registers itself with a unique ID. This ID is by default the hostname, but can be explicitly specified in the Minion config also by the id parameter.
Of course, there are hundreds of other modules that can be simply called test.ping . The following example returns disk usage on all Minions.
salt '*' disk.usage
Introduction to functions
Salt comes with an extensive library of functions available to perform and Salt functions are self-documenting. To see which features are available on the Minions, run 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 website .
These functions cover everything from package management to database server management. They include a powerful API management system that is the basis for managing Salt configurations and many other Salt parties.
Attention!
Salt comes with a large number of system plugins. Functions that are available by means of salt commands are called executive modules .
Useful features
The cmd module contains functions that are performed on Minions, such as cmd.run and cmd.run_all :
salt '*' cmd.run 'ls -l /etc'
The pkg functions automatically match the local package manager with the corresponding functions. This means pkg.install will install packages via yum on the Red Hat system, via apt on the Debian system, etc .:
salt '*' pkg.install vim
Attention! Some custom Linux builds and derivatives from some distributions are not correctly determined by Salt. If the above command returns an error like pkg.install is not available then you can override the pkg provider. This process is described here .
The network.interfaces function lists all interfaces on the Minion, along with their IP addresses, masks, MAC addresses, etc .:
salt '*' network.interfaces
CHANGING THE OUTPUT FORMAT
The default output format used for most Salt commands is nested (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 withdrawal methods, as well as examples of output can be found here .
SALT-CALL
The examples above described launching commands from the Wizard using the salt command, but in diagnostics it may be more effective to go to Minion via ssh and use the salt-call .
This allows you to see Minion messages related to the command being executed (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 control.
It is common practice to assign grains to Minions in order to indicate what role or roles are possible for Minion. These static grains can be set in the Minion configuration file or via 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.ping
or
salt 'larry*' test.ping
or
salt '*1' test.ping
There are many other ways besides the main ones:
Regular expressions
Using pcre-compatible regular expressions
Grains
Target based on grains data: Targeting with Grains
Pillar
Target based on pillar data: Targeting with Pillar
IP
Target based on IP address / subnet / range
Compound
A goal based on several goals: Targeting with Compound
Nodegroup
Target with nodegroups: Targeting with Nodegroup
Passing arguments
Many functions can use arguments that can be passed:
salt '*' pkg.install vim
This example passes the vim argument to the pkg.install function. Many functions may have more complex arguments than just a string, arguments processed via YAML, allowing you to transfer more complex data:
salt '*' test.echo 'foo: bar'
In this case, Salt translates the string 'foo: bar' into the dictionary "{'foo': 'bar'}"
Attention! Any string that contains a newline character will not be processed in YAML.
→ Source
Source: https://habr.com/ru/post/315012/
All Articles