We use something that's halfway between the second and third options.
We use standardized namespaces in Hiera that group together logical sets
of data (we use it mostly for distributed app configuration, but you
could easily apply this to system configuration), then we pull that into
our profiles. Not an actual "data class" like your second option, but a
little more complex than your third option. For example:
define profiles::vhost (
$sitename = $title,
$parent_config = $title,
) {
$config = merge ( hiera_hash("application::${parent_config}"),
hiera_hash("application::${sitename}")
)
$product = $config['product']
$branch = $config['branch']
$component = $config['component']
$version = $config['version']
$db_user = $config['db_user']
$db_pass = $config['db_pass']
...
}
This lets us share things like database passwords among the various
profiles (vhost, database, etc) and systems that need it, and the hash
merge lets us share common configuration (e.g. log host or database
credentials) among many application sub-components that might be on
different code branches or versions.
This way way have a very, very generic "virtual host" module (or
"database" module or what have you) at the profile level, and our roles
define what namespace(s) we use for configuration (and thus, what
product/component/etc gets deployed, and the data inheritance structure
between them).
This was developed in response to some really specific business
requirements at our site, but it works reasonably well for us.
- Peter
On 1/9/2017 6:15 AM, Stefan Schlesinger wrote:
Hi,
I wonder what approaches you are currently using for sharing common information
among multiple Puppet profiles:
To come up with some examples which will need to be maintained for multiple
profiles:
- HTTP proxy settings
- IP ACLs for whitelists (eg. IP of monitoring systems, trusted hosts)
- E-mail addresses for system mails (not only for /etc/aliases)
Any thoughts?
The options I currently have on the table are:
- Don’t do any abstraction and maintain multiple copies of the same information
in hiera (eg. ::profile::redsocks::proxy_url, ::profile::apt::proxy_url).
Which in more comprehensive Puppet might not scale so well.
- As Volcane suggested on IRC, use a ::data module to provide an interface for
hiera key lookups and use ::data::some_common_thing in other profiles.
- Simply use hiera calls directly in modules such as
class profile::redsocks(
$proxy_url = hiera(‘proxy_url’)
)
Which I personally dislike, as using a module provides options for
documentation and validation as well as a defined, versionable interface to
the variables.
Thanks for your feedback!
Best, Stefan.
--
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/90faabc0-9e95-448c-eec8-5a71547037c4%40alter3d.ca.
For more options, visit https://groups.google.com/d/optout.
