I manage about 15 VMs in my home lab with OpenSource Puppet. Unlike Puppet Enterprise, there’s no Console to help you determine when agents stop checking in or encountering any problems applying their catalog. With only 15 agents it’s not a huge problem, but it always rears its head at the worst time. I decided to deploy Puppetboard at home to get a similar view to PE’s Console. As is always the way, we’re going to deploy that using a puppet module, Vox Pupuli’s puppet/puppetboard. Now, I’ve got Puppetboard running, but it’s served via HTTP and communicates with puppetdb via HTTP, so there’s room to improve. I’m not sure I’ll get to that, since this is on a private network, but something to keep in mind if you’re implementing this in a more sensitive deployment.

Special thanks to Tim Meusel for his assistance with some of the settings!

The first step is to add the module and its dependencies to the Puppetfile and .fixtures.yml. You may have a few of these modules already, but I’ve bumped them to the latest version.

# Puppetfile
mod 'puppet/puppetboard', '2.8.2'
mod 'puppetlabs/stdlib', '4.14.0'
mod 'puppetlabs/vcsrepo', '1.5.0'
mod 'stankevich/python', '1.18.2'

# .fixtures.yml
    stdlib:
      repo: "puppetlabs/stdlib"
      ref: "4.14.0"
    vcsrepo:
      repo: "puppetlabs/vcsrepo"
      ref: "1.5.0"
    python:
      repo: "stankevich/python"
      ref: "1.18.2"
    puppetboard:
      repo: "puppet/puppetboard"
      ref: "2.8.2"

Now we can make a profile class for it. We’ll configure it with hiera in a moment:

class profile::puppetboard {
  include apache
  include apache::mod::wsgi

  include puppetboard
  include puppetboard::apache::vhost

  firewall { '100 Puppetboard inbound':
    dport  => 80,
    proto  => tcp,
    action => accept,
  }
}

Here’s a spec test and a verrrrrry tiny hiera sample for this:

# spec/classes/puppetboard_spec.rb
require 'spec_helper'
describe 'profile::puppetboard', :type => :class do
  on_supported_os.each do |os, facts|
    let (:facts) {
      facts.merge(
        clientcert: 'puppetboard',
      )
    }

    let (:pre_condition) { "include apache" }

    context 'with defaults for all parameters' do
      it { is_expected.to create_class('profile::puppetboard') }

      it { is_expected.to contain_class('apache') }
      it { is_expected.to contain_class('apache::mod::wsgi') }
      it { is_expected.to contain_class('puppetboard') }
      it { is_expected.to contain_class('puppetboard::apache::vhost') }
      it { is_expected.to contain_firewall('100 Puppetboard inbound') }
    end
  end
end

# spec/fixtures/hieradata/puppetboard.yaml
---
puppetboard::apache::vhost::vhost_name: 'pboard.example.com'
puppetboard::apache::vhost::port: 80

You need to wrap this into a role. Mine is pretty simple:

class role::puppetboard {
  include profile::base
  include profile::puppetboard
}

Now, there’s some specifics you need to put in hiera. There are lots of options! Here are the ones I selected, with comments:

---
classes:
  role::puppetboard                                               # our role
puppetboard::offline_mode: true                                   # jquery and dependencies are bundled, not on the CDN
puppetboard::manage_git: true                                     # manage the git package
puppetboard::manage_virtualenv: true                              # manage the virtualenv package
puppetboard::apache::vhost::vhost_name: 'puppetboard.example.com' # hostname the puppetboard server responds at
puppetboard::apache::vhost::port: 80
python::dev: true                                                 # By default python-devel is uninstalled which is required for virtualenv, whoops
apache::mod::wsgi::wsgi_socket_prefix: '/var/run/wsgi'            # The readme says this is needed
puppetboard::puppetdb_host: 'puppet.example.com'                  # Hostname of the puppet master (unless this IS the master)
puppetboard::puppetdb_port: 8080                                  # Communicate with puppetdb on http (8080) or https (8081)

We can spin up your puppetboard VM and let it start provisioning itself via puppet. However, it won’t work too well without a few edits to the puppet master profile if that includes iptables. We just need to create a firewall rule in profile::puppet_master. Don’t forget to add a spec test for it!

firewall {'105 puppetdb inbound':
  dport  => 8080,
  proto  => tcp,
  action => accept,
}

The last thing we want to check is that the puppet master is collecting reports. I use jlambert121/puppet to manage my puppetserver and I had to change one line in my hiera config (I honestly have no idea why I set it this way to begin with):

 puppet::server_reports:
-  - 'none'
+  - 'puppetdb'

The master needs to run against the updated manifests and restart before it will collect reports and allow puppetboard to connect to puppetdb. Once everything is set up, go to http://puppetboard.example.com and you should see something like this:

You may remember that I said I had close to 15 nodes earlier. There’s only 6 reporting. This is why I wanted to set up puppetboard! Now I can review my VMs and get them all reporting, then look for failed nodes in here on a regular basis and fix things when they happen, not months later. I hope this helps you, as well!