classes and modules

The Puppet client software is called the agent. Puppet calls the definition of the host itself a node. The Puppet server is called the master.

Why do we need classes?

We don't want a huge /etc/puppet/manifests/site.pp file, and the files should be splitted into chunks of logically related code out into their own files, and then refer to those chunks by name when we need them.

"Classes are Puppet's way of separating out chunks of code, and modules are Puppet's way of organizing classes so that you can refer to them by name." - Learning Puppet - Modules and Classes

classes

Defining a class makes it available by name, but doesn't automatically evaluate the code inside it.
Before we can use a class, we must define it, which is done with the class keyword, a name, curly braces, and a block of code:
```
class my_class {
  ... puppet code ...
}
```
This manifest does nothing.
Declaring a class evaluates the code in the class, and applies all of its resources.
This one actually does something.
```
class my_class {
  ... puppet code ...
}
include my_class
```

class names

Class names must start with a lowercase letter, and can contain lowercase letters, numbers, and underscores. Class names can also use a double colon (::) as a namespace separator.

Class & Variable Scope

Each class definition introduces a new variable scope. Any variables we assign inside the class won't be accessible by their short names outside the class; to get at them from elsewhere, we have to use the fully-qualified name, e.g. $ntp::service_name, as shown in the example below (modules/ntp/manifests/init.pp):

class ntp {
      case $operatingsystem {
        centos, redhat: {
          $service_name = 'ntpd'
          $conf_file    = 'ntp.conf.el'
        }
        debian, ubuntu: {
          $service_name = 'ntp'
          $conf_file    = 'ntp.conf.debian'
        }
      }

      package { 'ntp':
        ensure => installed,
      }
      file { 'ntp.conf':
        path    => '/etc/ntp.conf',
        ensure  => file,
        require => Package['ntp'],
        source  => "/root/examples/answers/${conf_file}"
      }
      service { 'ntp':
        name      => $service_name,
        ensure    => running,
        enable    => true,
        subscribe => File['ntp.conf'],
      }
}

We can assign new, local values to variable names that were already used at top scope. For example, we could specify a new local value for $var.

define vs declaration

Defining makes a class available, and declaring evaluates it. We can see that in action by trying to apply our manifest in the previous section:

ubuntu@ip-172-31-45-62:/etc/puppet$ sudo puppet apply modules/ntp/manifests/init.pp
Notice: Compiled catalog for ip-172-31-45-62.ec2.internal in environment production in 0.02 seconds
Notice: Finished catalog run in 0.02 seconds

We can see it does nothing, because we only defined the class.

To declare a class, we should use the include function with the class's name:

node 'puppet-agent' {
  include ntp
  ...
}

Run puppet:

ubuntu@puppet-agent:~$ sudo puppet agent --test
Info: Retrieving plugin
Info: Caching catalog for puppet-agent.ec2.internal
Info: Applying configuration version '1419831895'
Notice: /Stage[main]/Exec/Exec[Run a command]/returns: executed successfully
Notice: Finished catalog run in 0.18 seconds

Modules

Now we know how to define and declare classes. We could have done everything in a single manifest (site.pp), but we actually splitted up our manifests into an easier to understand structure, and used manifests/site.pp.

node 'puppet-agent' {
  include ntp
  include nginx
  include user
  include sudoers
  include exec
  Exec {
    path => ['/bin', '/usr/bin'],
  }
}

By stowing the implementation of a feature in a module, our main manifest can become much smaller, more readable, and policy-focused - we can tell at a glance what will be configured on our nodes, and if we need implementation details on something, we can delve into the module.

Module Structure

A module is a directory.
The module's name must be the name of the directory.
It contains a manifests directory, which can contain any number of .pp files.
The manifests directory should always contain an init.pp file.
1. This file must contain a single class definition. The class's name must be the same as the module's name.