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:

[root@centos manifests]# vim site.pp
[root@centos manifests]# cat site.pp
import 'order.pp'
[root@centos 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!":}

[root@yum01 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:

[root@centos 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'],
}

[root@yum01 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   send msg to puppet agent
• 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:

[root@centos 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.':}

[root@yum01 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:

[root@centos manifests]# mkdir -p /etc/puppet/modules/ntp/files

[root@centos manifests]# cp /etc/ntp.conf /etc/puppet/modules/ntp/files

[root@centos 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'],
}

[root@yum01 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. (There are two changed parameters, so trggered refresh from 2 events)

# 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.

This example causes the same dependency as the similar examples above:

[root@centos manifests]# cat site.pp |grep order1
import 'order1.pp'

[root@centos manifests]# cat order1.pp
file {'/tmp/test11':
ensure => present,
content => "hi",
}
notify {'after':
message => '/tmp/test11 has already been synced.',
}

File['/tmp/test11'] -> Notify['after']

[root@yum01 ~]# puppet agent --test
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Caching catalog for yum01.test.com
Info: Applying configuration version '1417158189'
Notice: /Stage[main]/Main/File[/tmp/test11]/ensure: created
Notice: /tmp/test11 has already been synced.
Notice: /Stage[main]/Main/Notify[after]/message: defined 'message' as '/tmp/test11 has already been synced.'
Notice: Finished catalog run in 0.89 seconds

Chaining arrows can take several things as their operands: this example uses resource references, but they can also take resource declarations and resource collectors.

Since whitespace is freely adjustable in Puppet, and since chaining arrows can go between resource declarations, it’s easy to make a short run of resources be synced in the order they’re written — just put chaining arrows between them:

[root@centos manifests]# cat order1.pp
file {'/tmp/test11':
ensure => present,
content => "hi",
}
->
notify {'after':
message => '/tmp/test11 has already been synced.',
}

[root@yum01 ~]# puppet agent --test
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Caching catalog for yum01.test.com
Info: Applying configuration version '1417158371'
Notice: /Stage[main]/Main/File[/tmp/test11]/ensure: created
Notice: /tmp/test11 has already been synced.
Notice: /Stage[main]/Main/Notify[after]/message: defined 'message' as '/tmp/test11 has already been synced.'
Notice: Finished catalog run in 1.03 seconds

Again, this creates the same relationship we’ve seen previously.

Autorequire

Some of Puppet’s resource types will notice when an instance is related to other resources, and they’ll set up automatic dependencies. The one you’ll use most often is between files and their parent directories: if a given file and its parent directory are both being managed as resources, Puppet will make sure to sync the parent directory before the file. This never creates new resources; it only adds dependencies to resources that are already being managed.

Don’t sweat much about the details of autorequiring; it’s fairly conservative and should generally do the right thing without getting in your way. If you forget it’s there and make explicit dependencies, your code will still work. Explicit dependencies will also override autorequires, if they conflict.

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