A Peek into the Ruby Part of Puppet - Facts, Types, and Providers

So far in this book, you have primarily done practical things - writing manifests, setting up a master, assigning agents, signing certificates, and so forth. Before you are introduced to the missing language concepts that you will need to use Puppet effectively for bigger projects, there is some background that we should cover. Don't worry, it won't be all dry theory - most of the important parts of Puppet are relevant to your daily business.

The topics of this chapter have been hinted at earlier; Chapter 1, Writing Your First Manifests, contained a brief description of the type and provider. This and some adjacent topics will be thoroughly explored in the sections collecting system information with Facter, understanding the type system, and command execution control with providers.

...

Putting it all together - collecting system information with Facter

Configuration management is quite a dynamic problem. In other words, the systems that need configuration are mostly moving targets. In some situations, system administrators or operators get lucky and work with large quantities of 100 percent uniform hardware and software. In most cases, however, the landscape of servers and other computing nodes is rather heterogeneous, at least in subtle ways. Even in unified networks, there are likely multiple generations of machines or operating systems, with smaller or larger differences required for their respective configurations.

For example, a common task for Puppet is to handle the configuration of system monitoring. Your business logic will likely dictate warning thresholds for gauges such as the system load value. However, those thresholds can rarely be static. On...

Accessing and using fact values

You have already seen the use of the processors fact in an example. In the manifest, each fact value is available as a global variable value. That is why you can just use the ::processors expression where you need it.

You will often see conventional uses such as $::processors['count'] or $::networking[‘ip’]. Prefixing the fact name with double colons is highly recommended. The official style guide at https://docs.puppetlabs.com/guides/style_guide.html#namespacing-variables recommends this. The prefix indicates that you are referring to a variable delivered from Facter. Facter variables are put into the Puppet master's top scope.

Some helpful facts have already been mentioned. The processors fact might play a role for your configuration. When configuring some services, you will want to use the machine's networking...

Extending Facter with custom facts

Technically, nothing is stopping you from adding your own fact code right next to the core facts, either by maintaining your own Facter package, or even by deploying the Ruby code files to your agents directly through Puppet management. However, Puppet offers a much more convenient alternative in the form of custom facts.

We have still not covered Puppet modules yet. They will be thoroughly introduced in Chapter 5, Combining Classes, Configuration Files, and Extensions into Modules. For now, just create a Ruby file at /etc/puppetlabs/code/environments/production/modules/hello_world/lib/facter/hello.rb on the master machine. Puppet will recognize this as a custom fact of the name, hello. (For Puppet 3 or older versions, the path should be /etc/puppet/modules/hello_world/lib/facter/hello.rb.)

The inner workings of Facter are very straightforward...

Simplifying things using external facts

If writing and maintaining Ruby code is not desirable in your team for any reason, you might prefer to use an alternative that allows shell scripts, or really any kind of programming language, or even static data with no programming involved at all. Facter allows this in the form of external facts.

Creating an external fact is similar to the process used for regular custom facts, with the following distinctions:

• External facts are produced by standalone executables or files with static data, which the agent must find in /etc/puppetlabs/facter/facts.d/
• The data is not just a string value, but an arbitrary number of key=value pairs instead

The data need not use the ini file notation style; the key/value pairs can also be in the YAML or JSON format. The following external facts hold the same data:

# site-facts.txt
workgroup='CT4Site2...

Goals of Facter

The whole structure and philosophy of Facter serves the goal of allowing for platform-agnostic usage and development. The same collection of facts (roughly) is available on all supported platforms. This allows Puppet users to keep a coherent development style throughout their manifests for all those different systems.

Facter forms a layer of abstraction over the characteristics of both hardware and software. It is an important piece of Puppet's platform-independent architecture. Another feature that was mentioned before is the type and provider subsystem. Types and providers are explored in greater detail in the following sections.

Understanding the type system

Being one of the cornerstones of the Puppet...

The resource type's life cycle on the agent side

Once the compilation has succeeded, the master hands out the catalog and the agent enters the catalog validation phase. Each resource type can define some Ruby methods that ensure that the passed values make sense. This happens on two levels of granularity: Each attribute can validate its input value, and then the resource as a whole can be checked for consistency.

One example of attribute value validation can be found in the ssh_authorized_key resource type. A resource of this type fails if its key value contains a whitespace character because SSH keys cannot comprise multiple strings.

Validation of whole resources happens with the cron type, for example. It makes sure that the time fields make sense together. The following resource would not pass, because special times, such as midgnight, cannot be combined with numeric fields...

Command execution control with providers

At the start of this chapter, you learned about Facter and how it works as a layer of abstraction over the supported platforms. This unified information base is one of Puppet's most important means of achieving its goal of operating system independence. Another one is the DSL, of course. Finally, Puppet also needs a method to transparently adapt its behavior to the respective platform on which each agent runs.

In other words, depending on the characteristics of the computing environment, the agent needs to switch between different implementations for its resources. This is not unlike object oriented programming-the type system provides a unified interface, not unlike an abstract base class. The programmer need not worry what specific class is being referenced, as long as it correctly implements all the required methods. In this analogy...

Summarizing types and providers

Puppet's resource types and their providers work together to form a solid abstraction layer over software configuration details. The type system is an extendable basis for Puppet's powerful DSL. It forms an elaborate interface for the polymorphous provider layer.

The providers flexibly implement the actual management actions that Puppet is supposed to perform. They map the necessary synchronization steps to commands and system interactions. Many providers cannot satisfy every nuance that the resource type models. The feature system takes care of these disparities in a transparent fashion.

Putting it all together

Reading this far, you might have gotten the impression that this chapter...

Summary

Puppet gathers information about all agent systems using Facter. The information base consists of a large number of independent bits, called facts. Manifests can query the values of those facts to adapt to the respective agents that trigger their compilation. Puppet also uses facts to choose among providers, the work horses that make the abstract resource types functional across the wide range of supported platforms.

The resource types not only completely define the interface that Puppet exposes in the DSL, they also take care of all the validation of input values, transformations that must be performed before handing values to the providers, and other related tasks.

The providers encapsulate all knowledge of actual operating systems and their respective toolchains. They implement the functionality that the resource types describe. The Puppet model's configurations...