Puppet Labs released Facter 1.7 this week, introducing a number of under-the-hood enhancements and a new feature called “external facts” that’s been waiting in the wings for about a year now.
Facter is a cross-platform library for gathering information about nodes managed by Puppet, including domain names, IP addresses, operating systems, Linux distributions, and more. External facts provide a simple way for a puppet agent to provide custom facts without having to write Ruby. Eric Sorenson, Puppet’s open source product owner, told me, “they’re probably the easiest way for people to get an entry into Puppet for extending Puppet or customizing Puppet for their own site.”
Purpose | Build Java keystores form existing keys and certificates. |
Module | puppet/java_ks |
Puppet Version | 2.7+ |
Platforms | OpenJDK 6, OpenJDK 7 |
This module attempts to ease and shorten the workflow associated with Java applications.
The reason this module came to life was my frustration over the workflow needed to get a SSL protected ActiveMQ broker set up. When I wanted to integrate the Java keystore build workflow into the rest of ActiveMQ’s setup using a Puppet manifest… well, it got ugly. Converting a string of shell commands into Puppet exec resources eventually led me to a dark dark place. Personally I find that if you are running into a need for a lot of exec resources, especially when they are using the same command or operating on the same file, it is time to grab a copy of Puppet Types and Providers and get your hands dirty with some Ruby. You’ll usually notice a speed increase of your agent runs after a conversion to a type/provider to replace all the exec resources and always end up with easier to maintain manifests.
One of the major interfaces to extend functionality with Puppet is the use of Facter and custom facts. A fact is a key/value data pair that represents some aspect of node state, such as its IP address, uptime, operating system, or whether it’s a virtual machine. Custom facts are able to provide catalog compile time data to the puppet master to customise the configurations for a specific node (using PuppetDB, this data becomes available even when you’re doing things elsewhere). Facts are provided by Facter, an independent, cross-platform Ruby library designed to gather information on all the nodes you will be managing with Puppet.
For an example of using a custom fact within Puppet, you can use this data in the context of a catalog compile to make a decision about the catalog that you sent back to the node. A fact that tells us the node’s operating system could cause some conditional logic in a class that tells the node the right set of packages to use to configure ntp on that particular system. Because the package names differ between Linuxes (let alone between Linux and Windows), this fact simplifies ntp configuration. Alternatively, you could use the $::ipaddress fact to customise the appropriate listen directive in Apache or SSH.
Purpose | Helps you automate the management of VMware Tools. |
Module | rasorsedge/vmwaretools (v4.1.1 tested) |
Puppet Version | Tested on 2.7+ (Puppet Enterprise 2.0+) |
Platforms | RHEL, CentOS, SUSE, OEL (post written with CentOS) |
In a previous MOTW, I covered what problem this module solves and addressed a very simple workflow for using the module to manage VMware Tools.
This time, I’m going to dive into how the module is structured and explore some of the more advanced things you can do with it.
A long time ago (well, June of this year) the Puppet Forge was running without a leader. In my role as community manager, I saw the Forge as having this awesome potential to be the resource for user-generated content surrounding the Puppet community. I knew it was getting more attention, but that was mostly anecdotal. My next step was to find some data that could tell a good story.
Puppet Modules are often the first way people learn and start using Puppet. We’ve had our Puppet Forge for a while, but I didn’t feel like I knew a lot about it. When we were getting ready to interview Product Owners for the Puppet Forge and Modules, I decided I wanted to know more to help me prepare for the interview, and maybe give me some insight into usage patterns that I hadn’t thought about.
Like any geek, I love data. I knew we had all sorts of data in our module download logs, but we had not ever really taken the time to transform that data into awesome information. I started with simple awk/sed/grep to find basic information, like what modules were popular. This worked for a time, but then I wanted to know modules by name, find popular authors, and do things like ignore version number changes.
Purpose | Fetch and update file data from an S3 bucket |
Module | branan/s3file |
Puppet Version | 2.7+ |
Platforms | All, but see ‘Advanced Usage’ for non-Linux |
Puppet and Puppet Enterprise come with a basic file server, allowing agents to fetch files from the master. This capability is suitable for small files, but when used with large binaries it can cause performance issues on the master.
S3file provides a simple Puppet type to fetch and update files stored in an Amazon S3 bucket or in your private OpenStack Swift storage environment. This allows you to store large files outside of Puppet, while still keeping the resource model provided by the existing Puppet file types.
S3file is written to be compatible with the old Puppet 2.7 as well as the latest Puppet 3.0, making it easy to integrate with any Puppet deployment.
This week’s Module of the Week is a guest post from Carlos Sanchez from MaestroDev.
Purpose | Manage Apache Maven installation and download artifacts from Maven repositories |
Module | maestrodev/maven |
Puppet Version | 2.7+ |
Platforms | RHEL5, RHEL6 |
The maven module allows Puppet users to install and configure Apache Maven, the build and project management tool, as well as easily use dependencies from Maven repositories.
If you use Maven repositories to store the artifacts resulting from your development process, whether you use Maven, Ivy, Gradle or any other tool capable of pushing builds to Maven repositories, this module defines a new maven type that will let you deploy those artifacts into any Puppet managed server. For instance, you can deploy WAR files directly from your Maven repository by just using their groupId, artifactId and version, bridging development and provisioning without any extra steps or packaging like RPMs or debs.
The maven type allows you to easily provision servers during development by using SNAPSHOT versions—using the latest build for provisioning. Together with a CI tool, this enables you to always keep your development servers up to date.