Introduction to saltstack
Saltstack is a C/S architecture configuration management tool based on Python. The bottom layer uses ZeroMQ message queue pub/sub mode to communicate, and uses SSL certificate issuance mode to manage authentication. Deployment is easy, it can run in a few minutes, scalability is good, it is easy to manage tens of thousands of servers, fast enough, communication between servers in seconds. ZeroMQ, known as the world's fastest message queue, enables SaltStack to perform various operations on thousands of machines quickly. It also uses RSA Key to confirm identity and AES to encrypt transmission, which guarantees security performance.
Basic principles:
The basic principle of SaltStack is to adopt C/S mode:
- Server is Salt's master, Client is minion, and the communication between minion and maseter is through ZeroMQ message queue.
- Minion starts for the first time, generates monion.pem and minion.key in the / etc/minion/pli/minion.d directory, and then sends minion.pub to master.
- The maseter side sees the key of minion through the salt-key-L command. After accepting the key of minion, the master generates the pub key in the / etc/salt/minion.d/ directory, and they trust each other.
-
Both Master and Minion run in daemon mode, listening to ret_port (accept minion request) and publish_port (publish message) ports defined in the configuration file.
- SaltStack master defaults to monitor 4505 and 4506 ports after startup. 4505 (publish_port) is the message publishing system of saltstack, 4506 (ret_port) is the port of communication between saltstack client and server. If you look at port 4505 with lsof, you will find that all minion s remain in ESTABLISHED status at port 4505.
-
ZMQ (hereinafter referred to as ZMQ) encapsulated Socket library transport layer message queue processing library makes Socket programming simpler, simpler and better performance, and can be flexible between multiple threads, kernels and host boxes. It is undoubtedly a promising layer of encapsulation on top of the "traditional" BSD Socket that people need more. ZMQ makes writing high-performance network applications extremely simple and interesting.
-
Similar to a series of socket interfaces, the difference between socket and socket is that ordinary sockets are end-to-end (1:1 relationship), while ZMQ can be N:M relationship. People know more about BSD sockets are point-to-point connections. Point-to-point connections need to explicitly establish connections, destroy connections, select protocols (TCP/UDP) and handle errors, while ZMQ shields this. Some details to make your network programming easier. ZMQ is used to communicate between node and node, which can be a host or a process.
-
Similar to a series of socket interfaces, the difference between socket and socket is that ordinary sockets are end-to-end (1:1 relationship), while ZMQ can be N:M relationship. People know more about BSD sockets are point-to-point connections. Point-to-point connections need to explicitly establish connections, destroy connections, select protocols (TCP/UDP) and handle errors, while ZMQ shields this. Some details to make your network programming easier. ZMQ is used to communicate between node and node, which can be a host or a process.
II. EXPERIMENTAL ENVIRONMENT
- Server1: 172.25.2.1/24 (salt-master,redhat6.5)
- Server2: 172.25.2.2/24 (salt-minion,redhat6.5)
- Physical host: 172.25.2.250/24 (providing yum source, redhat7.3)
Installation Pack Baidu Cloud Link:
Sal-master profile auspicious interpretation, feel that the blogger wrote a good >-<, not so good! Take a look.
saltstack official website
Three. Experiment
3.1 Add Installation Pack http Sharing to Physical Machine
1.//Import files to the publishing directory
[root@foundation2 saltstack]# cp -r rhel6/ /var/www/html/
[root@foundation2 saltstack]# cd /var/www/html/
[root@foundation2 html]# ls
rhel6 rhel6.5 source7.0 source7.2
[root@foundation2 html]# ll
total 20
drwx------ 3 root root 4096 Aug 17 05:20 rhel6
dr-xr-xr-x 12 root root 8192 Nov 12 2013 rhel6.5
dr-xr-xr-x 10 root root 4096 May 7 2014 source7.0
dr-xr-xr-x 10 root root 4096 Oct 30 2015 source7.2
[root@foundation2 html]# chmod 555 rhel6/ -R //Modify authority
[root@foundation2 html]# ll
total 20
dr-xr-xr-x 3 root root 4096 Aug 17 05:20 rhel6
dr-xr-xr-x 12 root root 8192 Nov 12 2013 rhel6.5
dr-xr-xr-x 10 root root 4096 May 7 2014 source7.0
dr-xr-xr-x 10 root root 4096 Oct 30 2015 source7.2
2.//Virtual Machine Configuration yum Source
[root@server1 ~]# vim /etc/yum.repos.d/rhel-source.repo
[rhel-source]
name=Red Hat Enterprise Linux $releasever - $basearch - Source
baseurl=http://172.25.2.250/rhel6.5
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
[salt]
name=saltstack
baseurl=http://172.25.2.250/rhel6
gpgcheck=0
3.2 Installation of salt-master
//server1:
root@server1 salt]# yum install salt-master -y
[root@server1 salt]# /etc/init.d/salt-master start
Starting salt-master daemon: [ OK ]
3.3 Install salt-minion
//server2:
[root@server2 ~]# yum install salt-minion -y
[root@server2 ~]# cd /etc/salt/
[root@server2 salt]# vim minion
17 master: 172.25.2.1 //Specify master as server1
[root@server2 salt]# /etc/init.d/salt-minion start
Starting salt-minion:root:server2 daemon: OK
3.4 Exchange Public Key
//server1:
[root@server1 salt]# salt-key -L //Looking at the key, server2 is not allowed
Accepted Keys:
Denied Keys:
Unaccepted Keys:
server2
Rejected Keys:
[root@server1 salt]# salt-key --help //View command help
Usage: salt-key [options]
salt-key is used to manage Salt authentication keys
Options:
--version show program's version number and exit
--versions-report Show program's dependencies version number and exit.
-h, --help show this help message and exit
--saltfile=SALTFILE Specify the path to a Saltfile. If not passed, one
will be searched for in the current working directory.
-c CONFIG_DIR, --config-dir=CONFIG_DIR
Pass in an alternative configuration directory.
Default: '/etc/salt'.
-u USER, --user=USER Specify user to run salt-key.
--hard-crash Raise any original exception rather than exiting
gracefully. Default: False.
-q, --quiet Suppress output.
-y, --yes Answer "Yes" to all questions presented. Default:
False.
--rotate-aes-key=ROTATE_AES_KEY
Setting this to False prevents the master from
refreshing the key session when keys are deleted or
rejected, this lowers the security of the key
deletion/rejection operation. Default: True.
Logging Options:
Logging options which override any settings defined on the
configuration files.
--log-file=KEY_LOGFILE
Log file path. Default: '/var/log/salt/key'.
--log-file-level=LOG_LEVEL_LOGFILE
Logfile logging log level. One of 'all', 'garbage',
'trace', 'debug', 'profile', 'info', 'warning',
'error', 'critical', 'quiet'. Default: 'warning'.
External Authentication:
--auth=EAUTH, --eauth=EAUTH, --external-auth=EAUTH
Specify an external authentication system to use.
-T, --make-token Generate and save an authentication token for re-use.
The token is generated and made available for the
period defined in the Salt Master.
--username=USERNAME
Username for external authentication.
--password=PASSWORD
Password for external authentication.
Output Options:
Configure your preferred output format.
--out=OUTPUT, --output=OUTPUT
Print the output from the 'salt-key' command using the
specified outputter.
--out-indent=OUTPUT_INDENT, --output-indent=OUTPUT_INDENT
Print the output indented by the provided value in
spaces. Negative values disables indentation. Only
applicable in outputters that support indentation.
--out-file=OUTPUT_FILE, --output-file=OUTPUT_FILE
Write the output to the specified file.
--out-file-append, --output-file-append
Append the output to the specified file.
--no-color, --no-colour
Disable all colored output.
--force-color, --force-colour
Force colored output.
--state-output=STATE_OUTPUT, --state_output=STATE_OUTPUT
Override the configured state_output value for minion
output. One of 'full', 'terse', 'mixed', 'changes' or
'filter'. Default: 'none'.
--state-verbose=STATE_VERBOSE, --state_verbose=STATE_VERBOSE
Override the configured state_verbose value for minion
output. Set to True or False. Default: none.
Actions:
-l ARG, --list=ARG List the public keys. The args 'pre', 'un', and
'unaccepted' will list unaccepted/unsigned keys. 'acc'
or 'accepted' will list accepted/signed keys. 'rej' or
'rejected' will list rejected keys. 'den' or 'denied'
will list denied keys. Finally, 'all' will list all
keys.
-L, --list-all List all public keys. Deprecated: use "--list all".
-a ACCEPT, --accept=ACCEPT
Accept the specified public key (use --include-
rejected and --include-denied to match rejected and
denied keys in addition to pending keys). Globs are
supported.
-A, --accept-all Accept all pending keys.
-r REJECT, --reject=REJECT
Reject the specified public key. Use --include-
accepted and --include-denied to match accepted and
denied keys in addition to pending keys. Globs are
supported.
-R, --reject-all Reject all pending keys.
--include-all Include rejected/accepted keys when
accepting/rejecting. Deprecated: use "--include-
rejected" and "--include-accepted".
--include-accepted Include accepted keys when rejecting.
--include-rejected Include rejected keys when accepting.
--include-denied Include denied keys when accepting/rejecting.
-p PRINT, --print=PRINT
Print the specified public key.
-P, --print-all Print all public keys.
-d DELETE, --delete=DELETE
Delete the specified key. Globs are supported.
-D, --delete-all Delete all keys.
-f FINGER, --finger=FINGER
Print the specified key's fingerprint.
-F, --finger-all Print all keys' fingerprints.
Key Generation Options:
--gen-keys=GEN_KEYS
Set a name to generate a keypair for use with salt.
--gen-keys-dir=GEN_KEYS_DIR
Set the directory to save the generated keypair, only
works with "gen_keys_dir" option. Default: '.'.
--keysize=KEYSIZE Set the keysize for the generated key, only works with
the "--gen-keys" option, the key size must be 2048 or
higher, otherwise it will be rounded up to 2048.
Default: 2048.
--gen-signature Create a signature file of the masters public-key
named master_pubkey_signature. The signature can be
send to a minion in the masters auth-reply and enables
the minion to verify the masters public-key
cryptographically. This requires a new signing-key-
pair which can be auto-created with the --auto-create
parameter.
--priv=PRIV The private-key file to create a signature with.
--signature-path=SIGNATURE_PATH
The path where the signature file should be written.
--pub=PUB The public-key file to create a signature for.
--auto-create Auto-create a signing key-pair if it does not yet
exist.
You can find additional help about salt-key issuing "man salt-key" or on
http://docs.saltstack.com
[root@server1 salt]# Salt-key-A//Allows all links
The following keys are going to be accepted:
Unaccepted Keys:
server2
Proceed? [n/Y] Y
Key for minion server2 accepted.
[root@server1 salt]# Sal-key-L// At this point the key exchange is successful
Accepted Keys:
server2
Denied Keys:
Unaccepted Keys:
Rejected Keys:
//salt-minion needs to be deleted from / etc/salyminion_id and reloaded when the host name is changed because the minion_id content is the host name generated at the first boot.
3.5 View Key
//server1:
[root@server1 salt]# cd pki/master/
[root@server1 master]# md5sum master.pub
660f7f951fc03b392355169fbb2a0119 master.pub //secret key
//Server2:
[root@server2 salt]# cd pki/minion/
[root@server2 minion]# md5sum minion_master.pub
660f7f951fc03b392355169fbb2a0119 minion_master.pub
3.6 View Port Running
[root@server1 master]# lsof -i :4505
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
salt-mast 1800 root 16u IPv4 14512 0t0 TCP server1:4505 (LISTEN)
salt-mast 1800 root 18u IPv4 17279 0t0 TCP server1:4505->server2:53946 (ESTABLISHED)
[root@server1 master]# lsof -i :4506
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
salt-mast 1807 root 24u IPv4 14523 0t0 TCP server1:4506 (LISTEN)
// View the python port process
[root@server1 master]# yum install python-setproctitle.x86_64 -y
[root@server1 master]# /etc/init.d/salt-master restart
Stoppingsalt-master daemon: [ OK ]
Starting salt-master daemon: [ OK ]
3.7 Testing salt Service
[root@server1 master]# salt '*' test.ping
server2:
True
[root@server1 master]# salt '*' cmd.run hostname //Execute the hostname command on all salt-minion hosts
server2:
server2
// Run "df-h" on server 2
4. salt Management System Installs httpd and php with rpm
Three Rules of YAML Grammar in Saltstack
YAML grammar rule 1: indentation
YAML uses a fixed indentation style to represent data layer structure relationships, and Saltstack requires that each indentation level be composed of two spaces. You must not use the tab key.
Rule 2: Colon
YAML: mykey: my_value must have a space after each colon (no space is required at the end of the colon, and no space is required for templates representing file paths)
Rule 3: Short horizontal lines
To represent a list item, use a short bar with a space. Multiple items use the same indentation level as part of the same list.
eg: my_dictionary:
- list_value_one
- list_value_two
- list_value_three
4.1 Open File System Server:
[root@server1 master]# vim /etc/salt/master //Opening the base environment depends on the main entry file
534 file_roots:
535 base:
536 - /srv/salt
4.2 Write deployment scripts and push
[root@server1 master]# ls /srv
[root@server1 master]# mkdir /srv/salt
[root@server1 master]# /etc/init.d/salt-master restart
[root@server1 master]# cd /srv/salt/
[root@server1 salt]# mkdir httpd //Configure http and php in this directory
[root@server1 salt]# cd httpd
[root@server1 httpd]# vim apache.sls //Deployment script
apache-install:
pkg.installed:
- pkgs:
- httpd
- php
//Test, execute push
[root@server1 httpd]# salt server2 state.sls httpd.apache test=true
/ / push
4.3 Server2 View Installation
[root@server2 minion]# rpm -q httpd php //Success
httpd-2.2.15-29.el6_4.x86_64
php-5.3.3-26.el6.x86_64