More the merrier
We’ve started with a single node, which probably translates to a single machine or a single family of nearly-identical machines.
Now let’s start to add in other machine definitions (nodes):
node default {
class { 'example' : }
}
node remprov {
class { 'example' : }
}
Specialising hiera values
So far, we’ve already defined user in the class (where the default is ‘centos’) and in common.yaml
(azula).
We now define it just for the new node (remprov) in remprov.yaml
:
example::user: "yuliana"
Hiera operates an inheriting structure. Values are sourced in order from hiera.yaml, so it tries to find the value in hieradata/nodes/remprov.yaml
in preference to hieradata/common.yaml
.
Output
Similar to the previous installment, we execute locally again giving puppet
a relative path for the modules
and hieradata
directories, i.e. puppet apply -dvt ./manifests/site.pp --modulepath=./modules/ --hiera_config=./hieradata/hiera.yaml
. When run on the remprov
host, the output shows our specialised user value:
Debug: Scope(Class[Example]): The value of the variable $user is yuliana on remprov
Open-source
All the code for these tutorials is available as part of DevOps-Workstream.
The segments from this tutorial specifically make up puppet/tutorial/06-second-node
here on GitHub.
If you’d like to see all the previous and future installments of this tutorial, they’re available under the puppet
tag.
Get your team coding
If you'd like to help your Operations team move to infrastructure-as-code, please get in touch to find out how Lightenna Consulting could accelerate your Cloud journey.
Leave a comment