Pillar in saltstack

Pillar in Salt

Basic Introduction

In saltstack, pillar serves as the interface for defining minion global data. by default, it is stored on the master end. When Minion is started, it connects to the master to obtain the latest pillar data. pillar uses a structure similar to the State Tree. By default, yaml is used as its description format and is eventually converted into a python dictionary within minion.

How does pillar work in salt? In what situations do I need to perform the refresh pillar operation first? But what does not need it?

This article is based on Salt 2014.1.4

Pillar in the configuration file

Pillar_roots

It exists in the master/minion configuration file. specifies the directory of the environment corresponding to pillar roots. Its layout is similar to the State Tree. configure this option in the minion configuration file. This option takes effect only when file_client is set to local.

State_top

Exists in the master/minion configuration file. The default value is top. SLS. the official description is for state system, which is used to tell minion which environment is used and which modules need to be executed. in fact, this option is also applied to the pillar system, which is similar to the state system. therefore, if this option is changed, the top of the pillar system. slS also needs to be changed. configure this option in the minion configuration file. This option takes effect only when file_client is set to local.

File_client

It exists in the minion configuration file. The default value is remote. It is used to specify where to find the file. The valid values are remote and local. Remote, indicating that the master is used, and local is used for masterless.

Pillar_opts

Exists in the master configuration file. The default value is true. specifies whether to use the master configuration option as pillar. if this option is set to true, you must restart the master to obtain the latest value in pillar when the master configuration option is modified.

Pillar implementation in minion

In Minion, pillar is a python dictionary. When Minion is started, it connects to the master to obtain the latest pillar data by default and is stored in self. opts ['pillar ']. The corresponding code is as follows:

Class minion (minionbase ):

'''

This class instantiates a minion, runs connections for a minion,

And loads all of the functions into the minion

'''

Def _ init _ (self, opts, timeout = 60, safe = true ):

'''

Pass in the options dict

'''

......

Self. opts ['pillar '] = salt. Pillar. get_pillar (

Opts,

Opts ['grains'],

Opts ['id'],

Opts ['enable'],

). Compile_pillar ()

......

So how does salt. Pillar. get_pillar work? The Code is as follows:

Def get_pillar (OPTs, grains, ID _, saltenv = none, ext = none, ENV = none ):

'''

Return the correct pillar Driver Based on the file_client Option

'''

If env is not none:

Salt. utils. warn_until (

'Boron ',

'Passing a Salt Environment shoshould be done using \ 'saltenv \''

'Not \ 'env \ '. This functionality will be removed in salt boron .'

)

# Backwards compatibility

Saltenv = env

Return {

'Remotepillar,

'Local': pillar

}. Get (OPTs ['file _ client'], pillar) (OPTs, grains, ID _, saltenv, ext)

You can also know from the code that the file_client value will be obtained from opts. If it is remote, the corresponding object will be remotepillar. If it is local, it will be pillar for subsequent processing.

If the command received by minion starts with the refresh_pillar string during running, execute the pillar_refresh operation. The corresponding code is as follows:

If package. startswith ('module _ refresh '):

Self. module_refresh ()

Elif package. startswith ('pillar _ refresh '):

Self. pillar_refresh ()

So what does pillar_refresh () do? The Code is as follows:

Def pillar_refresh (Self ):

'''

Refresh the pillar

'''

Self. opts ['pillar '] = salt. Pillar. get_pillar (

Self. opts,

Self. opts ['grains'],

Self. opts ['id'],

Self. opts ['enable'],

). Compile_pillar ()

Self. module_refresh ()

It is learned from the code that the pillar_refresh operation will not only obtain the latest pillar information locally from the master/Minion, but also execute the module refresh (module_refresh. you can adjust the minion local log level to TRAC and then execute saltutil. refresh_pillar operation, then observe the minion log, whether the module will be refreshed for verification.

Pillar in target

The underlying network for sending the salt command adopts the zeromq pub/sub structure. minion listens to the sub interface, and the master sends the command to the local pub interface, and all minion receives the command, then, in Minion, determine whether you need to execute the command (target) locally ). in the current version, pillar is supported as the target (specified through the "-I" option ). the Code is as follows:

Def pillar_match (self, TGT, delim = ':'):

'''

Reads in the pillar glob match

'''

Log. debug ('pillar target: {0} '. Format (TGT ))

If delim not in TGT:

Log. Error ('got insufficient arguments for pillar Match'

'Statement from master ')

Return false

Return salt. utils. subdict_match (self. opts ['pillar '], TGT, delim = delim)

We can see that self is used for matching. opts ['pillar '] indicates the data of Pillar in the current minion memory. therefore, if you want to use the latest pillar to perform the target operation after modifying the pillar data in the master/minion (when file_client is local), you need to manually execute saltutil before execution. refresh_pillar operation to refresh the pillar data in the minion memory.

Pillar in the remote execution module

Pillar. Items

The Code is as follows:

Pillar = salt. Pillar. get_pillar (

_ Opts __,

_ Grains __,

_ Opts _ ['id'],

_ Opts _ ['enable'])

Return pillar. compile_pillar ()

Connect master/minion (when file_client is local) to obtain the latest pillar data and return it. but it does not refresh the minion local cache. that is to say, modify the pillar tree on the master end and refresh the pillar (saltutil. refresh_pillar), you can use Pillar first. items to verify whether the data meets expectations.

Pillar. Data

The Code is as follows:

Data = items

Only a value reference is created, and the same value is specified for data and items execution.

Pillar. Item

The Code is as follows:

Ret = {}

Pillar = items ()

For ARG in ARGs:

Try:

RET [Arg] = pillar [Arg]

Failed t keyerror:

Pass

Return ret

Use pillar. items to obtain the latest pillar data on the master. Then, use a for loop to obtain the value of the required keys from items. Therefore, item can query multiple keys.

Pillar. Raw

The Code is as follows:

If key:

Ret = _ pillar _. Get (Key ,{})

Else:

Ret = _ pillar __

Return ret

Obtain _ pillar _ (self. opts [pillar]) value. that is to say, use pillar. raw and pillar. different from items, the pillar value in the minion memory is obtained, not the value defined by the master. if the key is specified, the value of the corresponding key is returned. if no, the entire _ pillar _ is returned __

Pillar. Get

The Code is as follows:

Return salt. utils. traverse_dict (_ pillar __, key, default)

And pillar. raw works in a similar way. It is a value from _ pillar _ and is used to obtain the corresponding key value of pillar. and pillar. the difference between raw keys is that get recursively obtains the value of the embedded Dictionary (separated by ":" by default ). from the latest develop branch, the Merge function will be added in the next version (helium.

Pillar. ext

Similar to how pillar. Items works, it is used to obtain the value of ext pillar.

Saltutil. refresh_pillar

The Code is as follows:

_ Salt _ ['event. fire'] ({}, 'pillar _ refresh ')

A pillar_refresh event is generated on the minion local event interface. Previously, in the pillar of Minion, Minion listens to the local event interface locally. If the command starting with pillar_refresh is captured, the local pillar is refreshed.

Pillar in configuration management

Use pillar in SLS

In SLS, you can directly use pillar. For example, pillar ['pkg '], which directly uses the pillar value (self. opts ['pillar']) in the current memory of minion.

State. SLS & State. highstate

Put these two remote execution module methods into configuration management, because they are used to send configuration management commands to minions.

State. SLS and state. highstate are both salt. state. highstate objects in the Code. During execution, the State object. State class refreshes pillar during instantiation. The corresponding code is as follows:

Class state (object ):

'''

Class used to execute salt states

'''

Def _ init _ (self, opts, pillar = none, jid = none ):

If 'logins' not in opts:

Opts ['logins'] = salt. loader. grains (OPTs)

Self. opts = opts

Self. _ pillar_override = pillar

Self. opts ['pillar '] = self. _ gather_pillar ()

The code for _ gather_pillar is as follows:

Def _ gather_pillar (Self ):

'''

Whenever a State run starts, gather the pillar data fresh

'''

Pillar = salt. Pillar. get_pillar (

Self. opts,

Self. opts ['grains'],

Self. opts ['id'],

Self. opts ['enable'],

)

Ret = pillar. compile_pillar ()

If self. _ pillar_override and isinstance (self. _ pillar_override, dict ):

Ret. Update (self. _ pillar_override)

Return ret

_ Gather_pillar: obtain the latest pillar data corresponding to minion from the master, and self in the _ init _ method. opts ['pillar '] = self. _ gather_pillar () assigns the value to self. opts ['pillar '] to refresh the pillar data in the minion local memory. this is why the pillar value on the master is modified without performing the refresh operation (saltutil. refresh_pillar), because the state is being executed. highstate and state. slS will automatically display the latest value.

Ext_pillar

Salt supports obtaining pillar information from a third-party system, making it easy to integrate with existing CMDB systems. the corresponding configuration is the ext_pillar option in the master configuration file. the official website has provided several drivers.

If the provided driver does not meet the requirements, the custom ext_pillar driver is also very simple. you only need to place the driver file in the pillar directory of the salt code on the master end. The driver is Python code, which contains the ext_pillar function. The first parameter of this function is minion_id, and the second parameter is pillar, the returned value is a standard Python dictionary. you can refer to the cobbler's ext_pillar for compiling.

Posted on: 2014-06-08

Category: saltstack-tags: saltstack, pillar

Pengyao. built using pelican. Theme by Giulio fidente on GitHub ..

This article is from the "davideylee" blog and will not be reposted!

Pillar in saltstack