Automate Repetitive Tasks with SaltStack

0
357

showing presentation in salt programming

SaltStack is an open source, scalable, flexible systems management software that can be used for data centre automation, cloud orchestration, server provisioning and configuration management.

CM or configuration management is common terminology in the software industry. For those of us who do not know what it is, it’s the process of automating sets of tasks that are repetitive, e.g., building a machine to match the company or group standards. Some of the prominent tools that help you to do this are SaltStack, Ansible, Puppet, Chef, CFEngine, Bcfg2, Quattor, Rundeck and Vagrant. We will concentrate on SaltStack.
A DevOps engineer is a new role that has evolved in the software industry. One of the key skills a DevOps engineer is expected to have, among many others, is automation skills. Whoever has read the four-part series of articles on Puppet at https://www.opensourceforu.com/tag/puppet/ must surely know about configuration management by now, at least from a Puppet perspective. But don’t worry if you don’t know too much; one can always learn.

Why SaltStack?
There are a few reasons why we have chosen SaltStack as a configuration management tool. These are:

  • Orchestration, predictability and automation
  • The power available to DevOps
  • It is open source (Apache licence), free, and has pretty wide community support in case of hiccups
  • A full-fledged client/server model
  • It is written entirely in Python
  • Marks systems for easier management
  • Uses the fast, powerful and light communication layer-ZeroMQ
  • Uses the well established jinja2 platform for logic (uses a variety for languages to render the configuration files; yaml + jinja2 is the default template engine)
  • Password-less root-based remote execution—runs predefined or custom commands on remote hosts
  • It uses a push technology, where the onus is on the server to push configuration details to the client
  • Completely encrypted communication and data transfer
  • It is available on all UNIX/GNU/Linux platforms under the following pkg names:
  • salt-master
  • salt-minion

Glossary
This is already available at the SaltStack glossary page; I am just re-pasting a few terms that we will see more often.

SLS: The SaLt State File Extension.
Salt State: Consists of identifiers (resources to operate on), a state module (functionality to manage a type of resource) and function declarations (definition of a desired state of a resource), and sometimes function parameters (specific details for the state function).
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 that are to be controlled using Salt.
Masterless: A minion that does not require a Salt master to operate. All configuration is local.
Top file: Determines which SLS files should be applied to various systems, and organises those groups of systems into environments.
High state: The collection of states to be applied to a system.
High data: Data structure in a SLS file that represents a set of state declarations.
Job: Tasks to be performed by Salt command execution.
Pillar: A simple key-value store for user-defined data to be made available to a minion. Often used to store and distribute sensitive data to minions.
Grain: A key-value pair which contains a fact about a system, such as its hostname or network addresses.
Jinja: A templating language framework for Python, which allows variables and simple logic to be dynamically inserted into static text files when they are rendered. Inspired by Django’s templating language.
Salt key: Salt master manages which machines are allowed or not allowed to communicate with it.
Salt SSH: A configuration management and remote orchestration system, which does not require that any software besides SSH be installed on systems to be controlled.
SLS module: Contains a set of state declarations.
State declaration: A data structure that contains a unique ID and describes one or more states of a system, such as ensuring that a package is installed or a user is defined.
State module: A module that contains a set of state functions.
State run: The application of a set of states on a set of systems.
Target: Minion(s) to which a given Salt command will apply.

Table 1
Table 1

Setup

We can install SaltStack by three methods—Bootstrap, Yum or APT. We are only covering installs for the most common server platforms like Red Hat, SUSE and Debian, though the SaltStack official documentation includes Solaris, ArchLinux, Ubuntu and even Windows.
Bootstrap: This is the easiest way and it takes care of dependency packages as well on any platform.
Download the required script:

wget --no-check-certificate -O install_salt.sh http://bootstrap.saltstack.org

Install the master:

sh install_salt.sh -M –N

Install the client:

sh install_salt.sh -A [Master’s IP or DNS Record]

Yum: Yum is platform-independent and is best when we use Red Hat or SUSE. It will install all the required dependencies.

Install the master:

yum install salt-master

Now, install the client:

yum install salt-minion

For SUSE, replacing Yum with Zypper should also work.

zypper addrepo http://download.opensuse.org/repositories/devel:languages:python/SLE_11_SP3/devel:languages:zypper refresh
zypper install salt salt-minion salt-master

APT: APT is best for Debian platforms and it takes care of all the dependencies as well.
Add the following to /etc/apt/sources.list

deb http://debian.saltstack.com/debian squeeze-saltstack main
deb http://backports.debian.org/debian-backports squeeze-backports main contrib non-free

And import the required key before installing the following:

wget -q -O- “http://debian.saltstack.com/debian-salt-team-joehealy.gpg.key” | apt-key add -
apt-get install salt-master
apt-get install salt-minion

TAR: This is the least preferred way because of the dependencies involved, but is do-able in the following way:

wget https://pypi.python.org/packages/source/s/salt/salt-2014.1.10.tar.gz --no-check-certificate
tar -zxvf salt-2014.1.10.tar.gz
cd salt-2014.1.10
python26 setup.py install
wget https://bootstrap.pypa.io/get-pip.py --no-check-certificate (for pip command for python26)

Dependencies for TAR: Using PIP or Source Tar, the following packages have to be installed for SaltStack and Python to go hand-in-hand:

yum install python26-jinja2.noarch python26-PyYAML python26-zmq.x86_64 python26-m2crypto.x86_64 python26-msgpack.x86_64 python26-crypto.x86_64 python26-PyYAML.x86_64
/usr/bin/pip2.6 install msgpack-pure
salt-master --versions-report

Salt: 2014.1.10
Python: 2.6.8 (unknown, Nov 7 2012, 14:47:45)
Jinja2: 2.5.5
M2Crypto: 0.21.1
msgpack-python: 0.1.12
msgpack-pure: 0.1.3
pycrypto: 2.3
PyYAML: 3.08
PyZMQ: 2.1.9
ZMQ: 2.1.9

Configuration
Master:

  • If it is a tar-based install, create the folder /etc/salt and copy the file conf/master from the Salt install folder to /etc/salt/master. In other cases, the file should be there by default.
  • By default, it will take the path /srv/salt and /srv/pillar as the base folders, if not mentioned. But still, we can go and uncomment the following lines in /etc/salt/master
    • file_roots:
    • base:
    • – /srv/salt
  • Run the command salt-master with a -d if you want to run it as a background daemon.

Client:

  • If it is a tar-based install, create the folder /etc/salt and copy the file conf/minion from the salt install folder to /etc/salt/minion. In other cases, the file should be there, by default.
  • Add <ip-address> salt salt.master.com to /etc/hosts. Only and only if DNS doesn’t have entry for the Salt master, do we need to add an entry here that resolves entries to the word ‘salt’.
  • Search for “#master:” in the file /etc/salt/minion; uncomment it before adding the name of the Salt master after the colon and saving the file.
  • Run the command salt-minion with a -d if you want to run it as a background daemon. This will send an authorisation request to the master.

Activation:

  • From the server, list the machines waiting for authorisation using:
    salt-key -L
  • To authorise a node, sign the respective node
    • salt-key -a ‘node-name’
    • salt-key -a (accepts all nodes)

Testing:

  • Run a test from the master to the client.
    • salt ‘*’ test.ping
    • which gives output as…
      • Node_name:
      • True

Uninstalling:

yum remove salt salt-master salt-minion (RedHat or SuSE)
zypper remove salt salt-master salt-minion (SuSE)
apt-get autoremove salt salt-master salt-minion (Debian, Ubuntu)

If we haven’t removed the untarred salt-tar folder, then a make clean must clean things up.

Resources
[1] http://salt.readthedocs.org/en/v0.9.2/topics/download.html
[2] http://docs.saltstack.com/en/latest/
[3] http://www.linuxjournal.com/content/getting-started-salt-stack-other-configuration-management-system-built-python

LEAVE A REPLY

Please enter your comment!
Please enter your name here