Thomas Martin I/O

Programming, Sysadmin, Open Source

Infrastructure management using Salt and Reclass

2014-11-20 SYSADMIN SALT RECLASS CFGMGMT


Adding a pinch of Reclass to Salt

Some times ago I talked about Reclass, a kind of software called an External Node Classifier (see Nodes inventory using reclass). It's a very useful tool to keep an inventory of all the components which are parts of a computer infrastructure, along with their properties (servers, network equipments, storage, etc). All of this in YAML-formatted plain text.

But of course, where Reclass helps a lot is in interaction with a configuration management tool. In my case, it's Salt, but I'm sure you've already guessed.

And good news, the authors of these two software have already done all the work to help them communicate. Each one is supplied with modules for interacting with the other.

So, what are the Salt subsystems able to consume the Reclass database ? There are two : Topfile and Pillar.

Topfile

Salt associates states to hosts using what is called the topfile. Reclass enumerates software components associated to a node, in a applications list.

So yes, Salt is able to retrieve states for each host by querying Reclass applications instead of the traditional top.sls file.

For that, there is a subsystem called the Master Tops System. It allows to plug Python modules in charge to retrieve states list from arbitrary sources. In our case, the salt.tops.reclass_adapter is shipped by default (On Debian : /usr/share/pyshared/salt/tops/reclass_adapter.py).

In conclusion, for a given node/host : Salt states <=> Reclass applications.

Pillar

Salt can associate key/values data to each minion using the Pillar subsystem. The standard way of storing Pillars is in a YAML file. Reclass do the same using parameters associated to nodes.

So yes, using the External Pillars feature, Salt can retrieve pillar data from Reclass parameters.

For that, the salt.pillar.reclass_adapter is needed and shipped by default (on Debian : /usr/share/pyshared/salt/pillar/reclass_adapter.py).

In conclusion, for a given node/host : Salt pillars <=> Reclass parameters.

Technical steps

This section assumes Salt and Reclass are installed. This setup has been tested using Debian 7.0, Reclass 1.3, Python 2.7, and Salt 2014.1.11. The Reclass inventory is located in /srv/inventory, populated with at least one host called node1 containing some applications and parameters (see Adding nodes in my previous post). Note that it is preferable to have a working Salt setup (with topfile and pillar), before trying to add the Reclass layer.

Salt adapter

Reclass provides a python module in charge of converting Reclass data to Salt data structure. This module could be directly invoked as a shell command and is useful for debugging purposes. So, this convenient symlink can be created to be able to call it easily :

ln -s /usr/share/pyshared/reclass/adapters/salt.py /usr/local/sbin/salt-reclass
chmod +x /usr/share/pyshared/reclass/adapters/salt.py

Then, this command should output a JSON-formatted Salt topfile :

salt-reclass --top

This one outputs a JSON-formatted pillar data structure for the node node1 :

salt-reclass --pillar node1

Salt master

Add the following configuration to the /etc/salt/master file :

reclass: &reclass
    inventory_base_uri: /srv/inventory

ext_pillar:
    - reclass: *reclass

master_tops:
  reclass: *reclass

It defines a global configuration for Reclass, then apply it for both Pillar and Topfile querying.

Important : at this point, the top.sls file should now be removed from the Salt root. According to the documentation :

When using ext_pillar and/or master_tops, you should make sure that your file_roots paths do not contain a top.sls file. Even though they ought to be able to coexist, there are a few sharp edges around at the moment, so beware!

Final test

Now it's time to validate the setup ! Restart salt-master, then execute the following commands on the node1 minion, and celebrate the fact that the data now comes from the reclass inventory :

salt-call state.show_top
salt-call pillar.items

Conclusion

Reclass + Salt is a very powerful setup.

But... what prevent Salt to handle all of that itself ? I see several reasons :

  • Cannot easily introspect the hosts list and their corresponding states (these informations could be useful to feed other software, like Nagios for example).
  • Information are scattered among two locations : topfile and pillars. Reclass allows to know all about a node with a single glance over the corresponding file.
  • No inheritance mechanism for the pillars. Currently, Pillar namespaces can be merged, but no conflicting keys should be present.

I think it would be a great improvement if Salt could act as a complete ENC like Reclass. Of course, it's a good thing to be able to connect Salt to different kind of ENC, but an integrated one could make the things simpler for a basic usage. Seems to be a great contribution challenge to the project !