cowley-tech/content/blog/how-i-classify-puppet-nodes/index.md

---
date: 2015-09-10
title: How I Classify Puppet Nodes
category: devops
---

The basics of defining what modules get applied to a particular node is
really simple in Puppet. Out of the box you just use the hostname and
the FQDN and everyone is happy. You find this everywhere in
documentation, blog posts, presentations, etc. However is has a problem:
scale.

What if you have an elastic infrastructure with nodes being created and
destroyed automatically? What if you want to use the same manifests in
different environment, but use different hostnames? What if you have
stupidly complex host naming conventions that you cannot get your head
round (current day job problem for me :-( )?

In all these cases and more, using the hostname to classify the node
falls down. I like to add in Role that can then be access in 2 ways.
With Hiera, one could do something like:

```
:hierarchy:
  - "nodes/%{::trusted.certname}"
  - "roles/%{role}"
  - "%{environment}"
  - "%{osfamily}-osreleasemajor"
  - global
```

And with in `site.pp` we can add in a simple `case` statement:

```
node default {
  case $::role {
    'loadbalancer': {
      class { 'haproxy': }
    }
    'db': {
      class { 'mysql': }
    }
    default: {
      notify('no specific classes assigned')
    }
  }
  class { 'security': }
}
```

Now, we can still classify nodes individually but there is something in
between the wider environment and OS categories that we can define
ourselves. Of course we now need to define the role, which is everywhere
from simple to complex or even not completely clear in my head for now.

I create a custom role fact that my manifests will look at. This is
universal, no matter what mechanism is used to populate that fact that
is the only place I will search in my Puppet code.

When your nodes are under Openstack or EC2, this is simple. They both
have the concept of user-defined metadata as key-value pairs. I simple
add a role pair:

```
nova meta <instance-id> set role=loadbalancer
```

You can also set this when you create the instance.

```
nova boot --meta role=loadbalancer --<other-settings> <hostname>
```

Now we just need the fact to look it up.

```
require 'net/http'
require 'json'
require 'uri'

module RoleModule
  def self.add_facts
    Facter.add("role") do
      productname = Facter.value(:productname)
      case productname
      when 'OpenStack Nova'
        setcode do
          url= "http://169.254.169.254/openstack/latest/meta_data.json"
          uri = URI.parse(url)
          http = Net::HTTP.new(uri.host,uri.port)
          response = http.get(uri.path)
          JSON.parse(response.body)['meta']['role']
        end
      when 'ProLiant MicroServer'
        setcode do
          'lab-compute'
        end
      end
    end
  end
end
RoleModule.add_facts
```

What is happening here? First it checks the productname fact so it can
work out what to do. If that is OpenStack Nova then it knows that is
needs to look in the Openstack Metadata service
(<http://169.254.169.254/openstack/latest/meta_data.json>). Our
key/value pair is returned as part of that JSON data and is pushed in to
the role fact.

Likewise, if the productname is an HP Microserver, it will always be a
lab compute node (in my case).

Physical machines otherwise fall down here. There is no way to
dynamically modify their role, but I have a couple of solutions:

-   Part of the kickstart file for provisioning the node could populate
    a configuration file (`/etc/role.conf`). If the `virtual` fact
    contains `physical` the role fact goes and looks it up from there.
-   A seperate node classification service that returns a role based on
    the contents of various facts that are passed via the custom fact
    code.

The important part with both of these is the classification is totally
seperate from my Puppet code.