Saltstack automated O & M artifacts (2)

File synchronization:

In fact, it is very complicated to synchronize some files during the O & M of openstack. There is a configuration item or a source code file for synchronization. Now we will introduce the file synchronization function of saltstack.

 

Environment Description: operating system version: rhel6.5x64

 

1. Configure the synchronization root directory for the master

Before starting the Configuration Management of saltstack, you must specify the root directory of all State files of saltstack and perform the following operations on the master.

# First, modify the configuration file of the master and specify the root directory. Note that the indentation uses two spaces instead of the tab (Python Specification) # determine whether the specified directory exists. If not, you need to manually create a directory

[[email protected] ~]# vim /etc/salt/master  file_roots:   base:     - /srv/salt   dev:     - /srv/salt/dev/[[email protected] ~]# mkdir -p /srv/salt/dev[[email protected] ~]# ls -ld /srv/salt/devdrwxr-xr-x 2 root root 4096 Feb  3 21:49 /srv/salt/dev

Restart the master service

[[email protected] ~]# service salt-master restartStopping salt-master daemon:                               [  OK  ]Starting salt-master daemon:                               [  OK  ]

2. Introduction to CP. get_file

First, we will introduce CP. get_file, which is used to download files from the master to the specified directory of minion.

# Create a test file on the master

[[email protected] ~]# echo ‘This is test file with saltstack module to  cp.get_file‘ >/opt/getfile.txt          [[email protected] ~]# cat /opt/getfile.txt  This is test file with saltstack module to  cp.get_file

Copy the file to the synchronization root directory of the master.

[[email protected] ~]# cp /opt/getfile.txt /srv/salt/

Execute file delivery on Master

[[email protected] ~]# salt ‘computer3‘ cp.get_file salt://getfile.txt /tmp/getfile.txt   computer3:     /tmp/getfile.txt

Log on to computer3 to view synchronization information.

[[email protected] ~]# cat /tmp/getfile.txt  This is test file with saltstack module to  cp.get_file

 

Attributes of the distribution file:

(1) Compressed Gzip

Use gzip to compress. The larger the number, the higher the compression ratio. 9 indicates the maximum compression ratio.

[[email protected]ontroller1 ~]# salt ‘computer8‘ cp.get_file salt://getfile.txt /tmp/getfile.txt gzip=9computer8:     /tmp/getfile.txt

 

(2) create directory makedirs (this directory is automatically created when the distribution location does not exist on the target host)

[[email protected] ~]# salt ‘computer8‘ cp.get_file salt://getfile.txt /tmp/srv/getfile.txt makedirs=Truecomputer8:     /tmp/srv/getfile.txt[[email protected] opt]# ll /tmp/srv/getfile.txt  -rw-r--r-- 1 root root 56 Feb  3 22:14 /tmp/srv/getfile.txt

3. Grains

First, we will introduce grains. This interface is used to call the minion service at the minion end to collect information on the minion end. This information data can be directly used in other modules of salt, note that this interface is called only once when the minion service on the minion end is started, so the collected data is static and will not change unless you restart the minion service.

 

Basic usage of grains:

[[email protected] ~]# salt ‘computer3‘ grains.lscomputer3:     - biosreleasedate     - biosversion     - cpu_flags     - cpu_model     - cpuarch     - defaultencoding     - defaultlanguage     - domain     - fqdn     - fqdn_ip4     - fqdn_ip6     - gpus     - host     - hwaddr_interfaces     - id     - ip_interfaces     - ipv4     - ipv6     - kernel     - kernelrelease     - localhost     - manufacturer     - master     - mem_total     - nodename     - num_cpus     - num_gpus     - os     - os_family     - osarch     - oscodename     - osfinger     - osfullname     - osmajorrelease     - osrelease     - path     - productname     - ps     - pythonpath     - pythonversion     - saltpath     - saltversion     - saltversioninfo     - serialnumber     - server_id     - shell     - virtual     - zmqversion

 

Use the grains. Items module to list the specific data of all available Grains

[[email protected] ~]# salt ‘computer3‘ grains.itemscomputer3:   biosreleasedate: 08/28/2013   biosversion: 2.10.0   cpu_flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt aes lahf_lm arat dts tpr_shadow vnmi flexpriority ept vpid   cpu_model: Intel(R) Xeon(R) CPU E7- 4820  @ 2.00GHz   cpuarch: x86_64   defaultencoding: UTF8   defaultlanguage: en_US   domain:    fqdn: computer3   fqdn_ip4:       192.168.100.23   fqdn_ip6:   gpus:       {‘model‘: ‘MGA G200eW WPCM450‘, ‘vendor‘: ‘unknown‘}   host: computer3   hwaddr_interfaces: {‘lo‘: ‘00:00:00:00:00:00‘, ‘tap002cf093-0c‘: ‘fe:16:3e:cf:43:28‘, ‘em4‘: ‘f0:1f:af:90:38:65‘, ‘eth1.2‘: ‘f0:1f:af:90:37:fd‘, ‘em3‘: ‘f0:1f:af:90:38:63‘, ‘brq8f15ee7f-54‘: ‘f0:1f:af:90:37:fd‘, ‘brqadf94242-74‘: ‘f0:1f:af:90:37:fd‘, ‘eth1.400‘: ‘f0:1f:af:90:37:fd‘, ‘eth1‘: ‘f0:1f:af:90:37:fd‘, ‘eth0‘: ‘f0:1f:af:90:37:fb‘}   id: computer3   ip_interfaces: {‘lo‘: [‘127.0.0.1‘], ‘tap002cf093-0c‘: [], ‘em4‘: [], ‘eth1.2‘: [], ‘em3‘: [], ‘brq8f15ee7f-54‘: [], ‘brqadf94242-74‘: [], ‘eth1.400‘: [], ‘eth1‘: [], ‘eth0‘: [‘192.168.100.23‘]}   ipv4:       127.0.0.1       192.168.100.23   ipv6:       ::1       fe80::60f7:96ff:feab:3d44       fe80::f21f:afff:fe90:37fb       fe80::f21f:afff:fe90:37fd       fe80::f8e7:cdff:fe54:7d02       fe80::fc16:3eff:fecf:4328   kernel: Linux   kernelrelease: 2.6.32-431.el6.x86_64   localhost: computer3   manufacturer: Dell Inc.   master: 192.168.100.200   mem_total: 225995   nodename: computer3   num_cpus: 64   num_gpus: 1   os: RedHat   os_family: RedHat   osarch: x86_64   oscodename: Santiago   osfinger: Red Hat Enterprise Linux Server-6   osfullname: Red Hat Enterprise Linux Server   osmajorrelease:       6       5   osrelease: 6.5   path: /sbin:/usr/sbin:/bin:/usr/bin   productname: PowerEdge M910   ps: ps -efH   pythonpath:       /usr/bin       /usr/lib64/python26.zip       /usr/lib64/python2.6       /usr/lib64/python2.6/plat-linux2       /usr/lib64/python2.6/lib-tk       /usr/lib64/python2.6/lib-old       /usr/lib64/python2.6/lib-dynload       /usr/lib64/python2.6/site-packages       /usr/lib64/python2.6/site-packages/gtk-2.0       /usr/lib/python2.6/site-packages       /usr/lib/python2.6/site-packages/setuptools-0.6c11-py2.6.egg-info   pythonversion: 2.6.6.final.0   saltpath: /usr/lib/python2.6/site-packages/salt   saltversion: 2014.1.10   saltversioninfo:       2014       1       10       0   serialnumber: XXXXXX   server_id: 111111111   shell: /bin/bash   virtual: physical   zmqversion: 4.0.5

 

Ping the host whose OS value is RedHat in grains to test whether the communication is normal.

[[email protected] ~]# salt -G ‘os:RedHat‘ test.ping  computer5:     Truecomputer8:     Truecomputer6:     Truecomputer7:     Truecomputer4:     Truecomputer3:     True

 

View the IP address of the uadoop2 host. Note that this is not items, but item

[[email protected] ~]# salt ‘*‘ grains.item ipv4computer5:   ipv4:       127.0.0.1       192.168.100.25computer7:   ipv4:       127.0.0.1       192.168.100.27computer4:   ipv4:       127.0.0.1       192.168.100.24computer3:   ipv4:       127.0.0.1       192.168.100.23computer8:   ipv4:       127.0.0.1       192.168.100.28computer6:   ipv4:       127.0.0.1       192.168.100.26

 

Now, after introducing the grains interface, let's take a look at how to use grains data in the CP module.

Determine the OS version first

[[email protected] RedHat]# salt ‘computer4‘  grains.item os          computer4:   os: RedHat

[[email protected] ~]# mkdir /srv/salt/RedHat/[[email protected] ~]# mv /srv/salt/getfile.txt  /srv/salt/RedHat/[[email protected] RedHat]# salt ‘computer4‘ cp.get_file "salt://{{grains.os}}/getfile.txt" /opt/getfile.txt template=jinjacomputer4:     /opt/getfile.txt

4. directory synchronization
The usage of CP. get_dir, get_dir, and get_file is very similar. It is used to distribute the entire directory to minions.

Create a test file

[[email protected] ~]# mkdir /srv/salt/test_dir[[email protected] ~]# echo ‘hello word !!‘ >>/srv/salt/test_dir/hello1.txt[[email protected] ~]# echo ‘hello2 word !!‘ >>/srv/salt/test_dir/hello2.txt[[email protected] ~]# ll /srv/salt/test_dir/total 8-rw-r--r-- 1 root root 14 Feb  4 14:49 hello1.txt-rw-r--r-- 1 root root 15 Feb  4 14:49 hello2.txt

Test distribution: Execute distribution of directory files and use compressed Transmission

[[Email protected] ~] # Salt 'computer4' CP. get_dir salt: // test_dir/tmp gzip = 9 computer4:-/tmp/test_dir/hello1.txt-/tmp/test_dir/hello2.txt log on to the target node to view the distribution status: [[email protected] ~] # Ll/tmp/test_dir/total 8-rw-r -- r -- 1 Root 14 Feb 4 hello1.txt-RW-r -- 1 Root 15 Feb 4 hello2.txt

 

5. Flexible Data Change

 

Before proceeding, let's first introduce the pillar interface of salt. pillar is an important component of salt, which is similar to grains, but pillar is more flexible and dynamic than grains, data can be updated at any time, as long as you wish. Grains only collects data once when Minion is started. The pillar official website is described as follows. It is a simple translation, but it is not guaranteed that the translation is in place, this means that pillar is the most important component for implementing the deployment function of salt. It can generate flexible data for minions, which can be used by other components of salt.

   The pillar interface inside of Salt is one of the most important components of a Salt deployment. Pillar is the interface used to generate arbitrary data for specific minions. The data generated in pillar is made available to almost every component of Salt.

Grains basic usage

(1) configure the master

[[Email protected] ~] # Vim/etc/salt/Master pillar_roots: Base:-/srv/pillar [[email protected] ~] # Service salt-master restartstopping salt-master daemon: [OK] Starting salt-master daemon: [OK] [[email protected] ~] # Mkdir/srv/pillar [[email protected] ~] # Mkdir/srv/pillar/user // create a user test directory

(2) create an entry file

First, you must have an entry file top. SLS in the/srv/pillar directory.

[[Email protected] pillar] # Cat top. slS base: 'computer3':-date # defines an attribute data for uadoop2 and references it with top. SLS is in the same directory as data. slS 'computer4':-webserver # defines an attribute data for uadoop3 and references it with top. the web. slS '*':-user # defines an attribute data for all nodes and References/srv/pillar/user/init. slS # the directory is specified here, and salt will automatically be in the top. search for the status file in the Reference Directory of the SLS file # The init. slS file # do not have any '#' During the test. Write the other two attributes: [email protected] pillar] # Cat date. slS Date: Some date [[email protected] pillar] # Cat webserver. slS webserver: test_dir

Test:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

To be continued .....

Saltstack automated O & M artifacts (2)