DevOps Series – Automation with Puppet – Part3

Puppet Facts

Puppet facts are information pieces about the server on which it is running. The Puppet client using the Puppet facter command collects Puppet system details before sending them to the server. A sample of Puppet facts is shown below

Puppet Facts

# facter
architecture => x86_64
augeasversion => 1.0.0
boardmanufacturer => Dell Inc.
boardproductname => XXXX
domain => example.com
facterversion => 1.6.18
fqdn => web.example.com
hardwareisa => x86_64
hardwaremodel => x86_64
hostname => web
id => root
interfaces => em1,lo
ipaddress => X.X.X.X
ipaddress_lo => 127.0.0.1
is_virtual => false
kernel => Linux
kernelmajversion => 2.6
kernelrelease => 2.6.32-431.17.1.el6.x86_64
kernelversion => 2.6.32
macaddress => XX:XX:XX:XX:51:DF
macaddress_em1 => XX:XX:XX:XX:51:DF
...[SNIP]...
swapsize => 7.81 GB
timezone => PDT
type => Main Server Chassis
uptime => 31 days
uptime_days => 31
uptime_hours => 764
uptime_seconds => 2752287
virtual => physical

Puppet facts are extremely useful in writing Puppet code. They can be referenced in Puppet code as top-scope variables, which means outside any class definition, type definition, or node definition. In other words, Puppet facts are global variables. A sample fact reference is shown in below listing

if $hostname == 'web' {
        #some code here
}

You can also write your own custom facts. Facts are snippets of Ruby code that are distributed from the master to the clients. Custom facts that are needed by a module can be stored in<MODULEPATH>/<MODULE>/facts.d/ when using pluginsync. Another way to store facts is in the environment variable FACTERLIB, which refers to a path. Last, you can use the Ruby$LOAD_PATH variable in which to store facts. On most systems, it is/usr/lib/ruby/site_ruby/<version>/facter.

Facts have two parts to them: their name and the code. Facter.add('fact_name') is the way to set the name. Next follows the code, which is specified as setcode. Facts normally return a single string; however, they can also return a hash or an array. These are called structured facts. You don’t have to do anything special for a structured fact.

To enable structured facts, in a master/client setup, the stringify_facts variable must be set to false in puppet.conf. This should be set in both the master and agent puppet.conf file. On the master, it can be in the [master] section or in the [main] section. On the slave, it can be in the [main] or [agent] section.

Two custom facts are shown in below listing In the first case we are adding a custom fact calledperlpath. The path returns the location of Perl on the system. In the second case we are returning an array that contains network interfaces.

#Case 1
Facter.add(:perlpath) do
  setcode do
    'which perl'
  end
end

#Case 2
Facter.add(:int_array) do
  setcode do
   interfaces = Facter.value(:interfaces)
   int_array = interfaces.split(',')
   int_array
  end
end

Puppet Catalog

The Puppet server has to compile a catalog and send it back to the client after the client has contacted the Puppet master. Building the catalog is a four-step process:

1. Retrieve the node object

2. Set variables from the node object, from facts, and from the certificate

3. Evaluate the main manifest

4. Evaluate classes from the node object

So, exactly what does the Puppet agent provide to the server? The Puppet agent provides:

• Its hostname, which is almost always the certname — for instance,/production/catalog/www.example.com

• The agent certificate

• Agent facts

• The environment requested, which is embedded in the request URL (production is default)

After these data have been provided, it is up to the master to create a catalog. The catalog is a set of instructions for the client to execute. For instance, a catalog might ask the Puppet client to install Apache and configure it in a particular way.