SaltStack is a remote execution tool and configuration management system like ansible, puppet or chef. Designed to work with any number of servers, from local network systems to other deployments across different data centers.
Master:
Master is the main server/machine that controls the infrastructure and dictates policies for the servers/machines that it manages. Master operates both as a repository for the configuration data AND as the control center that initiates remote command and ensures the state of your other machines. A daemon called salt-master runs on the Master to provide this functionality.
Minion:
Servers that Salt Master manages. A daemon salt-minion runs on EACH of the managed machines and is configured to communicate with the Master. The Minion is responsible for executing the instructions sent by the master, and reports back on the success (or failure). Communications between a master and minions occurs over the ZeroMQ message bus.
State/States-
The states are the heart and soul of Salt allows an administrator to describe the state that a system should be placed in. States are stored in text files on the master and transferred to the minions on demand via the master's File Server. The collection of state files make up the State Tree.
Formula-
Salt formulae are pre-written sets of state calls, arranged with the aim of producing a specific result.These are the configuration management files that describe how athe target system should look once the formula has been applied.By default, these are written in the YAML data serialization format, which provides a very good middle ground between high-readability and machine-friendliness.
A good collection of Salt formulas created by the SaltStack organization and community can by found in this GitHub account.
Grains-
The grains are stored on each minion in YAML and hold OS and hardware specific information like the FQDN of the minion, its minion ID, the CPU flags, IPs of the different interfaces, kernel information, total memory, OS family, the salt version of the minion among other pieces of information; all of this is automatically gathered by Salt. it is fairly common to use grains to assign a "role" to a server. This can then be used to target a subset of nodes similar to the operating system example above.
Pillar-
Pillar is used to store data, and it can store any kind of data; it is a very versatile system. It usually holds:
Sensitive data: Passwords, usernames, etc.
Minion configuration: ie. The name of the Apache package (RedHat based is httpd, Debian based is Apache2)
Variables: ie. The list of the company DNS servers, or a variable that indicates towhich deparment/subnet/category the minion belongs.
Execution Modules
Salt offers a variety of functions to manage the package system, run tests on the minion, manage files, manage web servers among other things. These functions are called Execution Modules. Salt even allow to write own execution modules
Top File
Matches formulas and Salt pillar data to Salt minions. for further details read this
Modules that execute on the Salt master to perform supporting tasks. Salt runners report job status, connection status, read data from external APIs, query connected Salt minions, and more.
For example, the Orchestrate runner coordinates configuration deployments across many systems.
Returners
Send data returned by Salt minions to another system, such as a database. Salt returners can run on the Salt minion or on the Salt master.
Reactor
Trigger reactions when events occur in your SaltStack environment.
Salt Cloud/Salt Virt
Provision systems on cloud providers / hypervisors and immediately bring them under management.
Salt SSH
Run Salt commands over SSH on systems that do not have a Salt minion
Ref:
1. https://docs.saltstack.com/en/latest/contents.html
2. https://www.tutorialspoint.com/saltstack/saltstack_architecture.htm
3. https://www.digitalocean.com/community/tutorials/an-introduction-to-saltstack-terminology-and-concepts
4. https://blog.talpor.com/2014/07/saltstack-beginners-tutorial/
No comments:
Post a Comment