We've written our fair share of Puppet modules during this book. We even explored some good patterns to use in doing so. However, there are several things we just touched on that should be explored further, such as testing. Additionally, we'll point out some other general resources that will help you on your way.

Puppet modules and data in Hiera should be considered code, just as any other part of your system. As such, they should be tested thoroughly to ensure that they operate properly. The prevailing method of doing that is using rspec with a number of plugins.

The first project is rspec-puppet. We use rspec-puppet to create behavior-driven tests of our Puppet manifests. These test the catalog to ensure that the things we are expecting to happen end up in the catalog. This also has a pleasant side effect of compiling the catalog when we run them, so it catches any silly syntax errors. More information on rspec can be found at http://rspec.info/, and on rspec-puppet at http://rspec-puppet.com/.

The second useful project for testing is beaker and the beaker-rspec gem. Beaker is an acceptance testing system that can use Vagrant or any number of other systems to provision systems for testing. Along with the beaker-rspec plugin, beaker can be used to write rspec tests that describe the state of the system. That is, Puppet runs and then rspec validates it. It actually did what you expected it to do on the system. This can sometimes vary from what you thought Puppet was going to do in the catalog.

In addition to testing, there are a handful of patterns that are considered useful when developing modules. We already covered several patterns earlier in the book, such as the roles and profiles pattern. The Puppet Labs documentation contains a wealth of good resources on good module development. For more information on this, see https://docs.puppetlabs.com/guides/module_guides/bgtm.html.

Finally, there are a number of good books available on Puppet, and especially module writing. Extending Puppet (https://www.packtpub.com/networking-and-servers/extending-puppet), Alessandro Franceschi, Packt Publishing is a resource written by a very experienced community member with a large amount of experience writing reusable modules that are available to the public.

In the past handful of years, there have been a number of initiatives to use Puppet on devices other than actual computers. The first iteration of this came back in 2011 with the release of support for managing F5 load balancers. Additional community support exists for a variety of devices, such as Cisco switches and routers. With some work, this model can even be extended to managing firewalls. Imagine getting all of the same auditing benefits from Puppet being applied to your network devices.

The device management solution uses the concept of a proxy host that serves as an intermediary between the host systems and the devices being managed. This proxy host turns the device configuration into resources and then sends the changes back to the device to keep them in sync. The proxy host could be the Puppet Master, or any node managed by Puppet and does not require additional software.

More information for the base device information can be found at https://docs.puppetlabs.com/references/latest/man/device.html, as well as for the f5 module at https://forge.puppetlabs.com/puppetlabs/f5 and for Cisco switch management at https://forge.puppetlabs.com/mburger/networkdevice.

The growing trend, however, seems to be running Puppet natively on the devices. Cisco and Juniper both support some methods of running the Puppet agent on devices for at least some of their lines. Cisco uses a container that runs Puppet and can communicate with the host, while Juniper has native packages for their routers running newer versions of Junos.

This has the advantage of being a simpler configuration, since it does not require the proxy hosts. Additionally, since the agent is tightly coupled with the device, there is better support for that specific device in the agent.

A brief introduction to the Cisco method of on-device management can be found in the PuppetConf talk at http://puppetlabs.com/presentations/managing-cisco-devices-using-puppet. Information on using Puppet on Junos can be found at http://puppetlabs.com/solutions/juniper-networks.

We dedicated a chapter to explore reporting in Puppet, but largely focused on internal tools that can help you do reporting.

There exists a good reference book for reporting in Puppet specifically, which is Puppet Reporting and Monitoring at https://www.packtpub.com/networking-and-servers/puppet-reporting-and-monitoring by Michael Duffy (full disclosure—I was a technical reviewer of this book). It covers many of the Puppet reporting topics in much greater detail than we can afford to do here.

We will, however, point out a couple of resources available that can help with reporting out of the box. These resources are Puppetboard and The Foreman.

Puppetboard is a web-based user interface that replaces the Puppet Dashboard, which was officially moved to community support. It provides an interface into the status of your Puppet runs, as well as a nice browser that lets you browse facts on your hosts and other such things. We wrote the custom code to provide reporting solutions for several of the problems in the reporting chapter, which can be run natively in Puppetboard.

Puppetboard relies on PuppetDB being installed as it uses it as the data backend. It uses data from PuppetDB to build rich dashboards with information about your systems.

More information on Puppetboard can be found at https://github.com/puppet-community/puppetboard.

Another good reporting-related tool for one to review is The Foreman. The Foreman is more than just a reporting tool. It aims to be a complete life cycle management tool that provisions your systems and then works with Puppet to configure them. It can even serve as an external node classifier that holds information about what classes get applied to a node.

In addition to this, The Foreman contains reporting features on nodes similar to those of Puppetboard. It can show trends in systems by type, show systems not completing Puppet runs, and so on.

More information on The Foreman can be found at http://theforeman.org/.

These are not the only reporting engines available for Puppet. Other options, such as Puppet Explorer exist at https://github.com/spotify/puppetexplorer and more are added everyday.

Finally, don't forget Kibana. By bringing your log data into Logstash, you can use Kibana to create reports. You can even configure Logstash to send certain events straight to an alerting system to alert on certain values. This can be used to build reporting, as well as any of the previously mentioned software packages.

There are a few other Puppet-related tools that don't really fit elsewhere, so we're going to talk about them briefly here.

The first such tool is Puppet Enterprise. In a security role, it may be important for you to have certified supported configurations for the tools managing your environment. Puppet Enterprise offers this, as well as additional features and capabilities not present in the base open source system.

Puppet Enterprise contains prebuilt, self-contained, packages for a large variety of operating systems. This includes all of the expected Linux variants, as well as other operating systems, such as AIX and Solaris. This can make it much easier to deploy Puppet on systems that it might otherwise be difficult to get a modern version of Ruby on.

On top of that, Puppet Enterprise contains a powerful dashboard that permits reporting, as well as system configuration. It serves as a node classifier, so if you use the roles and profiles pattern, for instance, you can apply profiles to the system straight from the Puppet Enterprise management dashboard.

More information on Puppet Enterprise can be found at http://puppetlabs.com/puppet/puppet-enterprise.

Another new item of the Puppet community is Puppet Server. This is a new rewrite of the Puppet Master in Clojure that runs on the JVM. The system then uses JRuby to run all of the existing Puppet code. This allows you to continue to write your types in providers in Ruby, while using the proven power of the JVM to increase the performance. This allows the Puppet Master to take advantage of things, such as multithreading and a much better garbage collection system. It also simplifies the configuration over the old method of using Apache and Passenger.

This, of course, comes at the cost of running the master in the JVM. That may give a certain amount of people cause for concern as they have previous bad experiences with Java-based applications. However, from a security standpoint, the JVM is a well-understood machine. Many more systems run in the JVM than run under Apache with Passenger. In the end, this is an adjustment in the server running the core Puppet Server and not a huge shift in paradigm.

Puppet Enterprise 3.7 is the first version to use this new Java-based Puppet Server.

More information on Puppet Server can be found at http://puppetlabs.com/blog/puppet-server-bringing-soa-to-a-puppet-master-near-you.

Finally, it should be mentioned that the core Puppet software is also improving. Version 4 is about to be released that will contain a new parser and a good amount of new functionalities. It's going to bring with it, the ability to solve a certain class of problems easier, with tools such as iteration, which are missing in Puppet today.

If you want to try some of these new features out today, you can use the future parser. This is the parser that is being worked on for Puppet 4. More information on the future parser can be found at https://docs.puppetlabs.com/puppet/latest/reference/experiments_future.html, and a presentation on Puppet 4 at http://puppetlabs.com/presentations/future-goals-puppet-4-andrew-parker-puppet-labs-kylo-ginsberg.

No book would be complete without the mention of the excellent Puppet community. One of the reasons Puppet has been successful is because the community members are top notch and very helpful. We'll explore a few of the community resources available to you if you need assistance.

The first resource can be found at http://ask.puppetlabs.com site. This site is a place where users can go to post questions for the community to answer. It is in the style of various other question and answer sites. As your knowledge of Puppet increases, you can earn badges to help other users out, with questions they might have.

A second resource is the Puppet mailing lists. These lists are hosted at Google Groups. Lists exist for users and development efforts. A reasonable amount of discussion concerning future development and direction of Puppet takes place on the lists. This is a good place to read about development of new patterns and discussions on the future of Puppet. It is also a great place to go to ask questions if you get stuck with a problem. You can find the Puppet Users list at https://groups.google.com/forum/#!forum/puppet-users.

Finally, there is a page that discusses general community. There are many other community-based events available, including the Puppet Users groups in some cities, Puppet Camps that are smaller regional conferences, and the giant PuppetConf that draws thousands of Puppet users to one place. Additionally, there is an IRC channel available for use in asking questions in a more real-time fashion. Information on all of these resources can be found at http://puppetlabs.com/community/get-help.