Design Patterns - Profiles & Shared Information

[Stefan Schlesinger]

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.

[Peter Kristolaitis]

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