Puppet Fundamentals:Manifests and Resources

Puppet Fundamentals:Manifests and Resources

Manifests:

Puppet is driven by manifests, the equivalent of scripts or programs, written in Puppet's domain-specific language (DSL).
Let's start with the obligatory Hello, world! manifest:

# hello_world.pp
notify { 'Hello, world!':
}

To put the manifest to work, use the following command with root or with sudo . To control system processes, boot options, and the like, Puppet needs to be run with root privileges .

root@puppetmaster:~# puppet apply hello_world.pp
Notice: Compiled catalog for puppetmaster.example.net in environment production in 0.45 seconds
Notice: Hello, world!
Notice: /Stage[main]/Main/Notify[Hello, world!]/message: defined 'message' as 'Hello, world!'
Notice: Applied catalog in 0.03 seconds 

Let's interpret the above output:

Notice     => This keyword at the beginning of the line represents the log level. 

                          Other levels include Warning, Error, and Debug    

Main      => Default class where the resource was declared

Notify[Hello, world!] => This is the resource name

Puppet resources are idempotent—which means that every resource first compares the actual (system) with the desired (puppet) state and only initiates actions in case there is a difference. 


Resources and Attributes:

Resources are the elementary building blocks of manifests. Each has a type (in the above example , it is notify ) and a name or title (Hello, world! ). Each resource is unique to a manifest, and can be referenced by the combination of its type and name, such as Service["puppet"].

A resource also comprises a list of zero or more attributes. An attribute is a key-value pair, such as "enable => false" .  

Each resource type supports a specific set of attributes. Certain parameters are available for all resource types (metaparameters), and some names are just very common, such as ensure. The service type supports the ensure property, which represents the status of the managed process. Its enabled property, on the other hand, relates to the system boot configuration.

Let's look at a parameter:

service { 'puppet':
  ensure   => 'stopped',
  enable   =>  false,
  provider => 'upstart',
}

The provider parameter tells Puppet that it needs to interact with the upstart

subsystem to control its background service, as opposed to systemd or init. 

The difference between parameters and properties is that the parameter merely

indicates how Puppet should manage the resource, not what a desired state is. Puppet 
will only take action on property values.

In this example,these are ensure => 'stopped' and enable => false. For each such property,

Puppet will perform the following tasks:

• Test whether the resource is already in sync with the target state
• If the resource is not in sync, it will trigger a sync action 

Puppet also allows you to read your existing system state by using the puppet resource command:

# puppet resource user root
user { 'root':
  ensure            => 'present',
  comment           => 'root',
  gid               => '0',
  home              => '/root',
  password          => '$6$lSPI38zs$nleaV3N7MkG...........SMOc4NcI/7GU/hK2DnKb/',
  password_max_age  => '99999',
  password_min_age  => '0',
  shell             => '/bin/bash',
  uid               => '0',
}
 
 Dry Run:

 Instead of Applying manifests , we can do dry-run as follows:

     # puppet apply hello_world.pp --noop