Fundamentals
Intros
Salt Terms
Master
A central Salt daemon from which commands can be issued to listening minions.
Minion
A server running a Salt minion daemon which can listen to commands from a master and perform the requested tasks. Generally, minions are servers which are to be controlled using Salt.
Targeting
Specifying which minions should run a command or execute a state by matching against hostnames, or system information, or defined groups, or even combinations thereof
Module
Functions called by the salt command that perform specific tasks.
There are many types of modules:
- execution
- state
Salt-key
Executes simple management of Salt server public keys used for authentication between masters and minions.
Grain
A key-value pair which contains a fact about a system, such as its hostname, network addresses.
SLS
Stands for Salt State
State
The definition of the desired state of salt minions, States comprise of single or multiple salt modules.
State Module
A module which contains a set of functions (things that need to be done).
YAML
Is a human-readable data format.
Why use Salt?
- Automate
- Configure
- Deploy
- Provision
What can Salt do?
- Configure
- Deploy
- Build
- Execute and retrieve
- Monitor
Who uses Salt now?
- Rackspace
- Customers
- You
Group Activity: What can you use Salt for?
- In small groups, research what companies are currently using Salt
- Discuss among your group, how configuration management like Salt could have saved time or resources.
Salt Architecture
Master and Minions
Salt Master
Controller of your Salt Minions
- /etc/salt/master
- /var/log/salt/master
- /etc/init.d/salt-master
- Communicate via ZeroMQ or SSH
Diagram here
Salt Minion
Allows for a Salt Master to control a server
- /etc/salt/minion
- /var/log/salt/minion
- /etc/init.d/salt-minion
Key Management
- SSH keys use for communications
- Minions generate keys
- salt-key on master
- /etc/salt/pki
Diagram here
Salt Modules
- Executon Modules
- State Modules
- and the rest...
Salt v. Chef v. Ansible
In a Nutshell
- Chef (2009) has been an industry standard, Puppet lineage, (2) flavors: Open Source, and Enterprise (adds hosted/private server, push capable, better web UI, central authentication, multi-tenancy, RBAC, reporting and support)
- Ansible (2012) is very recent, fully open source, active community driven development, (3) flavors: Guru (command line core only), Tower (adds web UI, LDAP, ReST API), and Enterprise Tower (adds support + SLA)
- Salt (2011) comes between Ansible and Chef in capability, fully open source, supports Windows, originally for remote execution
Philosophy
- Chef is about coding in ruby to suit your needs, and leverages a large pre-built base of re-usable code
- Ansible is about simple, extensible, batteries included, best ease of use, no coding
- Salt is about simple, extensible, ultra high speed, enterprise scale, batteries included, coding optional
Languages
- Chef: Ruby code using a specialize DSL (Domain Specific Language)
- Ansible: Python (but YAML for users)
- Saltstack: Python (but YAML for users)
Add User in Ruby
user "fred" do
supports :manage_home => true
comment "Fred Flintstone"
uid 4000
home "/home/fred"
shell "/bin/zsh"
end
group "wheel" do
action :modify
members "fred"
append true
end
group "storage" do
action :modify
members "fred"
append true
end
Add user in YAML
fred:
user.present:
- fullname: Fred Flintstone
- shell: /bin/zsh
- home: /home/fred
- uid: 4000
- gid: 4000
- groups:
- wheel
- storage
Architecture
- Chef: Server + Client agent, or Solo (no network component)
- Ansible: Agentless (uses ssh)
- Salt: Master + Minion (client), or Standalone
Management
- Chef: Code based pull, but added ZeroMQ push feature recently
- Ansible: YAML based push using ssh or ZeroMQ
- Salt: YAML based push/pull
Communications
- Chef: standard key-based SSL
- Ansible: standard SSH (or paramiko), MQ option
- Salt: MQ, custom SSH
Templating
- Chef: Ruby ERB
- Ansible: Jinja2
- Salt: Jinja2, others
Advantages of Salt
- Agents add (targeting) flexibility
- HA options availible
- Highly modular
- Friendly community driven development
Install and Deploy Salt
salt-bootstrap
salt-bootstrap
salt-bootstrap is the easiest method to install SaltStack.
- Multiple OS support
- Highly extendable
- Can install Salt Master / Minion
Download salt-bootstrap
wget -O install_salt.sh http://bootstrap.saltstack.org
Run salt-bootstrap
sh install_salt.sh
This example will install the minion, but -h show the help
Example flags
sh install_salt.sh -M -A localhost
This will install the Master and Minion (and configure it) all on the same machine.
Salt Keys
Salt Keys
Salt Keys manages which machines are allowed / not allowed to communicate with the Salt Master
salt-key
The -A flag will accept all pending keys
Verify installation
salt-master --versions-report
If installed correctly, you will see something like:
Salt: 2014.1.0
Python: 2.7.6 (default, Mar 22 2014, 22:59:56)
Jinja2: 2.7.2
M2Crypto: 0.21.1
msgpack-python: 0.3.0
msgpack-pure: Not Installed
pycrypto: 2.6.1
PyYAML: 3.10
PyZMQ: 14.0.1
ZMQ: 4.0.4
Lab
- Download the salt-bootstrap script
- Read the help file on salt-bootstrap
- Install the Salt Master / Minion on the same box
- Verify that the Salt Master is installed
- Accept the minion's keys
Example Commands and State Files
Execution Modules
Execution Modules
Execution modules are used when calling modules directly from the command line.
salt '*' user.add fred uid gid groups home shell
test.ping
This is the most basic module you can run. It simply connects to the targeted minion(s) and returns True if that minion responds.
salt '*' test.ping
minion1:
True
minion2:
True
There is no matching state module for test.ping.
test.ping Demo
Running Commands
Running arbitrary commands can come in handy for one time operations. This is done with the cmd.run module.
Execution Example
salt webservers cmd.run "service apache2 restart"
State Example
touches_foo:
cmd.run:
- name: touch /tmp/foo
- creates: /tmp/foo
Date Command Demo
Your Turn!
- On your salt master run the test.ping module targeting all minions
- Look up the documentation on the user module
- http://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.useradd.htm
State Modules
State Modules
State modules are used when calling state.sls or highstate agains t a minion.
salt '*' state.sls myslsfile
fred:
user.present:
- fullname: Fred Jones
- shell: /bin/zsh
- home: /home/fred
- uid: 4000
- gid: 4000
- groups:
- wheel
- storage
- games
Installing a Package
Package installations are abstracted by Salt. You don't have to invoke a specific yum or apt module, but a pkg module.
State Example
salt '*' pkg.install vim
Execution Example
install_vim:
pkg.installed:
- name: vim
Package names can still be different between distributions. (ie. apache2 and httpd)
Starting a Service
Starting services is done with the service module.
Execution Example
salt '*' service.start apache2
State Example
run_apache2:
service:
- running
- name: apache2
- enable: True
Service names can still be different between distributions. (ie. apache2 and httpd)
Installing sysstat Demo
Restart SSH Demo
Your Turn!
- Create the file: /srv/salt/cowsay.sls that will install the cowsay package
- Execute this file using the state.sls module
- Compare output from this to the output of a second execution of the file
hint
vim_install:
pkg.installed:
- name: vim
Grains
A grain is a piece of data related directly to a Salt Minion. You can view all grains related to a node with the grains.items module.
salt minion1 grains.items
You can target minions using data in grains. This example will target all your CentOS servers with a test.ping.
salt -G 'os:CentOS' test.ping
Grains Demo
Lab
Write your own state file to...
- Install the nginx webserver package
- Start the ngnix service
- add the user thatcha
A massive thanks to the content dev team...
Allen Oster
Bruce Stringer
Chris Caillouet
Chris Old
Eric Hernandez
Jason Swindle
Justin Phelps
Kenneth Wilke
Victor Palma
Salt Fundamentals
By Rackspace University
Salt Fundamentals
- 1,305