Hierarchical infrastructure description for your system management needs





The interactive transcript could not be loaded.


Rating is available when the video has been rented.
This feature is not available right now. Please try again later.
Published on Jan 17, 2014

Presenter(s): Martin Krafft
URL: https://lca2014.linux.org.au/schedule...

With modern system configuration management software, such as the popular Salt, Puppet, Chef, and Ansible, operators generally target configuration (behaviour) at hosts. In homogeneous environments, this makes sense, but when the environment is of heterogeneous nature, this approach quickly gets unmanageable.

If you maintain dozens and dozens of behavioral roles with only few nodes assigned to each, or if your infrastructure configuration special-cases hostnames, then rejoice, for here is help.

And even if your nodes come and go every day, and/or have numeric hostnames (aw!), here is an alternative paradigm to describe your infrastructure for consumption by the tools that manage your cloud or the machines in your rack.

reclass is a tool conceived during a massive migration from CFengine to Puppet, which received a complete rewrite in 2013 and is now faster, more predictable, more powerful and usable with Puppet, Salt and Ansible. Small adapters can be easily written (Python) to support other tools. reclass stands for "recursive external (node) classification".

reclass allows you to take a host-centric perspective of your infrastructure and mix and match behaviour in a hierarchical fashion, multiple inheritance included and encouraged.

reclass predates and inspired Hiera, and it's leaner and meaner. And written in Python, made to interface with whatever keeps your machines the way you want them.

Your webservers run Fedora while your mailservers are Debian machines, except one? Your nodes in Wellington should pull from a local distro mirror, while those in Perth should talk to Singapore, except three? And one webserver should listen on port 81 instead? All of those cases are one or two lines of YAML away.

reclass works by merging data during a recursive descent of a class hierarchy. Data in more specific classes overwrite data in more generic classes, naturally, and parameters may reference each other, independent of their position in the hierarchy. Recursive loops won't create galactic black holes.

How about pushing a backport to all your Debian oldstable nodes except those in Melbourne? Two lines of YAML...

reclass hooks into the provisioning systems and can serve them all, simultaneously, from the same database. This is very useful during step-wise migrations from one provisioning system to another, or when multiple systems are used in parallel, such as Salt and Ansible. If you need to reflect a change in your infrastructure, you do it once, only. In reclass.

And even with a single system, reclass allows you to keep everything in one place: roles, applications, parameters, and relationships. Defaults and exceptions, everything is tracked exactly in one place and exactly where you'd expect it.

You want port 4949/tcp open on all machines that the Munin server polls, without going back and forth between hosts and without time-delays? Use reclass!

I'll give a quick introduction to the concepts underlying reclass — which aren't hard to comprehend — and then put it to use, designing a fictitious use-case however complex the audience wants it to be, on the fly.

http://lca2014.linux.org.au - http://www.linux.org.au
CC BY-SA - http://creativecommons.org/licenses/b...


When autoplay is enabled, a suggested video will automatically play next.

Up next

to add this to Watch Later

Add to

Loading playlists...