tiasfen.blogg.se - Beacon effect stack

If the Minion service of a Target where to stop and re-start my Beacon would not persist. By electing not to “save” the Beacon I am saying to a Target to only use this configuration during the current runtime. So in the above example I am using the Beacon State module to apply a Beacon that uses the “service” Beacon module. There are many Beacon modules, each one providing Beacon functionality for a different things such as disk space, packages, processes etc. Line 4 is something you should play close attention to. Onchangeonly: True #Stops event on Minion start name: service #Relevant Beacon module name #State file for applying a beacon state for the crond serviceīeacon.present: #Beacon State module and function

Here I have created a State File on my fileserver which will create a Beacon for monitoring a service, in this case crond. There are reasons why you would choose one over the other but lets start with the Beacon state module. To apply a Beacon configuration using States you can either create a managed file on the minion that includes the Beacon configuration or you can use the Beacon state module. As we’ve been looking at States in the previous articles and I want the process of adding Beacon configuration to a Minion to be centrally defined and controlled I’m going to cover this method. There are multiple methods to create a Beacon including manually creating config files on the required Minions, adding Beacon config to a Pillar (more on those later) and using State modules. Now that you understand the concept of how this is supposed to work lets start by defining a Beacon.

Target sees a Job on the Event Bus for it and applies the defined Reactor State.

Salt Reactor monitors the Event Bus and issues a Job to apply a State when a matching event is detected.

Salt Beacon places an event on the Event Bus of the Master when an event happens that matches the Beacon config.

Beacon configuration is performed by a state.apply AND/OR local config file creation.

The following diagram gives you an idea of how Salt and it’s components work together to persist configuration on a Target. In this article I’m going to concentrate on Beacons but before we get into that lets take a look at how Beacons and Reactors work together to persist States on Targets. But how do you persist some of those States to make sure they are not deviated from or ensure that if a change is made then the appropriate corrective action is taken? That is a job for Beacons and Reactors which are core components of open source Salt. This allows a new Minion to be effectively assigned a role and then receive the States that are matched to that role from the execution of a Highstate. In the last article I covered some of the options available to build configuration maps for different types of servers.