Putting all our code in site.pp isn’t very scalable.

We want to follow Puppet best practise and use roles and profiles, so:

cd control-repo   # I'm going to assume this from now on
git checkout puppetapply02

If you look at manifests/site.pp, there’s an include statement. This is the basis of how node classification is generally done.

The code that is actually run is in site/profile/manifests/puppet/clientscope.pp

What this profile does is write out the puppet runtime scope to a file. This includes all defined facts, and it’s really useful to have a copy for development purposes, so I make this a permanent part of my puppet apply behaviour.

Run:

sudo scripts/puppetapply.sh #--noop

It should create a file

Notice: /Stage[main]/Profile::Puppet::Clientscope/File[/tmp/site_agent_variables.yaml]/ensure: defined content as '{md5}ec805d2f8d63a29b35dc0e515097324a'
Notice: Applied catalog in 0.80 seconds

If you keep running puppet apply, it’ll keep changing the file.  It contains time specific data, such as:

$ grep uptime /tmp/site_agent_variables.yaml
system_uptime: &19
  uptime: 2:33 hours
uptime: 2:33 hours
uptime_days: 0
uptime_hours: 2
uptime_seconds: 9181
  system_uptime: *19
  uptime: 2:33 hours
  uptime_days: 0
  uptime_hours: 2
  uptime_seconds: 9181

• This is a dump of variables, arrays, and hashes.
• For legacy reasons, each puppet fact appears in column 0 (top scope) and also indented under ‘facts’, as a member of the facts hash.  Other things will also appear in top scope, including variables created within the manifest that writes out the file.  To avoid issues with scope, best practise is to refer to facts via the the facts hash.
• You can use the facts shown in this file in your code; for example: write logic based on them, write out files with this data inserted.  Examples to follow!

Next

puppet apply #5 – roles and profiles