23. 3.0
• It has been removed
• Full scope variables
24. Facts
• Top level variables
• Do not trust them as sent from client
• Dont use if $::hostname ==
• Export FACTER_hostname=‘puppetmaster’
• puppet agent -t
• See my blog on thatbytes.co.uk
25. Is not all bad
• All languages have interesting behavior
• Look at the famous “WAT’ talk from Gary
Bernhardt
• www.destroyallsoftware.com/talks/wat
29. Export the resource
• @@file
{
"/etc/nagios/conf.d/$::fqdn.apachecheck.conf":
content
=>
template(‘apache/nagioscheck.erb’),
tag
=>
"nagioscheck",
}
• Tagged with nagioscheck
• Have a apache::nagios class ?
30. Collect the resource
File
<<|
tag
==
'nagioscheck'
|>>
• Using the tag previously
• In your nagios::server class
31. How does that work
• Puppetdb
• Stores configs
• Scalable
• AWESOMENESS
33. Puppet gets you
Knowledge
• Version controlled infrastructure
• Convergence
• Reporting
• Query-ability
• Removing the snowflakes
34. Hiera
• Puppet modules without hard-coded data
are easily shared and more re-usable
• Infrastructure configuration can be
managed without needing to edit Puppet
code
• The data problem
35. Bad Data
if ( $::environment == ‘dev’ ) {
$ntpserver = ‘192.168.2.1’
} else {
if ( $::fqdn == ‘host4.mycorp.com’) {
$ntpserver = ‘127.0.0.1’
} else {
$ntpserver = ‘213.21.6.4’
}
}
36. Good Data
$ntpserver = hiera(‘ntpserver’)
:hierarchy:
- %{operatingsystem}
- %{environment}
- %{fqdn}
- common
37. Remove Data from
Code
• Hiera uses information to determine a
hierarchy
• Top down hierarchy for overriding
configuration values based on roles,
environments, locations.... or anything else
• And do this without any coding!
38. Puppet 3.0
• Hiera is integrated into the core product
• Introduces data mapping for parameterized classes
• Backwards compatible