I think others have covered the why so I'll take a shot at the how. I think by understanding how someone might use Puppet to do what you want, it'll make the decision clearer.
Do the basic case first
Your Puppet module for Apache shouldn't do much by default. Install Apache, config it to a minimum standard, and start the service. Make this work on all distros you need to support.
Add flexibility second
We need to add vhosts. You'll end up with a system that can drop file or remove them from a set of conf.d or vhosts.d/ directories according to what you need. Same thing with enabling or configuring modules.
Use role or hostgroup classes to tie your building blocks together
I think the best way to use Puppet is to make sure it's additive. Using the examples above we should have a module that does
- Install Apache
- Set basic configs
- Add vhosts to apache
- Configure any extra settings
- Start Apache
Rather than overload our default Apache module to do exactly what we need for a particular host or group we should handle this is a role or hostgroup class.
class role::web_cust1 {
include apache
apache::vhost {'www.domain.com': }
apache::vhost {'www.domain2.com': priority => '99', }
include php
include php-fpm
include mysql
}
Again additive.
Put special cases in Hiera
I'm a big fan of letting Puppet's Hiera, think of it as a database for Puppet, store the special bits. If a certain host or hostgroup needs a special setting, first put a sane default into the module so that normal users don't need to know about it. Then insert data for those special hosts or hostgroups so Hiera can consume it pass it to Puppet as needed.
My use case is Listen port. Some servers have a Varnish or haproxy in front of them. By default the Puppet module has Apache use port 80, but if Hiera finds data it will override that default.
