SaltStack - Configuration Management that Rocks!

About Me

• Full-Stack Web Developer (Ruby, Javascript)
• Lead-Tech at Quicklizard Ltd.
• Freelance consultant & trainer
• Find me - @zohararad (Twitter / Github)

SaltStack Intro

• Configuration Manager (obviously)
• Remote Execution Engine
• Written in Python
• Configs are Jinja-powered YAMLs
• Hierarchical Master/Slave Architecture

Standing Out From The Crowd

Features that make SaltStack stand out from the crowd include:

• Remote Execution
• Power of Simplicity (3 concepts & Jinja)
• Solid Docs (once you wrap your head around it)
• Everything is a file!
• It's only YAML, but it's extensible (imports, overrides)

Salt States

Salt States are the heart of SaltStack's engine, and define the final state in which our server should be configured.

Salt States

• Installed Software (optionally with version)
• Running Services
• File System (dirs, files, mount points)
• User-provided configuration (with Jinja support)
• Dependencies and Conditions

Salt States - Packages and Services

      
nginx:
  pkgrepo.managed:
    - ppa: nginx/stable
    - require_in:
      - pkg: nginx
  pkg.installed:
    - version: 1.6.2
  service.running:
    - enable: True
    - require:
      - pkg: nginx
      
    

Salt States - File Management

      
/etc/nginx/sites-available/www.mysite.com:
  file.managed:
    - source: salt://packages/nginx/sites-available/www.mysite.com
    - template: jinja
    - require:
      - pkg: nginx

/etc/nginx/sites-enabled/www.mysite.com:
  file.symlink:
    - target: salt://packages/nginx/sites-available/www.mysite.com
    - require:
      - file: /etc/nginx/sites-available/www.mysite.com
      
    

Pillars of Salt

SaltStack's Pillars are the way we define variables that can be passed on to our Salt State files

Pillars help us create reusable, generic states with custom, user-defined variables.

Salt Pillar Data

      
# Pillar File
nginx:
  - stable: 1.6.2
  - edge: 1.7.3

# State File
{% set nginx = pillar.get('nginx', {}) -%}
nginx:
  pkg.installed:
    - version: {{ nginx['stable'] }}
      
    

Grains of Salt

Salt Grains are useful bits of information about the underlying OS we're trying to configure, such as OS type (Ubuntu or RedHat), CPU Arch., network and hostnames and even user-defined information (such as roles).

Like Salt Pillars, Grains help us define generic Salt States that target multiple configuration targets and scenarios.

Salt Grains - Package Names

      
apache:
  pkg.installed:
    {% if grains['os'] == 'RedHat'%}
    - name: httpd
    {% elif grains['os'] == 'Ubuntu' %}
    - name: apache2
    {% endif %}
      
    

Salt Grains - Hostnames

      
# nginx configuration
server {
  listen 80;
  server_name {{ grains['id'] }} {{ grains['id'] | replace('www','') }};
  root /var/www/mysite.com/public;
}
      
    

Putting it all Together

With out States, Pillars and Grains in place, we can now see how learn about Master, Minions and applying our configuration to target servers.

SaltStack Cluster

Salt Master

• Holds master copy of States and Pillars
• Authenticates new minions (SSH)
• Serves States, Pillars & Files (file server)
• Single point of remote execution on minions
• States can be read from Git
• Masters can be hierarchical

Salt Minion

• Runs on each target server
• Reads config from Master, caches locally
• Responsible for actual execution
• Authenticates with Master over SSH
• Communicates with Master over ZeroMQ

Top Files

Top files (top.sls) are the entry point of our States and Pillars configuration

Since everything in SaltStack is a file, Top files serve as the entry point from which we can target which minions will receive which parts of States and Pillars configuration tree.

SaltStack File Tree & States top.sls

      
/srv/salt/states
  - top.sls
  /salt
    - minion.sls
    - master.sls
  /nginx
    - init.sls
  /repos
    - ubuntu.sls
      
      
base:
  '*':
    - salt.minion
  'salt-master*':
    - salt.master
  '^(lb|web).(qa|prod).loc$':
    - match: pcre
    - nginx
  'os:Ubuntu':
    - match: grain
    - repos.ubuntu
      
    

Pillar Data top.sls

      
/src/salt/pillars
  - top.sls
  /salt
    - minion.sls
    - master.sls
  /www.mysite.com
    - init.sls
      
      
base:
  '*':
    - salt.minion
  'salt-master*':
    - salt.master
  '^web.(qa|prod)':
    - match: pcre
    - www.mysite.com
      
    

Remote Execution

Remote execution is basically the entry point to control minion state via state files or run arbitrary commands on a subset of registered minions

This is useful because it provides us with a fine-grained control over each minion using a very simple CLI.

Remote Execution

      
# tell minions to go into "high-state"
$ salt 'www*' state.highstate

# upgrade SSH server on all minions
$ salt '*' cmd.run 'aptitude install sshd=1.1.0~ubuntu-1.1.2'
      
    

SaltStack Highlights

• Everything is a file. YAML formatted Jinja templates
• States hold config, Pillars hold variables, Grains hold OS data
• Master manages config, minions and serves files
• Master allows remote execution on minions
• Minion gets targeted config from Master, executes locally
• States and Pillars are file trees with top.sls as entry point
• Minions are targeted in top.sls using grains, regex. etc.

We only touched the surface

SaltStack is more than just a configuration manager. So far we covered the bare basics to familiarize ourselves with Salt.

For more advanced topics, including environment-based configs, scheduling and job managemnet, check out docs.saltstack.com

My experience with SaltStack at Quicklizard

• Reasons for choosing SaltStack over Chef and Ansible
• Beyond configuration - Remote execution and automatic recovery
• Role based deployment with roles in Grains
• Low points - Docs, debugging