Why use SaltStack for automation and orchestration
Thomas S. Hatch released Salt, aka the SaltStack Platform, in 2011 after becoming frustrated with the (slow) speed of the Ruby-based open source configuration management systems available at the time, including Puppet and Chef. Hatch used the open source ZeroMQ messaging library for networking and Python as the implementation language. Later the more scalable RAET (Reliable Asynchronous Event Transport Protocol) transport was developed as an alternative message queue.
The result is a massively scalable automation system, supporting many thousands of nodes, with message queue networking and a multi-master architecture. If you have huge networks, SaltStack—whether open source Salt or SaltStack Enterprise—might be a better choice than Puppet, Chef, or Ansible. To open source Salt, SaltStack Enterprise adds features like a web console with customizable dashboards and reports, role-based access control with LDAP integration, database encryption and activity auditing, and commercial support.
SaltStack architecture
SaltStack provides event-driven automation, orchestration, and remediation, since Salt minions (agents) can report back to their masters when their client is out of spec. SaltStack can also talk to agentless nodes using SSH; the nodes must have Python installed as well as SSH. Agentless communication is slower than using a message queue.
Salt controllers are called masters; Salt agents are called minions. Salt configuration modules are called states, and they are written in Jinja-based YAML, Python, or PyDSL. Data is held in pillars; grains hold static information about a system in RAM. Execution modules perform local actions when called by the remote execution engine and contain cross-platform compatibility information.
Source: InfoWorld – Cloud Computing
Recent Comments