Hieratic – a new way to use Puppet and Hiera

Today I’m announcing the release of Hieratic, a new Puppet module designed to improve the integration between Puppet and Hiera.

Hiera tries to improve Puppet by taking site specific data out of manifests. Hiera makes it possible (and even easy) to define complex sites by making general configurations and then defining only the differences between each node. This can be done on a very granular (and configurable) level. If you haven’t played with Hiera yet take a minute to read through it’s overview and bask in the awesome.

As much as I love it though Hiera is not without flaws. Since it wasn’t shipped by default in Puppet until 3.0 many modules do not have built in support for it. Automatic Parameter Lookup partially solves this problem, but has some serious limitations that significantly reduces it’s usefulness- the biggest being that it is incapable of merging values from multiple levels and only provides the highest priority items.

Hieratic solves this problem. It lets you define a variety of a resources, including classes, while still allowing deep merging to occur. With Hieratic it’s possible to completely separate Puppet code from configuration.

To use the Hieratic module you simply have to declare the class. Your site.pp file can include a single line and be completely functional-

class {'hieratic':}

From there you can include classes, packages, users, or any of a number of resources in Hiera.

Here, for instance, we load the SSH module using Hiera and Hieratic with a generic configuration that can be used by all nodes by filling our common.yaml file with this.

---
class:
 "ssh":
    "server_options":
      Protocol: "2"
      PermitRootLogin: "no"
      PubkeyAuthentication: "yes"
      PasswordAuthentication: "no"
      UsePAM: "no"
      Port:
        - 5022
      AllowGroups:
        - admin

group:
  admin:
    name: "admin"
    ensure: "present"

firewall:
  '222 accept ssh traffic':
    proto: "tcp"
    dport: "222"
    action: "accept"

Suppose we want to test our puppet modules using vagrant? We can make a hierarchy level that uses the ::virtual fact to load a virtualbox.yaml file (assuming VirtualBox is your provider) that has our custom configuration:

---
class:
  "ssh":
    storeconfigs_enabled: false
    server_options:
      Port:
        - 22
      AllowGroups:
        - vagrant

group:
  admin:
    name: "vagrant"
    ensure: "present"


firewall:
  "022 accept ssh traffic":
    proto: "tcp"
    dport: "22"
    action: "accept"

Now when systems are loaded from vagrant ssh will be accessible using 'vagrant ssh' and provisioning scripts will continue to work. SSH will use both ports 5022 and 22, having combined the data from both files. On production systems the vagrant settings will not be there.

That's just a simple example- it's possible to control just about everything using Hieratic. Out of the box Hieratic supports a number of resource types (96, to be exact, from 14 modules plus the native Puppet resources) and any arbitrary class, and it does so with a variety of parameters to customize behavior.