SaltStack Mine - how to manage and use data changes in those grains

THE SALT MINE

Salt Mine used to collect arbitrary data from Minions and stored on the Master. Then salt.modules.mineblock all data available to all Minions.

Mine data collected on Minion and sent back to the Master, which maintains only those most recent data (if need long-term historical data is recommended returners or external job buffers).

Simply put, Salt Mine is to manage those opportunities to update or grains of high frequency data. Common sense, grains minions data is static data, from creation to basically disappear, are unlikely to change. But things will always be some exceptions, such systems sometimes need to adjust some ip address minions node according to needs, we hope this information can be quickly entered into force and that the use of state administrative commands or states that information can also be early using data on update. Salt Mine can be said that such a scenario is designed, of course, in addition to effectiveness considerations, but also take into account the needs of performance.
And when there are some grains used in the data we need to have a larger chance of change, we use the Salt Mine to manage them.

Salt Mine can also understand this data through the use of knowledge on github: at The Salt Mine

MINE VS GRAINS

Designed to Mine data is intended to be more than a grain timely data updates. Grains in a very limited basis on updates, but mainly static data. When the Minions Minions of other data required from, Mines designed to replace the slow release of the peer call. No longer let all other Minion Minions get a contact data, collected by the Salt Mine but running on the Master from all Minions in each Mine Interval it produces more fresh data at any given time, while reducing overhead.

MINE FUNCTIONS

To enable Salt Mine, you will need mine_functionsoptions to Minion. This option can Minion Minion configuration file or application of Pillar. mine_functionsOptions indicator function is being executed, and allows incoming parameters. salt.moduleIt provides a list of functions. If no parameter, you must add an empty list, the following Examples test.pingfunction shown:

mine_functions:
  test.ping: []
  network.ip_addrs:
    interface: eth0
    cidr: '10.0.0.0/8'

In the example above, salt.modules.network.ip_addrswith additional filters to help narrow down the results. In the above example, only when the IP address is the IP interface eth0 and 10.0.0.0/8 range, it will return the IP address.

MINE FUNCTIONS ALIASES

Function Aliases can be used to provide a more friendly name, intended use or allow the use of different parameters multiple calls to the same function. Delivery location and key parameters have different syntax. It does not support mixing position and key parameters.

New in version 2014.7.0.

mine_functions:
  network.ip_addrs: [eth0]
  networkplus.internal_ip_addrs: []
  internal_ip_addrs:
    mine_function: network.ip_addrs
    cidr: 192.168.0.0/16
  ip_list:
    - mine_function: grains.get
    - ip_interfaces

MINE INTERVAL

Salt Mine Minion functions performed at startup by the scheduler at given intervals. The default interval is every 60 minutes, by minion configuration mine_intervaloptions for adjustment Minion:

mine_interval: 60

MINE IN SALT-SSH

From 2015.5.0 version, salt-ssh support mine.getfunctions.

Because Minions can not provide their own mine_functionsconfiguration, so we args specified in one of three local mine retrieval function, search the following order:

  1. Roster data
  2. Pillar
  3. Master config

mine_functionsPositions different formats common salt in exactly the same format, but stored. The following is included mine_functionsexamples roster lists of:

test:
  host: 104.237.131.248
  user: root
  mine_functions:
    cmd.run: ['echo "hello!"']
    network.ip_addrs:
      interface: eth0

Note: Due to different salt-ssh architecture, mine.getcalling some low efficiency. Salt must be a new salt-ssh calls to each Minions related to retrieve the requested data, released just calling the same. However, unlike publish different, it must be requested function is run as a wrapper function, so we can retrieve related functions args from pillar Minion's. This results in a significant delay to retrieve the requested data.

MINIONS TARGETING WITH MINE

mine.getMinions function supports various targeting methods to obtain Mine data from a particular host, for example, on a glob Minion id (name), grain, pillars and composite matching or regular expression matching. See salt.modules.mine module documentation for reference.

Note: Pillar need to cache data on the Master, for use with the positioning pillar Mine binding. Read comments relevant chapter .

example

Mine A method for use in a data file status state. These values ​​can be retrieved and used by Jinja SLS file. The following example is part HAProxy profile, and extracts the IP address from all Minions with "web" grain size in order to add them to the load balancing server pool.

/srv/pillar/top.sls:

base:
  'G@roles:web':
    - web

/srv/pillar/web.sls:

mine_functions:
  network.ip_addrs: [eth0]

The next trigger minions refresh pillar data:

salt '*' saltutil.refresh_pillar

By performing the following operations and check the output of the network.ip_addrsverification result is displayed in the pillar minions of:

salt '*' pillar.items

We can see that the returned results to be displayed on the Mine Minion function exists, but the actual value does not include an output:

minion1.example.com:
    ----------
    mine_functions:
        ----------
        network.ip_addrs:
            - eth0

Mine data is generally updated every 60 minutes only once in the master, which may be modified by providing:

/etc/salt/minion.d/mine.conf:

mine_interval: 5

Mine data manually force a refresh immediately:

salt '*' mine.update

In /srv/salt/haproxy.slsconfigure a salt.states.file.managedstatus:

haproxy_config:
  file.managed:
    - name: /etc/haproxy/config
    - source: salt://haproxy_config
    - template: jinja

Create a Jinja template file /srv/salt/haproxy_config:

<...file contents snipped...>

{% for server, addrs in salt['mine.get']('roles:web', 'network.ip_addrs', tgt_type='grain') | dictsort() %}
server {{ server }} {{ addrs[0] }}:80 check
{% endfor %}

<...file contents snipped...>

In the above example, serverit will be replaced by minion_id.

NOTE: In version 2017.7.0 in Salt, expr_form parameter will be renamed tgt_type.

Guess you like

Origin blog.csdn.net/watermelonbig/article/details/91353767