Learning Puppet — Resource Ordering

Learn about dependencies and refresh events, manage the relationships between resources, and discover the fundamental Puppet design pattern.

Disorder

Let’s look back on one of our manifests from the last page:

[[email protected] manifests]# vim site.pp
[[email protected] manifests]# cat site.pp
import ‘order.pp‘
[[email protected] manifests]# cat order.pp
file { ‘/tmp/test1‘:
ensure => present,
content => "hi.",
}
file { ‘/tmp/test2‘:
ensure => directory,
mode => 644,
}
file { ‘/tmp/test3‘:
ensure => link,
target => ‘/tmp/test1‘,
}

notify {" iam nofitying you":}
notify {" so am I!":}

[[email protected] tmp]# puppet agent --test
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Caching catalog for yum01.test.com
Info: Applying configuration version ‘1415344839‘
Notice: /Stage[main]/Main/File[/tmp/test1]/ensure: created
Notice: /Stage[main]/Main/File[/tmp/test3]/ensure: created
Notice: /Stage[main]/Main/File[/tmp/test2]/ensure: created
Notice: so am I!
Notice: /Stage[main]/Main/Notify[ so am I!]/message: defined ‘message‘ as ‘ so am I!‘
Notice: iam nofitying you
Notice: /Stage[main]/Main/Notify[ iam nofitying you]/message: defined ‘message‘ as ‘ iam nofitying you‘
Notice: Finished catalog run in 0.04 seconds

When we ran this, the resources weren’t synced in the order we wrote them: it went /tmp/test1,/tmp/test3, /tmp/test2, So am I!, and I‘m notifying you.

Like we mentioned in the last chapter, Puppet combines “check the state” and “fix any problems” into a single declaration for each resource. Since each resource is represented by one atomic statement, ordering within a file matters a lot less than it would for an equivalent script. So when dealing with related resources, Puppet has ways to express those relationships.

Metaparameters, Resource References, and Ordering

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

[[email protected] manifests]# cat file.pp
file {‘/tmp/test111‘:
ensure => present,
content => "hi. this is a test 111111 file \n",
}

notify {‘/tmp/test111 has already been synced/‘:
require => File[‘/tmp/test111‘],
}

[[email protected] tmp]# puppet agent --test
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Caching catalog for yum01.test.com
Info: Applying configuration version ‘1415345569‘
Notice: /Stage[main]/Main/File[/tmp/test111]/ensure: created
Notice: /tmp/test111 has already been synced/
Notice: /Stage[main]/Main/Notify[/tmp/test111 has already been synced/]/message: defined ‘message‘ as ‘/tmp/test111 has already been synced/‘
Notice: Finished catalog run in 0.11 seconds

Each resource type has its own set of attributes, but there’s another set of attributes, calledmetaparameters, which can be used on any resource

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

• before  before is used in the earlier resource
• require  require is used in the later resource
• notify
• subscribe  subscribe is used in the later resource, if change, also sent refresh

All of them accept a resource reference (or an array of them) as their value.

Before and Require

before and require make simple dependency relationships, where one resource must be synced before another. before is used in the earlier resource, and lists resources that depend on it; require is used in the later resource, and lists the resources that it depends on.

These two metaparameters are just different ways of writing the same relationship — our example above could just as easily be written like this:

[[email protected] manifests]# cat file.pp
file {‘/tmp/test1‘:
ensure => present,
content => "Hi.",
before => Notify[‘/tmp/test1 has already been synced.‘],
}

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

[[email protected] tmp]# puppet agent --test
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Caching catalog for yum01.test.com
Info: Applying configuration version ‘1415345911‘
Notice: /Stage[main]/Main/File[/tmp/test1]/ensure: created
Notice: /tmp/test1 has already been synced.
Notice: /Stage[main]/Main/Notify[/tmp/test1 has already been synced.]/message: defined ‘message‘ as ‘/tmp/test1 has already been synced.‘
Notice: Finished catalog run in 0.39 seconds

Notify and Subscribe

A few resource types (service, exec, and mount) can be “refreshed” — that is, told to react to changes in their environment. For a service, this usually means restarting when a config file has been changed; for anexec resource, this could mean running its payload if any user accounts have been changed

The notify and subscribe metaparameters make dependency relationships the way before and requiredo, but they also make notification relationships. Not only will the earlier resource in the pair get synced first, but if Puppet makes any changes to that resource, it will send a refresh event to the later resource, which will react accordingly.

An example of a notification relationship:

[[email protected] manifests]# mkdir -p /etc/puppet/modules/ntp/files

[[email protected] manifests]# cp /etc/ntp.conf /etc/puppet/modules/ntp/files

[[email protected] manifests]# vim file.pp

file { ‘/etc/ntp.conf‘:
ensure => file,
mode => 600,
source => ‘puppet:///modules/ntp/ntp.conf‘,
}
service { ‘ntpd‘:
ensure => running,
enable => true,
subscribe => File[‘/etc/ntp.conf‘],
}

[[email protected] tmp]# puppet agent --test
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Caching catalog for yum01.test.com
Info: Applying configuration version ‘1415347799‘
Notice: /Stage[main]/Main/File[/etc/ntp.conf]/content:
--- /etc/ntp.conf 2014-11-07 07:56:08.681423545 +0000
+++ /tmp/puppet-file20141107-15367-s2gp6n-0 2014-11-07 08:19:27.500485582 +0000
@@ -19,9 +19,8 @@

# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
- #server ntpv01
server 192.168.1.20
-# server ntpv02
+server 192.168.1.21

Info: Computing checksum on file /etc/ntp.conf
Info: /Stage[main]/Main/File[/etc/ntp.conf]: Filebucketed /etc/ntp.conf to puppet with sum 4f6db2d5786a7911745abd3113ce02b4
Notice: /Stage[main]/Main/File[/etc/ntp.conf]/content: content changed ‘{md5}4f6db2d5786a7911745abd3113ce02b4‘ to ‘{md5}86f6b5f3e0cbcb2dd9dfcc49bb16e1a9‘
Notice: /Stage[main]/Main/File[/etc/ntp.conf]/mode: mode changed ‘0644‘ to ‘0600‘
Info: /Stage[main]/Main/File[/etc/ntp.conf]: Scheduling refresh of Service[ntpd]
Info: /Stage[main]/Main/File[/etc/ntp.conf]: Scheduling refresh of Service[ntpd]
Notice: /Stage[main]/Main/Service[ntpd]: Triggered ‘refresh‘ from 2 events
Notice: Finished catalog run in 4.39 seconds

In this example, the ntpd service will be restarted if Puppet has to edit its config file.

# fileserver.conf

# Puppet automatically serves PLUGINS and FILES FROM MODULES: anything in
# <module name>/files/<file name> is available to authenticated nodes at
# puppet:///modules/<module name>/<file name>. You do not need to edit this
# file to enable this.

Chaining Arrows

There’s one last way to declare relationships: chain resource references with the ordering (->) and notification (~>; note the tilde) arrows. Think of them as representing the flow of time: the resource behind the arrow will be synced before the resource the arrow points at.

refer: https://docs.puppetlabs.com/learning/ordering.html