What is grains
grains is one of the most important components of Saltstack. The function of grains is to collect basic information about the controlled host. These information are usually static data, including CPU, kernel, operating system, virtualization, etc., on the server side It can be flexibly customized based on this information, and the administrator can use this information to personalize settings for different businesses. Officially provided: grains are used to distinguish different minions for different configurations, and salt ' ' is mainly carried out in ' ' Match the role of the host.
The application scenario
is used in the state to configure the management module
Used in target to match minion, for example, to match the -G option used by the operating system
For information query, grains save the collected client details
The CentOS distribution host will be matched by "host: {{ grains['xxx'] }}". Take the host saltstack_web1group_1 (CentOS 6.5) as an example, and finally get "host: saltstack_web1group_1". At the same time, the command line matching operating system release version is CentOS and the controlled end can be filtered through the -G parameter.
[root@saltstack-master ~]# salt -G 'os:CentOS' test.ping
saltstack_web1group_1:
True
saltstack_web1group_2:
True
Common operation commands for grains
Match the minion with the kernel version 2.6.32-504.el6.x86_64 and execute the command'uname -a'
[root@saltstack-master ~]# salt -G 'kernelrelease:2.6.32-431.el6.x86_64' cmd.run 'uname -a'
saltstack_web1group_1:
Linux saltstack_web1group_1 2.6.32-431.el6.x86_64 #1 SMP Fri Nov 22 03:15:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
saltstack_web1group_2:
Linux saltstack_web1group_2 2.6.32-431.el6.x86_64 #1 SMP Fri Nov 22 03:15:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
Get the grain item information of all minion
[root@saltstack-master ~]# salt '*' grains.ls
saltstack_web1group_1:
- SSDs
- biosreleasedate
- biosversion
- cpu_flags
- cpu_model
- cpuarch
- domain
- fqdn
- fqdn_ip4
- fqdn_ip6
- gpus
- host
--------------忽略部分内容------------------Of course, you can also obtain individual grain data of the host, such as obtaining the operational release version.
[root@saltstack-master ~]# salt 'saltstack_web1group_1' grains.item os
saltstack_web1group_1:
----------
os:
CentOS
Define grain data
There are two ways to define grain data. One is to customize the configuration file in minion, and the other is to implement the master extension module API. The difference is that the module is more flexible and can be dynamically defined by Python programming, while the configuration file is only suitable for relative Fixed key and value.
[root@saltstack-master ~]# salt 'saltstack_web1group_1' grains.items
saltstack_web1group_1:
----------
SSDs:
biosreleasedate:
05/19/2017
biosversion:
6.00
cpu_flags:
- fpu
- vme
- de
--------------忽略部分内容------------------Customized grain data of the controlled end host
Log in to a controlled host (minion) via SSH, such as SN2013-08-022, the customized path of the configuration file is /etc/salt/minion, and the parameter is default_include:minion.d/*conf
Create a file [/etc/salt/minion.d/hostinfo.conf]
[root@saltstack_web1group_1 ~]# cd /etc/salt/minion.d/
[root@saltstack_web1group_1 minion.d]# vim hostinfo.conf
grains:
roles:
- webserver
- memcache
deployment: datacenter4
cabinet: 14
[root@saltstack_web1group_1 minion.d]# service salt-minion restart
Stopping salt-minion daemon: [确定]
Starting salt-minion daemon: [确定]
Restart the minion service and run the verification result on the master: salt'saltstack_web1group_1' grains.itemroles deployment cabinet, and observe the configured key and value.
[root@saltstack-master ~]# salt 'saltstack_web1group_1' grains.item roles deployment cabinet
saltstack_web1group_1:
----------
cabinet:
14
deployment:
datacenter4
roles:
- webserver
- memcache
Customized grain data for main control terminal expansion module
First, write Python code on the main control end, and then synchronize the Python file to the controlled end, and finally refresh to take effect (that is, compile the Python source code file into bytecode pyc). Create the _grains directory under the base directory of the master control terminal (see the file_roots item of the /etc/salt/master configuration file, the default base configuration is /srv/salt), execute install -d /srv/salt/_grains to start writing code, real-time Obtain the grain data of the maximum number of open files allowed by the controlled host system (ulimit -n).
[root@saltstack-master ~]# install -d /srv/salt/_grains
[root@saltstack-master ~]# cd /srv/salt/_grains
[root@saltstack-master _grains]# vim grains_openfile.py
#!/usr/bin/env python
# -*- coding:utf-8 -*-
import os,sys,commands
#定义一个获取最大打开文件数的函数，函数名称没有要求，符合python函数命名规则即可
def Grains_openfile():
'''
return os max open file of grains value
'''
grains = {} #初始化一个字典，变量名一定要用grains,以便Saltstack识别
_open_file=65535 #初始化一个默认值
try:
getulimit = commands.getstatusoutput('source /etc/profile;ulimit -n')
except Exception,e:
pass
if getulimit[0]==0:
_open_file=int(getulimit[1])
grains['max_open_file'] = _open_file #将获取的ulimit -n的结果进行赋值，其中'max_open_file'就是grains项，——open_file就是grains的值
return grains
grains_openfile() defines a function to obtain the maximum number of open files. There is no requirement on the function name, and it only needs to comply with the Python function naming rules.
grains={} initialize a grains dictionary, the variable name must use grains, so that saltstack can recognize
grains['max_open_file']=_open_file assigns the obtained Linux ulimit -n result value to grains['max_open_file'], where "max_open_file" is the item of grains, and _open_file is the value of grains.
Synchronization module on the host: salt'saltstack_web1group_1' saltutil.sync_grains or salt'saltstack_web1group_1' saltutil.sync_all, at this time the files have been synchronized to the directory below the host host.
[root@saltstack-master _grains]# salt 'saltstack_web1group_1' saltutil.sync_all
saltstack_web1group_1:
----------
beacons:
grains:
- grains.grains_openfile
modules:
output:
renderers:
returners:
sdb:
states:
utils:
[root@saltstack_web1group_1 minion.d]# ll /var/cache/salt/minion/extmods/grains/
总用量 4
-rw-------. 1 root root 774 3月 20 16:36 grains_openfile.py
[root@saltstack_web1group_1 minion.d]# ll /var/cache/salt/minion/files/base/_grains/
总用量 4
-rw-------. 1 root root 774 3月 20 16:36 grains_openfile.py
/var/cache/salt/minion/extmods/grains/
For the final storage location of the extension module file, the bytecode pyc will be generated under the same path after refreshing the module; /var/cache/salt/minion/files/base/_grains/ is the temporary storage location
Refresh module salt'saltstack_web1group_1' sys.reload_modules
A compiled bytecode file grains_openfile.py in the location of /var/cache/salt/minion/extmods/grains/ is a python executable format.
[root@saltstack-master _grains]# salt 'saltstack_web1group_1' sys.reload_modules
saltstack_web1group_1:
True
[root@saltstack_web1group_1 minion.d]# ll /var/cache/salt/minion/extmods/grains/
总用量 4
-rw-------. 1 root root 774 3月 20 16:36 grains_openfile.py
The verification result is that the grain information can be viewed on the main control terminal.
Execute salt'saltstack_web1group_1' grains.item max_open_file and the
result shows "max_open_file:65535", which is the host grains information customized earlier.
[root@saltstack-master _grains]# salt 'saltstack_web1group_1' grains.item max_open_file
saltstack_web1group_1:
----------
max_open_file: 65535