standalone_minion.rst 4.0 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109
  1. .. _tutorial-standalone-minion:
  2. =================
  3. Standalone Minion
  4. =================
  5. Since the Salt minion contains such extensive functionality it can be useful
  6. to run it standalone. A standalone minion can be used to do a number of
  7. things:
  8. - Use salt-call commands on a system without connectivity to a master
  9. - Masterless States, run states entirely from files local to the minion
  10. .. note::
  11. When running Salt in masterless mode, it is not required to run the
  12. salt-minion daemon. By default the salt-minion daemon will attempt to
  13. connect to a master and fail. The salt-call command stands on its own
  14. and does not need the salt-minion daemon.
  15. As of version 2016.11.0 you can have a running minion (with engines and
  16. beacons) without a master connection. If you wish to run the salt-minion
  17. daemon you will need to set the :conf_minion:`master_type` configuration
  18. setting to be set to 'disable'.
  19. Minion Configuration
  20. --------------------
  21. Throughout this document there are several references to setting different
  22. options to configure a masterless Minion. Salt Minions are easy to configure
  23. via a configuration file that is located, by default, in ``/etc/salt/minion``.
  24. Note, however, that on FreeBSD systems, the minion configuration file is located
  25. in ``/usr/local/etc/salt/minion``.
  26. You can learn more about minion configuration options in the
  27. :ref:`Configuring the Salt Minion <configuration-salt-minion>` docs.
  28. Telling Salt Call to Run Masterless
  29. ===================================
  30. The salt-call command is used to run module functions locally on a minion
  31. instead of executing them from the master. Normally the salt-call command
  32. checks into the master to retrieve file server and pillar data, but when
  33. running standalone salt-call needs to be instructed to not check the master for
  34. this data. To instruct the minion to not look for a master when running
  35. salt-call the :conf_minion:`file_client` configuration option needs to be set.
  36. By default the :conf_minion:`file_client` is set to ``remote`` so that the
  37. minion knows that file server and pillar data are to be gathered from the
  38. master. When setting the :conf_minion:`file_client` option to ``local`` the
  39. minion is configured to not gather this data from the master.
  40. .. code-block:: yaml
  41. file_client: local
  42. Now the salt-call command will not look for a master and will assume that the
  43. local system has all of the file and pillar resources.
  44. Running States Masterless
  45. =========================
  46. The state system can be easily run without a Salt master, with all needed files
  47. local to the minion. To do this the minion configuration file needs to be set
  48. up to know how to return file_roots information like the master. The file_roots
  49. setting defaults to /srv/salt for the base environment just like on the master:
  50. .. code-block:: yaml
  51. file_roots:
  52. base:
  53. - /srv/salt
  54. Now set up the Salt State Tree, top file, and SLS modules in the same way that
  55. they would be set up on a master. Now, with the :conf_minion:`file_client`
  56. option set to ``local`` and an available state tree then calls to functions in
  57. the state module will use the information in the file_roots on the minion
  58. instead of checking in with the master.
  59. Remember that when creating a state tree on a minion there are no syntax or
  60. path changes needed, SLS modules written to be used from a master do not need
  61. to be modified in any way to work with a minion.
  62. This makes it easy to "script" deployments with Salt states without having to
  63. set up a master, and allows for these SLS modules to be easily moved into a
  64. Salt master as the deployment grows.
  65. The declared state can now be executed with:
  66. .. code-block:: bash
  67. salt-call state.apply
  68. Or the salt-call command can be executed with the ``--local`` flag, this makes
  69. it unnecessary to change the configuration file:
  70. .. code-block:: bash
  71. salt-call state.apply --local
  72. External Pillars
  73. ================
  74. :ref:`External pillars <external-pillars>` are supported when running in masterless mode.