Target minions for learning saltstack (2)

Tag: Target saltstack nodegroup Grains

Next to the previous article, we will explain the detailed usage of each classification method of target.

> Grains

First, it should be noted that the grains information of minion will be generated and loaded at minion startup, and then will exist in the form of static data.

Grains matching has been mentioned previously. The implementation principle is to read the grains dict data and then match with the TGT string. Of course, it supports the nested key-value format, such:

salt -G ‘ec2_tags:environment:*production*‘ test.ping -v

The preceding Command finds the environment key corresponding to the ec2_tags grain data of grains, and the value contains all minion of the production.

For the source code for collecting grains data by default, see salt grains core. py.

Because salt's default static grains data coverage is insufficient, we can do some customized grains to meet business needs.

• /Etc/salt/grains or/etc/salt/Minion. d/XX. conf (create grains on the minion side)

roles:  - webserver  - memcachedeployment: datacenter4  cabinet: 13  cab_u: 14-15

• /Srv/salt/_ grains/(distributed to various minion on the master end)

# Collect. py #! PY # The returned result is a dict, in the key-value form # And then through salt '*' saltutil. sync_grains distribution def run (): Return {"test_data": "Yeah"} Run ()

Note that the above two types of grains have their own application scenarios. The former can be a specific small number of minion configuration independent grains data to facilitate target creation, for example, you can temporarily tag a cluster to quickly locate and deploy the cluster.Minion end. The py script placed in the following _ grains is completely custom grains, in order to add additional grains data in a unified manner, such as some business differentiation information.Master endDeployment, and then distributed to various minion.

> Group

As mentioned above, we can define a node group to classify minion into different groups. For example, the telecom data center is classified into one group, and the UNICOM data center is classified into another group (how can we achieve this? You can use custom grains !)

The method of using node group described in the official document is a bit pitfall. It takes effect only after the configuration file is written to the master (you also need to restart salt-Master !!). However, after reading the blog of Jack green manure, I suddenly became very cheerful. "It's good to have a big cow! ".

In fact, you can go to/etc/salt/master. d/nodegroups. the conf file (new if not found) writes related content. Accordingly, the salt-master can identify the corresponding group information by default! The following is a simple example of nodegroups. conf:

nodegroups:    test1: ‘[email protected]*‘      test2: ‘[email protected],salt02‘      test: ‘[email protected] or [email protected]’

Try itsalt -N test test.ping -vRight! You will get the desired answer!

For groups, I personally think that the corresponding information of each minion should be fully defined (the most important data should be grains data) and then written into the nodegroups. conf file. Grouping can be divided by business, server category, OS, and other dimensions, which will greatly facilitate subsequent deployment and maintenance!

Refer:
Salt official website and green fat god blog

My blog: http://devopstarter.info/saltstack-xue-xi-zhi-target-minionser/

This article is from "Love blog" blog, please be sure to keep this source http://jackywu.blog.51cto.com/3011457/1434913