Name: puppet-hiera
Owner: Vox Pupuli
Description: Hiera hierarchy module for templating `hiera.yaml`
Created: 2012-08-14 18:47:18.0
Updated: 2017-12-19 11:05:15.0
Pushed: 2018-01-04 10:50:16.0
Homepage: https://forge.puppet.com/puppet/hiera
Size: 322
Language: Ruby
GitHub Committers
| User | Most Recent Commit | # Commits |
|---|
Other Committers
| User | Most Recent Commit | # Commits |
|---|
This module configures Hiera for Puppet.
If you are using the eyaml backend on:
Declaring the class with a given hierarchy is a pretty good starting point:
This class will write out a hiera.yaml file in either /etc/puppetlabs/puppet/hiera.yaml or /etc/puppet/hiera.yaml (depending on if the node is running Puppet Enterprise or not).
s { 'hiera':
erarchy => [
'%{environment}/%{calling_class}',
'%{environment}',
'common',
s { 'hiera':
hiera_version => '5',
hiera5_defaults => {"datadir" => "data", "data_hash" => "yaml_data"},
hierarchy => [
{"name" => "Virtual yaml", "path" => "virtual/%{::virtual}.yaml"},
{"name" => "Nodes yaml", "paths" => ['nodes/%{::trusted.certname}.yaml', 'nodes/%{::osfamily}.yaml']},
{"name" => "Default yaml file", "path" => "common.yaml"},
],
Note: For Hiera version 5 when calling the class, please remember to pass '5' to 'hiera_version' as in the example above. Also please note that 'hierarchy' is an array of hash in version 5.
The resulting output in /etc/puppet/hiera.yaml:
kends:
yaml
ger: console
rarchy:
"%{environment}/%{calling_class}"
"%{environment}"
common
l:
datadir: /etc/puppet/hieradata
era.yaml Managed by Puppet
ion: 5
ults:
tadir: data
ta_hash: yaml_data
archy:
name: "Virtual yaml"
path: "virtual/%{::virtual}.yaml"
name: "Nodes yaml"
paths:
- "nodes/%{::trusted.certname}.yaml"
- "nodes/%{::osfamily}.yaml"
name: "Default yaml file"
path: "common.yaml"
This module will also allow you to configure different options for logger and merge_behavior. The default behavior is to set logger to console and merge behavior to native.
For details and valid options see Configuring Hiera.
s { 'hiera':
erarchy => [
'%{environment}/%{calling_class}',
'%{environment}',
'common',
gger => 'console',
rge_behavior => 'deeper'
The resulting output in /etc/puppet/hiera.yaml:
kends:
yaml
ger: console
rarchy:
"%{environment}/%{calling_class}"
"%{environment}"
common
l:
datadir: /etc/puppet/hieradata
ge_behavior: deeper
The default PKCS#7 encryption scheme used by hiera-eyaml is perfect if only simple encryption and decryption is needed.
However, if you are in a sizable team it helps to encrypt and decrypt data with multiple keys. This means that each team member can hold their own private key and so can the puppetmaster. Equally, each puppet master can have their own key if desired and when you need to rotate keys for either users or puppet masters, re-encrypting your files and changing the key everywhere does not need to be done in lockstep.
Note: This module will create a /gpg sub-directory in the `$keysdir`.
The GPG keyring must be passphraseless on the on the PuppetServer(Master).
The GPG keyring must live in the /gpg sub-directory in the `$keysdir`.
The GPG keyring must be owned by the Puppet user. ex: pe-puppet
When generating a GPG keyring the system requires a good amount of entropy.
To help generate entropy to speed up the process then rng-tools package on RHEL
based systems or equivilent can be used. Note: Update the `/etc/sysconfig/rngd`
or equivilent file to set the EXTRAOPTIONS to
# Keyring Generation
w is a sample GPG answers file that will assist in generating a
phraseless key
cat « EOF » /tmp/gpg_answers %echo Generating a Puppet Hiera GPG Key Key-Type: RSA Key-Length: 4096 Subkey-Type: ELG-E Subkey-Length: 4096 Name-Real: Hiera Data Name-Comment: Hiera Data Encryption Name-Email: puppet@$(hostname -d) Expire-Date: 0 %no-ask-passphrase
EOF
can then use the GPG answer file to generate your keyring within the
sub-directory in the ```$keysdir```
gpg –batch –homedir /etc/puppetlabs/code-staging/keys/gpg –gen-key /tmp/gpg_answers
Usage
class { 'hiera': hierarchy => [
'nodes/%{::clientcert}',
'locations/%{::location}',
'environments/%{::applicationtier}',
'common',
], eyaml => true, eyaml_gpg => true, eyaml_gpg_recipients => 'sihil@example.com,gtmtech@example.com,tpoulton@example.com', }
resulting output in /etc/puppet/hiera.yaml:
:backends:
:yaml: :datadir: /etc/puppet/hieradata
:eyaml: :datadir: /etc/puppet/hieradata :pkcs7_private_key: /etc/puppet/keys/private_key.pkcs7.pem :pkcs7_public_key: /etc/puppet/keys/public_key.pkcs7.pem :encrypt_method: “gpg” :gpg_gnupghome: “/etc/puppet/keys/gpg” :gpg_recipients: “sihil@example.com,gtmtech@example.com,tpoulton@example.com”
Classes
Public Classes
era: Main class to configure hiera
Private Classes
era::params: Handles variable conditionals
era::eyaml: Handles eyaml configuration
Parameters
following parameters are available for the hiera class:
ierarchy`
e hiera hierarchy.
fault: `[]`
r Hiera verison 5.
fault: `[{}]`
iera5_defaults`
set hiera 5 defaults. e.g. datadir, data_hash
fault: `{}`
iera_version`
rsion format to layout hiera.yaml.
ould be a string.
fault: `3`
ackends`
e list of backends.
fault: `['yaml']`
you supply a additional backend you must also supply the backend data in
e `backend_options` hash.
ackend_options`
optional hash of backend data for **any** backend.
ch key in the hash should be the name of the backend as listed in
e `backends` array. You can also supply additional settings for the backend
passing in a hash. By default the `yaml` and `eyaml` backend data will be added
you enable them via their respective parameters. Any options you supply
r `yaml` and `eyaml` backend types will always override other parameters supplied
the hiera class for that backend.
ample hiera data for the backend_options hash:
backend_options:
json:
datadir: '/etc/puppetlabs/puppet/%{::environment}/jsondata'
redis:
password: clearp@ssw0rd # if your Redis server requires authentication
port: 6380 # unless present, defaults to 6379
db: 1 # unless present, defaults to 0
host: db.example.com # unless present, defaults to localhost
path: /tmp/redis.sock # overrides port if unixsocket exists
soft_connection_failure: true # bypass exception if Redis server is unavailable; default is false
separator: / # unless present, defaults to :
deserialize: :json # Try to deserialize; both :yaml and :json are supported
NOTE:** The backend_options must **not** contain symbols as keys ie `:json:`
spite the hiera config needing symbols. The template will perform all the
nversions to symbols in order for hiera to be happy. Because puppet does
t use symbols there are minor annoyances when converting back and forth and
rge data together.
iera_yaml`
e path to the hiera config file.
Note**: Due to a bug, hiera.yaml is not placed in the codedir. Your
ppet.conf `hiera_config` setting must match the configured value; see also
iera::puppet_conf_manage`
fault:
* `'/etc/puppet/hiera.yaml'` for Puppet Open Source
* `'/etc/puppetlabs/puppet/hiera.yaml'` for Puppet Enterprise
reate_symlink`
ether to create the symlink `/etc/hiera.yaml`
fault: true
atadir`
e path to the directory where hiera will look for databases.
fault:
* `'/etc/puppet/hieradata'` for Puppet Open Source
* `'/etc/puppetlabs/puppet/hieradata'` for PE Puppet < 4
* `'/etc/puppetlabs/code/environments/%{::environment}/hieradata'` for Puppet >= 4
atadir_manage`
ether to create and manage the datadir as a file resource.
fault: `true`
wner`
e owner of managed files and directories.
fault:
* `'puppet'` for Puppet Open Source
* `'pe-puppet'` for Puppet Enterprise
roup`
e group owner of managed files and directories.
fault:
* `'puppet'` for Puppet Open Source
* `'pe-puppet'` for Puppet Enterprise
yaml`
ether to install, configure, and enable [the eyaml backend][eyaml]. Also see
e provider and master_service parameters.
fault: `false`
yaml_name`
e name of the eyaml gem.
fault: 'hiera-eyaml'
yaml_version`
e version of hiera-eyaml to install. Accepts 'installed', 'latest', '2.0.7',
c
fault: `undef`
yaml_source`
alternate gem source for installing hiera-eyaml.
fault: `undef`, uses gem backend default
yaml_datadir`
e path to the directory where hiera will look for databases with the eyaml backend.
fault: same as `datadir`
yaml_extension`
e file extension for the eyaml backend.
fault: `undef`, backend defaults to `'.eyaml'`
eep_merge_name`
e name of the deep_merge gem.
fault: 'deep\_merge'
eep_merge_version`
e version of deep\_merge to install. Accepts 'installed', 'latest', '2.0.7',
c.
fault: `undef`
eep_merge_source`
alternate gem source for installing deep_merge.
fault: `undef`, uses gem backend default
eep_merge_options`
hash of options to set in hiera.yaml for the deep merge behavior.
fault: `{}`
anage_package`
boolean for wether the hiera package should be managed. Defaults to `true` on
SS 3 but `false` otherwise.
ackage_name`
ecifies the name of the hiera package. Default: 'hiera'
ackage_ensure`
ecifies the ensure value of the hiera package. Default: 'present'
onfdir`
e path to Puppet's confdir.
fault: `$::settings::confdir` which should be the following:
* `'/etc/puppet'` for Puppet Open Source
* `'/etc/puppetlabs/puppet'` for Puppet Enterprise
ogger`
ich hiera logger to use.
Note**: You need to manage any package/gem dependencies yourself.
fault: `undef`, hiera defaults to `'console'`
mdpath`
arch paths for command binaries, like the `eyaml` command.
e default should cover most cases.
fault: `['/opt/puppet/bin', '/usr/bin', '/usr/local/bin']`
reate_keys`
ether to create pkcs7 keys and manage key files for hiera-eyaml.
is is useful if you need to distribute a pkcs7 key pair.
fault: `true`
erge_behavior`
ich hiera merge behavior to use. Valid values are 'native', 'deep', and
eeper'. Deep and deeper values will install the deep\_merge gem into the
ppet runtime.
fault: `undef`, hiera defaults to `'native'`
xtra_config`
bitrary YAML content to append to the end of the hiera.yaml config file.
is is useful for configuring backend-specific parameters.
fault: `''`
eysdir`
rectory for hiera to manage for eyaml keys.
fault: `$confdir/keys`
Note:** If using PE 2013.x+ and code-manager set the keysdir under the
keys to all PuppetServers Example: `/etc/puppetlabs/code-staging/keys`
puppet_conf_manage
Whether to manage the puppet.conf hiera_config value or not.
Default: trueprovider
Which provider to use to install hiera-eyaml. Can be:puppetserver_gem (PE 2015.x or FOSS using puppetserver)pe_puppetserver_gem (PE 3.7 or 3.8)pe_gem (PE pre-3.7)puppet_gem (agent-only gem)gem (FOSS using system ruby (ie puppetmaster))
Note: this module cannot detect FOSS puppetserver and you must pass
provider => 'puppetserver_gem' for that to work. See also master_service.
Default: Depends on puppet version detected as specified above.master_service
The service name of the master to restart after package installation or
hiera.yaml changes.
Note: You must pass master_service => 'puppetserver' for FOSS puppetserver
Default: 'pe-puppetserver' for PE 2015.x, otherwise 'puppetmaster'gem_install_options
An array of install options to pass to the gem package resources. Typically,
this parameter is used to specify a proxy server. eg
gem_install_options => ['--http-proxy', 'http://proxy.example.com:3128']The eyaml_version parameter does not currently modify the eyaml version of the
command-line gem on pe-puppetserver.
Pull requests on github! If someone wrote spec tests, that would be awesome.