Rajan's View

Overview In the previous post , we saw how beacons were deployed in all machines using state files. Salt internally uses zero MQ messaging for communication between the master and minions. As with any messaging framework, there are publisher(s) and consumer(s). One can think of the beacons (on salt minions) as publishers and reactors (on salt master) as consumers. Salt Concepts Covered In this post, the following Salt concepts are covered - Beacons - Monitor minions for state changes, system diagnostics etc. Reactors - Trigger reactions when events occur in the managed systems running minions. Beacons A beacon on the minion can be used to monitor various system events such as - memory usage, CPU load average, overall statistics, user commands etc. The beacon deployed in the previous post contains the 'sh' module. Sh module monitors all commands run on a machine which has the salt minion running. Note: Every time a beacon is deployed to the salt minions,

Overview In the previous post , we saw how to setup the salt master and minions. Now, let's see how we can use Salt to maintain a consistent state in the infrastructure. The state here could mean - software, configuration, permissions etc. Salt Concepts Covered In this post, the following concepts are covered - Formulas (States) - A declarative or imperative representation of a system configuration. Top File - Matches formulas and Salt pillar data to Salt minions. State Management One of the key concepts in Salt, is state management. State management in Salt ensures that the applications and infrastructure is managed centrally (as you would using other tools such as Chef, Ansible, Puppet). In addition, state management also ensures that if someone changes the configuration in a minion, state management will rest it back to what it should be. This way, Salt ensures that all changes to application, infrastructure, configuration, permission etc. are managed centrally