I agree with everything Luke said, but would also like to point out 2 other
techniques that are useful:
1) create_resources() is a bit of a kludge left over from puppet 3. Starting in
puppet 4 (and 3’s future parser), iteration was added. Instead of
create_resources($some_hash), you would say $some_hash.each |$title, $options|
{} and create each resource inside the block. You can still use hiera to get
the hash as an automatic parameter lookup on the class, but the creation of
resources is a bit more explicit.
2) you also get the chance to define defaults, which means users don’t
necessarily have to provide everything! Create a $defaults hash and assign it
plus the defined overrides as (say for a user) user {$title: * => $defaults +
$options}. This merges the options and defaults and applies the resulting hash
as the parameters and values for the resource. You can keep your hiera tidier
by creating sane defaults and only specifying the overrides in hiera. Have a
new default? Modify the code once and all the resources in hiera benefit from
it, unless they explicitly override it.
A practical example of this might be creating local users on nodes without
access to a central auth mechanism, maybe in staging. In your code you create
some defaults:
$defaults = {
ensure => present,
password_max_age => 90,
shell => ‘/bin/fish’,
}
Your hiera might look like:
profile::linux::local_users:
rnelson0:
password: ‘hash1’
groups:
- wheel
password_max_age: 180
root:
password: “hash2”
password_max_age: 9999
lbigum:
ensure: absent
In your code, you iterate over the class parameter local_users and combine your
defaults with the specific options:
$local_users.each |$title, $options| {
user { $title:
* => defaults + $options,
}
}
Now my user is created, root’s password is changed and set to basically never
expire, and Luke’s account is deleted if it exists.
This is a good way to combine the power of hiera with the predictability of
puppet DSL, maintain unit and acceptance tests, and make it easy for your less
familiar puppet admins to manage resources without having to know every single
attribute required or even available in order to use them without going too far
down the road of recreating a particular well known CM system. It’s always a
bit of a balancing act, but I find this is a comfortable boundary for me and
one that my teammates understand.
There a lot more power to iteration that can be found in the puppet
documentation and particularly this article by RI that I still reference
frequently https://www.devco.net/archives/2015/12/16/iterating-in-puppet.php
Hope that helps.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/db93faba-3059-48f7-a09a-277463713336%40googlegroups.com.
