Salt

Posted on avril 24, 2014 in System

Since a few months, I've been inclined to test and use Salt Stack. I manage a lot a heterogeneous plateforms, but each one are composed of similar machines who does the same stuff.

For example, once three months, I'm being asked to install a new packages, configure a new printer on desktop machines of our datacenter's collaborators. What a great use case :)

Introduction

Salt is like Puppet and Chef, which are also deployment and automation tools. I find it more lightweight and

Installation

It seems that Salt Stack is not yet in the official Ubuntu repositories

Things to do on your master host:

apt-get install python-software-properties
add-apt-repository ppa:saltstack/salt

apt-get update
apt-get install salt-master

Things to do on your client host:

apt-get install python-software-properties
add-apt-repository ppa:saltstack/salt

apt-get update
apt-get install salt-minion

By default a Salt Minion will try to connect to the DNS name "salt"; if the Minion is able to resolve that name correctly, no configuration is needed. If the DNS name "salt" does not resolve, you need to edit /etc/salt/minion

master: 192.168.0.2

Restart everything

Master

/etc/init.d/salt-master restart

Minion

/etc/init.d/salt-minion restart

Communication

Communications bettwen the Master and your Minions is done via AES encryption. But to communicate, your Minion's key must be accepted by the Master

List all keys:

$ salt-key -L
Accepted Keys:
Unaccepted Keys:
NOC1-VTY2
NOC2-VTY2
NOC3-VTY2
NOC4-VTY2
Rejected Keys:

Accept all keys

$ salt-key -A

Accept one key

$ salt-key -a NOC1-VTY2

If you list your keys again you should get an output like this:

$ salt-key -L
Accepted Keys:
NOC1-VTY2
NOC2-VTY2
NOC3-VTY2
NOC4-VTY2
Unaccepted Keys:
Rejected Keys:

You can now test the communication between your Master and one of all of your Minions

$ salt 'NOC1-VTY2' test.ping
NOC1-VTY2:
    True
$ salt '*' test.ping
NOC3-VTY2:
    True
NOC4-VTY2:
    True
NOC1-VTY2:
    True
NOC2-VTY2:
    True

Deployment

Now, I want to be able to add another computer to our NOC team without having to push manually all the configurations (NIS/NFS/packages etc)

There is two major things, the directive file_roots and the file top.sls According to the documentation, SLS (or SaLt State file) is a representation of the state in which a system should be in.

file_roots

In your /etc/salt/master file, you need to uncomment the file_roots directive. It defines the location of the Salt file server and the SLS definitions. Mine look like this

file_roots:
  base:
    - /srv/salt/

After this modification, restart your server

top.sls

Doing specific stuff to specific machines in the main purpose of Salt. This is defined within the top.sls file.

This can be done by:

Ways Example
Globbing "webserverprod"
Regular Expressions "^(memcache|web).(qa|prod).loc$"
Lists "dev1,dev2,dev3"
Grains "os:CentOS"
Pillar
Node Groups
Compound Matching

This is my top.sls file:

base:
   '*':
     - nagios.client
   'os:Ubuntu':
     - repos.online
   '^NOC(\d)+-VTY2$':
     - match: pcre
     - yp.install
     - yp.nsswitch
     - nfs.mount_noc

base:

base:
   '*':
     - nagios.client

This block declare the global environment the minion must apply. In this case, every machine will be assigned the nagios.client directive It's going to execute /srv/salt/nagios/client.sls

os:Ubuntu

This section matches machine using the Salt "grain" system, basically from system attributes. It will execute /srv/salt/repos/online.sls

'^NOC(\d)+-VTY2$'

This section matches using Perl regular expression feature If the hostname of the machine matches this regex, it will be assigned the few directives It will execute, /srv/salt/nagios/yp/install.sls, /srv/salt/nagios/yp/nsswitch.sls, /srv/salt/nagios/nfs/mount_noc.sls

Links