This document discusses configuration management and provides an overview of Saltstack. It describes how configuration management addresses the challenges of managing hundreds of assets across multiple datacenters. It then summarizes the key components of Saltstack, including states, grains, pillars, roster, mine, job management, and reactors/events. States define the desired configuration of hosts, grains contain static host data, pillars provide variable host data, and roster facilitates remote management. Mine collects arbitrary host data, jobs manage scheduled tasks, and reactors respond to events. The document also briefly discusses syndication, proxies, Salt Virt for virtual machines, and Salt Cloud for cloud infrastructure.

1. Configuration management
More than 60 years old topic, actually.

2. Overview
1. The problem
2. The solution
3. The implementations
4. The comparison

3. The problem
• Hundreds/thousands of assets
• Multiple datacenters
• Physical/Virtual hosts, Storages, Appliances, Network gears
• Dozens of parameters to set up for each asset
• Multiple operating systems
• Different way to configure the same parameter
• Dozens of users
• Roles, permissions, passwords, keys
• Hundreds of software and system services
• Configuration

4. The solution
Large companies started to extend asset
management:
• More business/management rather than
an operation tool
• At least it keeps track of what you are
dealing with
• Let you roughly size the effort to keep IT
running
• Not enough, but still an IT cornerstone

5. The implementations
1. CFEngine3 (CFEngine started in 1993)
• Self Healing
• Promise theory
2. OCSInventoryNG + GLPI (2003)
3. Bcfg2 (2004)
4. Puppet (2005)
5. Chef (2009)
6. Salt (2011)
7. Ansible (2012)
8. A load more...

6. The comparison
• TL;DR : Basically, more or less they are the same.
• More then 6 years old (marketing) topic, lasted for more than 4 years
• Tools are more then mature now
• There is a (sort of) consensus about the market being full
• More than battle one another, they battle people against any of them
• (Almost) All have the full set of features and functionalities for the job
• Enterprise support and/or training
• Extensive public documentation and books.
• Friendly and active Opensource community
• Few differences
• Push vs Pull architecture, implementation details
• Dev oriented vs SysAdmin oriented

7. Saltstack Overview
Everything else is just data:
• States
• Grains
• Pillars
• Roster
• Mine
• Jobs management
• Reactor / Events
• Syndication
• Proxying

8. States
apache2:
pkg.installed: []
service.running:
- watch:
- file: '/etc/apache2/site-available/*.conf'
/etc/apache2/site-available/app.conf: # ID declaration
file: # state declaration
- managed # function
- source: salt://webserver/app.conf # function arg
- require: # requisite declaration
- pkg: apache2 # requisite reference
• Define the desired state of a target host
• top.sls file couple states with target hosts,
N to N
• Multi-level directory structure
• States and configuration files can be
templates:
• Jinjia2
• Mako
• Wempy
• States can also be:
• python
• pydsl
• pyobjects

9. Grains
• Define hosts attributes
• Can be used for state targeting
• Can be used in pillars
• Can be extended
• Are meant to be static data loaded at
startup
• Other targeting:
• Name or names list
• Globbing
• Regular expressions

10. Pillars
• Data input source
• Good for sensible data
• Pluggable inputs (> 24 included)
• cmd_json / cmd_yaml
• etcd
• git / svn
• hiera
• LDAP / RDBMS / NoSQL

11. Rosters
<Salt ID>: # The id to reference the target system with
host: # The IP address or DNS name of the remote host
user: # The user to log in as
passwd: # The password to log in with
# Optional parameters
port: # The target system's ssh port number
sudo: # Boolean to run command via sudo
priv: # File path to ssh private key,
# defaults to salt-ssh.rsa
timeout: # Number of seconds to wait for response when
# establishing an SSH connection
timeout: # Number of seconds to wait for response
minion_opts: # Dictionary of minion opts
• Pluggable system to facilitate the
salt-ssh system
• Ansible
• Scan

12. Mine
• Collect arbitrary data from minions and
store on master
• Short term storage only
• Mine functions can be defined in Rosters
• > 2015.5.0
• Mined values can be used in state and
configuration files

13. Job management
schedule:
highstate:
function: state.highstate
minutes: 60
meminfo:
function: status.meminfo
minutes: 5
returner: mysql
log_loadavg:
function: cmd.run
seconds: 3660
args:
- 'logger -t salt < /proc/loadavg'
kwargs:
stateful: False
shell: /bin/sh
• Minions have an internal "proc" directory
in which they store job specific data
• Can query one or more minions for
current job information
• Versatile scheduler

14. Reactor / Events
reactor: # Master config section "reactor"
- 'salt/minion/*/start': # Match tag "salt/minion/*/start"
- /srv/reactor/start.sls # Things to do when a minion starts
- /srv/reactor/monitor.sls # Other things to do
- 'salt/cloud/*/destroyed': # Globs can be used to matching tags
- /srv/reactor/destroy/*.sls # Globs can be used to match file names
- 'sib/custom/event/tag': # React to custom event tags
- salt://reactor/mycustom.sls # Put reactor files under file_roots
• Events
• Have tags, for filtering
• Have pig-back data structure
• Can be fired by external
commands
• Reactor
• Salt configuration
• Similar to state and pillars

15. Syndication
• Syndication:
• Special pass through minion
• About flexibility
• Complex topologies
• Mix and match
• Masterless
• Master -> minions
• Master -> Syndic(s) -> minions

16. Proxy
• Special Minion
• Control devices that cannot run minion or
ssh
• Network gear
• Security reason
• Not out of the box

17. Bonus 1: Salt Virt
• Based on libvirt
• Virtual machine deployment
• Inspection of deployed VMs
• Virtual machine migration
• Network profiling
• Automatic VM integration with all aspects of Salt
• Image Pre-seeding
• Use salt to query live data about the hypervisor and make decisions
about cloud operation.
• No external resources required

18. Bonus 2: Salt Cloud
• Built-in support for 16 cloud providers
• EC2
• Google
• Azure
• DigitalOcean
• Linode
• OpenStack
• Rackspace
• Extensible

19. Thanks
Luca De Vitis
E-Mail: luca.devitis@linux.com