CM or configuration management is common terminology in the software industry. For those of us who do not know what it is, its 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 http://www.opensourceforu.com/tag/puppet/ must surely know about configuration management by now, at least from a Puppet perspective. But dont worry if you dont know too much; one can always learn.
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 executionruns 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:
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 Djangos 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.
We can install SaltStack by three methodsBootstrap, 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 [Masters 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
- 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
• – /srv/salt
- Run the command salt-master with a -d if you want to run it as a background daemon.
- 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 doesnt 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.
- From the server, list the machines waiting for authorisation using:
- To authorise a node, sign the respective node
- salt-key -a node-name
- salt-key -a (accepts all nodes)
- Run a test from the master to the client.
- salt * test.ping
- which gives output as
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 havent removed the untarred salt-tar folder, then a make clean must clean things up.
The author is currently working as a Perl/Gnu/Linux/DevOps Admin with Servista Inc, Irvine, California, USA. He is a Free Software enthusiast since the Y2K bug era. He can be contacted at email@example.com