Manifests

Manifests

Puppet programs are called “manifests,” and they use the .pp file extension.
The core of the Puppet language is the resource declaration. A resource declaration describes a desired state for one resource.
(Manifests can also use various kinds of logic: conditional statements, collections of resources, functions to generate text, etc. We’ll get to these later.)

[root@server demo_manifests]# cat add_user.pp
user { 'optimus':
  ensure => 'present',
  home   => '/home/optimus',
  shell  => '/bin/bash',
}
[root@server demo_manifests]#

[root@server demo_manifests]# puppet apply /root/Desktop/demo_manifests/add_user.pp
notice: /Stage[main]//User[optimus]/ensure: created
notice: Finished catalog run in 0.21 seconds
[root@server demo_manifests]#

Puppet Apply

Like resource in the last chapter, apply is a Puppet subcommand. It takes the name of a manifest file as its argument, and enforces the desired state described in the manifest.

[root@server demo_manifests]# cat add_file.pp
file {'testfile':
    path    => '/tmp/testfile',
    ensure    => present,
    mode    => 0640,
    content => "Testfile, please ignore.",
}
[root@server demo_manifests]#

Change something is the test file and then fire the same command again, what it will do is change the content of the file to the desired state.

 [root@server demo_manifests]# puppet apply add_file.pp
notice: /Stage[main]//File[testfile]/content: content changed '{md5}e2c1101ee90533ae9c917e47f1dbb4d8' to '{md5}c562bd5b4f66e53bca1755f95c30dab1'
notice: Finished catalog run in 0.11 seconds
[root@server demo_manifests]#

Resource Declarations

Let’s start by looking at a single resource:

    file {'testfile':
      path    => '/tmp/testfile',
      ensure  => present,
      mode    => 0640,
      content => "I'm a test file.",
    }

In short, they consist of:

• The type (file, in this case)
• An opening curly brace ({)
  • The title (testfile)
  • A colon (:)
  • A set of attribute => value pairs, with a comma after each pair (path => '/tmp/testfile', etc.)
• A closing curly brace (})

 [root@server demo_manifests]# cat multiple_resource_dec_1.pp
user {'optimus':
    ensure => absent,
}

notify {"Deleting user Optimus":}

file {'testfile2':
        path => '/tmp/testfile2',
    ensure => present,
    mode => 0666,
    content => "Testfile2",
}

notify {"Creating a testfile2 in /tmp directory":}

file {'/tmp/testfile3':
        target => '/tmp/testfile2',
    ensure => link,
}

notify {"Creating a link file to testfile2":}
[root@server demo_manifests]#


[root@server demo_manifests]# puppet apply multiple_resource_dec_1.pp
notice: Creating a link file to testfile2
notice: /Stage[main]//Notify[Creating a link file to testfile2]/message: defined 'message' as 'Creating a link file to testfile2'
notice: Deleting user Optimus
notice: /Stage[main]//Notify[Deleting user Optimus]/message: defined 'message' as 'Deleting user Optimus'
notice: Creating a testfile2 in /tmp directory
notice: /Stage[main]//Notify[Creating a testfile2 in /tmp directory]/message: defined 'message' as 'Creating a testfile2 in /tmp directory'
notice: /Stage[main]//User[optimus]/ensure: removed
notice: /Stage[main]//File[testfile2]/ensure: created
notice: /Stage[main]//File[/tmp/testfile3]/ensure: created
notice: Finished catalog run in 0.16 seconds
[root@server demo_manifests]#


 manifests can contain conditional statements, variables, functions, and other forms of logic. But before being applied, manifests get compiled into a document called a “catalog,” which only contains resources and hints about the order to sync them in. With puppet apply, the distinction doesn’t mean much. In a master/agent Puppet environment, though, it matters more, because agents only see the catalog

Puppet apply:

• A user executes a command, triggering a Puppet run.
• Puppet apply reads the manifest passed to it, compiles it into a catalog, and applies the catalog.

Puppet agent/master:

• Puppet agent runs as a service, and triggers a Puppet run about every half hour (configurable).
  • On your VM, which runs Puppet Enterprise, the agent service is named pe-puppet. (Puppet agent can also be configured to run from cron, instead of as a service.)
• Puppet agent does not have access to any manifests; instead, it requests a pre-compiled catalog from a puppet master server.
  • On your VM, the puppet master appears as the pe-httpd service. A sandboxed copy of Apache with Passenger manages the puppet master application, spawning and killing new copies of it as needed.
• The puppet master always reads one special manifest, called the “site manifest” or site.pp. It uses this to compile a catalog, which it sends back to the agent.
  • On your VM, the site manifest is at /etc/puppetlabs/puppet/manifests/site.pp.
• After getting the catalog, the agent applies it.

This way, you can have many machines being configured by Puppet, while only maintaining your manifests on one (or a few) servers. This also gives some extra security, as described above under “Compilation.”


 http://packtlib.packtpub.com/library/puppet-3-beginners-guide/ch05lvl1sec46#

• You can embed relationship information in a resource with the before, require, notify, and subscribe metaparameters.
• You can also declare relationships outside a resource with the -> and ~> chaining arrows.
• Relationships can be either ordering (this before that) or ordering-with-notification (this before that, and tell that whether this was changed).

Here’s a notify resource that depends on a file resource:

    file {'/tmp/test1':
      ensure  => present,
      content => "Hi.",
    }

    notify {'/tmp/test1 has already been synced.':
      require => File['/tmp/test1'],
    }

OROROROROR

file {'/tmp/test1':
      ensure  => present,
      content => "Hi.",
      before  => Notify['/tmp/test1 has already been synced.'],
    }

    notify {'/tmp/test1 has already been synced.':}

(Note the square brackets and capitalized resource type!)

There are four metaparameters that let you arrange resources in order:

• before
• require
• notify
• subscribe