Not sure if you know that you can create a relation between custom / external facts (read more) and hiera (read more) data in Puppet. For hiera data, firstly you define a hierarchy for parameters at various levels e.g. Server, data center, region etc.. Secondly, you set values to hiera parameters. Further, Puppet classes reference them. On the other hand, you can use Puppet external facts described here to define and / or generate default values for some of the parameters. Later, they can be used in hiera data to set the default values for hiera top level parameters. Next, they can be override by providing other values at lower, more specific hiera data level, or left as is. In this case, the default value will be generated in facter scrips, and used globally.
Let me show You couple examples of the setup for Puppet facts in hiera data.
Example of Puppet facts
In PowerShell, generating server name based on some hostname portions.
...
$MachineName = (hostname)
$location = (hostname).Substring(0,3).tolower()
$environment = (hostname).Substring(4,2).tolower()
$backupHost = $location + $environment + "bak01"
write-host "facterbackuphost=$backupHost"
...In ruby, putting portions of the server name into facter.
...
Facter.add(:location) do
location = nil
setcode do
location = Facter.value(:hostname)[0..2]
location.downcase
end
end
Facter.add(:environ) do
environ = nil
setcode do
environ = Facter.value(:hostname)[3..4]
environ.downcase
end
end
...Examples of hiera data
Server name generated in Puppet facts
Example below shows how you can reference variable from facter, that you configured in previous step in PowerShell. Such setting, I would suggest to store at the most general hiera data level, which is common.yaml file located under data folder. As result, value for the backuphost, that you can use in Puppet templates for example, will be driven by Puppet facter. In subsequent examples you will see how to override it, if necessary.
...
backuphost: "%{facterbackuphost}"
...Server name constructed as conjunction of couple Puppet facts parameters
Another example presents how you can construct dynamic values in hiera data based on facter parameters generated in Ruby. Again, this is good example of setting for common.yaml.
...
backuphost: "%{location}%{environ}bak01"
...Example of hiera data parameter override
Finally, if you followed one of the examples above to setup your common.yaml, at some point you may need to tweak it a little bit. Just for example let’s say that the most general setting does not work for some type of your servers. Firstly, you need to ensure that hiera data hierarchy is setup as expected. Secondly, you will use it to override the settting located in coommon.yaml. You will create another more specific *.yaml file at the defined level of your hierarchy e.g. servertype. Then you will store your desired values for the parameter in question. That way backuphost value will be generated based on the facter for most of you servers, but not for that specific server type, for which have just you defined another value.
...
backuphost: "locqabak01"
...
