Introduction to Salt States

What is Salt?

• Why Salt before what is Salt? 
• Salt is very similar to Chef, Puppet, Ansible but very Powerful. 
• Using ssh is substantially slow and not scalable, hence TCP based Salt stands out. 

• Thomas Hatch’s first commit was on Feb 2011 for SaltStack and the company was founded in 2012. Linkedin was the first one to use Salt and now there are 10,000+ users. 

• Salt is a remote execution and configuration management tool.  

• The foundation of Salt is remote execution, which is very unique and enables extremely fast & reliable Remote Control Systems.  

• Salt is designed to be secure using AES encryption and public-key authentication; incredibly scalable using an advanced ZeroMQ topology, so that salt daemon includes a viable and transpired AMQ broker. Further Salt takes advantage of communication via msgpack, which makes it fast and light network traffic. 

• Salt is open source developed under Apache 2.0 license. 

• Salt is flexible enough to support Agent (minion) or Agentless (via ssh). 

• Salt is written in phython, hence it’s very easy to contribute. 

• The salt-master daemon runs on the designated Salt master and performs functions such as authenticating minions, sending, and receiving requests from connected minions and sending and receiving requests and replies to the 'salt' CLI. 

• LocalClient – Salt Client runs on the same machine as of salt master is called LocalClient. This connects to the salt master via – TCP - 4506 

Salt – Master 

• Host name of the Salt master should be salt. The salt minion looks defaulting to that name. you can change the host name but the default one is simple  
• Salt Master connects to Salt Minion via TCP 4505. 
• ZeroMQ / AMQP broker / Wrapper MQ 

Salt – Minion 

• Each salt minion establishes a connection to the master ReqServ via TCP 4506  

ZeroMQ 

• High-speed network message passing. 

Salt States 

• The folder (/opt/salt/states/base) under which you are planning to create your state files should be added in file_roots master config file (/etc/salt/master) as your root directory. 
• Create the following file under /opt/salt/states/base
• Filename:list-processes.sls 

                            #State Id should be unique across all states files. No space after or before: list-processes:| # type the command after two black spaces in the immediate new line   cmd.run: # 4 spaces after new line, once space after -, no space before : and once space after :     - name: ps -ef 

               Run the file: sudo salt ‘*all-02*’ state.sls list-processes 

               Output start & end: 

Pillars 

• Pillars are tree-like structures of data defined on the Salt Master and passed through to minions.  
• A pillar is a list of data on the master (in SLS format) that you need to distribute to your minions. Pillar allows you to set variables that the minions can access, for example a database configuration option. 
• Pillar data is stored on the master and cached on matching minions.   Note: Pillar data is only available to matching minions. 

Grains 

• Salt grains are pieces of information gathered by and maintained by a minion (salt-minion daemon) and passed back to master upon request. 
• In Salt, grains are used for immutable aspects of your minion, such as the cpu, memory, location, time zone, etc. 
• The grains are stored on each minion in YAML and hold OS and hardware specific information to that minion.  
• Grains are stored on minions and cached on the master.   Note: All grains data is available to all minions. 

Difference between Grains & Pillars

Differences	Grains	Pillars
Info which..	... Minion knows about itself	... Minion asks Master about
Distributed:	Yes	No
Centralized	No	Yes
Computed automatically:	Yes (mostly should)	No
Assigned manually:	No (or kept to minimum)	Yes
Conceptually intrinsic to…	… individual minion node	… entire system

Salt Commands - Tried  & Tested

• sudo salt-run manage.up – lists the connected salt minions 
• sudo salt-run manage.status – lists the minions that are up & down 
• sudo salt-run manage.down – lists the minions that are down 
• type ls -1 /var/cache/salt/master/minions from master to list the available minions 
• "sudo salt-key -L" will list all minions that whose public keys you've accepted on your master. 
• sudo salt ‘*’ cmd.run ‘<daemon  or application name> <parameters>’ runas=<username>  Note: run.cmd does not work. With cmd.run it says ERROR: Sorry, Windows does not support runas functionality. 

Use grains, specify OS to run on specific set of OS. 

sudo salt –G ‘os:CentOS’ ‘<daemon  or application name> <parameters>’ runas=<username> 

or  sudo salt –G ‘kernel:Linux’ ‘<daemon  or application name> <parameters>’ runas=<username> 

sudo salt –G ‘kernel:windows’ cmd.run 'd:\apps\cygwin64\bin\bash.exe -li <application name> <parameters>'  

• Find the IP Address of the minions 
• sudo salt ‘*’ grains.item fqdn_ip4 
• sudo salt ‘kernel:windows’ grains.item fqdn_ip4 
• sudo salt ‘kernel:linux’ grains.item fqdn_ip4 
• salt-call --local grains.item fqdn - this one to get fqdn on EC2 instance

• Command Line reference for Masterless Minion 
• salt-call -g lists the grains in the system - EC2 instance
• salt-call --local state.highstate -l debug --retcode-passthrough pillar='{"name": "value"}'
• salt-call --local state.highstate -l warning --retcode-passthrough pillar='{"name": "value"}'`
• salt-call --local state.apply <sls filename without  extn> -l debug
• salt-call --local grains.item fqdn - this one to get fqdn on EC2 instance