index.rst 8.3 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293
  1. .. _salt-mine:
  2. .. index:: ! Mine, Salt Mine
  3. =============
  4. The Salt Mine
  5. =============
  6. The Salt Mine is used to collect arbitrary data from Minions and store it on
  7. the Master. This data is then made available to all Minions via the
  8. :py:mod:`salt.modules.mine` module.
  9. Mine data is gathered on the Minion and sent back to the Master where only the
  10. most recent data is maintained (if long term data is required use returners or
  11. the external job cache).
  12. Mine vs Grains
  13. ==============
  14. Mine data is designed to be much more up-to-date than grain data. Grains are
  15. refreshed on a very limited basis and are largely static data. Mines are
  16. designed to replace slow peer publishing calls when Minions need data from
  17. other Minions. Rather than having a Minion reach out to all the other Minions
  18. for a piece of data, the Salt Mine, running on the Master, can collect it from
  19. all the Minions every :ref:`mine_interval`, resulting in
  20. almost fresh data at any given time, with much less overhead.
  21. Mine Functions
  22. ==============
  23. To enable the Salt Mine the ``mine_functions`` option needs to be applied to a
  24. Minion. This option can be applied via the Minion's configuration file, or the
  25. Minion's Pillar. The ``mine_functions`` option dictates what functions are
  26. being executed and allows for arguments to be passed in. The list of
  27. functions are available in the :py:mod:`salt.module`. If no arguments
  28. are passed, an empty list must be added like in the ``test.ping`` function in
  29. the example below:
  30. .. code-block:: yaml
  31. mine_functions:
  32. test.ping: []
  33. network.ip_addrs:
  34. interface: eth0
  35. cidr: 10.0.0.0/8
  36. In the example above :py:mod:`salt.modules.network.ip_addrs` has additional
  37. filters to help narrow down the results. In the above example IP addresses
  38. are only returned if they are on a eth0 interface and in the 10.0.0.0/8 IP
  39. range.
  40. .. versionchanged:: 3000
  41. The format to define mine_functions has been changed to allow the same format
  42. as used for module.run. The old format (above) will still be supported.
  43. .. code-block:: yaml
  44. mine_functions:
  45. test.ping: []
  46. network.ip_addrs:
  47. - interface: eth0
  48. - cidr: 10.0.0.0/8
  49. test.arg:
  50. - isn't
  51. - this
  52. - fun
  53. - this: that
  54. - salt: stack
  55. .. _mine_minion-side-acl:
  56. Minion-side Access Control
  57. --------------------------
  58. .. versionadded:: 3000
  59. Mine functions can be targeted to only be available to specific minions. This
  60. uses the same targeting parameters as :ref:`targeting` but with keywords ``allow_tgt``
  61. and ``allow_tgt_type``. When a minion requests a function from the salt mine that
  62. is not allowed to be requested by that minion (i.e. when looking up the combination
  63. of ``allow_tgt`` and ``allow_tgt_type`` and the requesting minion is not in the list)
  64. it will get no data, just as if the requested function is not present in the salt mine.
  65. .. code-block:: yaml
  66. mine_functions:
  67. network.ip_addrs:
  68. - interface: eth0
  69. - cidr: 10.0.0.0/8
  70. - allow_tgt: 'G@role:master'
  71. - allow_tgt_type: 'compound'
  72. Mine Functions Aliases
  73. ----------------------
  74. Function aliases can be used to provide friendly names, usage intentions or to
  75. allow multiple calls of the same function with different arguments. There is a
  76. different syntax for passing positional and key-value arguments. Mixing
  77. positional and key-value arguments is not supported.
  78. .. versionadded:: 2014.7.0
  79. .. code-block:: yaml
  80. mine_functions:
  81. network.ip_addrs: [eth0]
  82. networkplus.internal_ip_addrs: []
  83. internal_ip_addrs:
  84. mine_function: network.ip_addrs
  85. cidr: 192.168.0.0/16
  86. ip_list:
  87. - mine_function: grains.get
  88. - ip_interfaces
  89. .. versionchanged:: 3000
  90. With the addition of the module.run-like format for defining mine_functions, the
  91. method of adding aliases remains similar. Just add a ``mine_function`` kwarg with
  92. the name of the real function to call, making the key below ``mine_functions``
  93. the alias:
  94. .. code-block:: yaml
  95. mine_functions:
  96. alias_name:
  97. - mine_function: network.ip_addrs
  98. - eth0
  99. internal_ip_addrs:
  100. - mine_function: network.ip_addrs
  101. - cidr: 192.168.0.0/16
  102. ip_list:
  103. - mine_function: grains.get
  104. - ip_interfaces
  105. .. _mine_interval:
  106. Mine Interval
  107. =============
  108. The Salt Mine functions are executed when the Minion starts and at a given
  109. interval by the scheduler. The default interval is every 60 minutes and can
  110. be adjusted for the Minion via the ``mine_interval`` option in the minion
  111. config:
  112. .. code-block:: yaml
  113. mine_interval: 60
  114. Mine in Salt-SSH
  115. ================
  116. As of the 2015.5.0 release of salt, salt-ssh supports ``mine.get``.
  117. Because the Minions cannot provide their own ``mine_functions`` configuration,
  118. we retrieve the args for specified mine functions in one of three places,
  119. searched in the following order:
  120. 1. Roster data
  121. 2. Pillar
  122. 3. Master config
  123. The ``mine_functions`` are formatted exactly the same as in normal salt, just
  124. stored in a different location. Here is an example of a flat roster containing
  125. ``mine_functions``:
  126. .. code-block:: yaml
  127. test:
  128. host: 104.237.131.248
  129. user: root
  130. mine_functions:
  131. cmd.run: ['echo "hello!"']
  132. network.ip_addrs:
  133. interface: eth0
  134. .. note::
  135. Because of the differences in the architecture of salt-ssh, ``mine.get``
  136. calls are somewhat inefficient. Salt must make a new salt-ssh call to each
  137. of the Minions in question to retrieve the requested data, much like a
  138. publish call. However, unlike publish, it must run the requested function
  139. as a wrapper function, so we can retrieve the function args from the pillar
  140. of the Minion in question. This results in a non-trivial delay in
  141. retrieving the requested data.
  142. Minions Targeting with Mine
  143. ===========================
  144. The ``mine.get`` function supports various methods of :ref:`Minions targeting
  145. <targeting>` to fetch Mine data from particular hosts, such as glob or regular
  146. expression matching on Minion id (name), grains, pillars and :ref:`compound
  147. matches <targeting-compound>`. See the :py:mod:`salt.modules.mine` module
  148. documentation for the reference.
  149. .. note::
  150. Pillar data needs to be cached on Master for pillar targeting to work with
  151. Mine. Read the note in :ref:`relevant section <targeting-pillar>`.
  152. Example
  153. =======
  154. One way to use data from Salt Mine is in a State. The values can be retrieved
  155. via Jinja and used in the SLS file. The following example is a partial HAProxy
  156. configuration file and pulls IP addresses from all Minions with the "web" grain
  157. to add them to the pool of load balanced servers.
  158. :file:`/srv/pillar/top.sls`:
  159. .. code-block:: yaml
  160. base:
  161. 'G@roles:web':
  162. - web
  163. :file:`/srv/pillar/web.sls`:
  164. .. code-block:: yaml
  165. mine_functions:
  166. network.ip_addrs: [eth0]
  167. Then trigger the minions to refresh their pillar data by running:
  168. .. code-block:: bash
  169. salt '*' saltutil.refresh_pillar
  170. Verify that the results are showing up in the pillar on the minions by
  171. executing the following and checking for ``network.ip_addrs`` in the output:
  172. .. code-block:: bash
  173. salt '*' pillar.items
  174. Which should show that the function is present on the minion, but not include
  175. the output:
  176. .. code-block:: shell
  177. minion1.example.com:
  178. ----------
  179. mine_functions:
  180. ----------
  181. network.ip_addrs:
  182. - eth0
  183. Mine data is typically only updated on the master every 60 minutes, this can
  184. be modified by setting:
  185. :file:`/etc/salt/minion.d/mine.conf`:
  186. .. code-block:: yaml
  187. mine_interval: 5
  188. To force the mine data to update immediately run:
  189. .. code-block:: bash
  190. salt '*' mine.update
  191. Setup the :py:mod:`salt.states.file.managed` state in
  192. :file:`/srv/salt/haproxy.sls`:
  193. .. code-block:: yaml
  194. haproxy_config:
  195. file.managed:
  196. - name: /etc/haproxy/config
  197. - source: salt://haproxy_config
  198. - template: jinja
  199. Create the Jinja template in :file:`/srv/salt/haproxy_config`:
  200. .. code-block:: yaml
  201. <...file contents snipped...>
  202. {% for server, addrs in salt['mine.get']('roles:web', 'network.ip_addrs', tgt_type='grain') | dictsort() %}
  203. server {{ server }} {{ addrs[0] }}:80 check
  204. {% endfor %}
  205. <...file contents snipped...>
  206. In the above example, ``server`` will be expanded to the ``minion_id``.
  207. .. note::
  208. The expr_form argument will be renamed to ``tgt_type`` in the 2017.7.0
  209. release of Salt.