Ask Your Question
3

What goes in the Profile part of Role/Profile?

asked 2014-02-09 23:06:49 -0500

ramindk gravatar image

Many of the examples of Role/Profile don't explain very well if at all what goes in the Profile part of Role/Profile. Here's an example

class role::server {
  include profile::apache
}

class profile::apache {
  include ::apache
}

That appears very contrived. Some example go a bit farther, but only show using create_resources.

class profile::apache {
  include ::apache
  $myvhosts = hiera('apache::vhosts', {})
  create_resources('apache::vhost', $myvhosts)
}

Is there a better explanation for what can and should go into profile classes? Any other examples than Craig Dunn's original blog post?

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
7

answered 2014-02-09 23:07:09 -0500

ramindk gravatar image

updated 2014-09-03 16:07:28 -0500

Profile classes should be the most opinionated and site specific classes in your repo which is one reason why there are very few good examples. It's hard to write a general example for something that should be tightly coupled to the system it defines.

In my experience good profile class should:

  • be Opinionated because it is a local config.
  • be used in different roles, profile::apache_webapp is less useful than profile::apache. If possible make your profile classes general enough to be used in any of your roles.
  • wrap modules so that site config is contained in the profile class allowing modules to be easily shared.
  • allow you to easily use third party modules without editing.
  • hardly ever be shared so be opinionated, it's your system.
  • hard to get wrong. When in doubt overload your profile classes, not your modules.

Let's start with a simple example profile class for Apache.

class profile::apache
  include ::apache

  package { 'lynx': ensure => installed, } # needed for apachectl status  
  collectd::plugin { 'apache': } # turn on Apache plugin within collectd
  logrotate::simple {'apache': } # change logrotate to daily rotate
}

The writer of this class uses Collectd, adds lynx, and makes custom changes to Logrotate's apache.conf file. As you can see these are site specific choices based on how the local system is configured. We could combine all of this into some sort of super Apache module rather than wrapping it in a profile class and many Puppet users have done just that. However it makes their Apache module impossible to share and hard to update parts of their infrastructure without rewriting individual modules. Do you really want to release a new Apache module when you change your stats collector?

Expanding the profile with additional statements leads to

class profile::apache
  include ::apache
  include profile::sslcerts # include ssl profile, will only add sslcerts if Hiera returns data.

  package { 'lynx': ensure => installed, } # needed for apachectl status  
  collectd::plugin { 'apache': } # turn on Apache plugin within collectd
  logrotate::simple {'apache': }  # change logrotate to daily rotate

  Sslcerts::Cert<||> ~> Class['apache::service'] # all ssl certs resource before Apache service
}

The profile::sslcerts class is a general class that can install various ssl certs. However many daemons such as Mysql, haproxy, nginx, and others can use ssl certs. We can't have ordering in profile::sslcerts because we don't know which daemon it may be uses with so ordering is added in profile::apache. Would be the same if we built a profile::nginx class.

Adding even more to our example

class profile::apache
  include ::apache
  include profile::sslcerts # include ssl profile, will only add sslcerts if hiera returns data.

  package { 'lynx': ensure => installed, } # needed for apachectl status  
  collectd::plugin { 'apache': }  # turn on Apache plugin within collectd
  logrotate::simple {'apache': }  # change logrotate to daily rotate

  $myvhosts = hiera('apache::vhosts', {}) # query Hiera for apache::vhosts key
  create_resources('apache::vhost', $myvhosts) # use data from apache::vhosts key to populate apache::vhost

  Sslcerts::Cert<||> -> Class['apache::service'] # all ssl certs resource before Apache ...
(more)
edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

4 followers

Stats

Asked: 2014-02-09 23:06:49 -0500

Seen: 1,547 times

Last updated: Sep 03 '14