Short version: read up on hiera, data bindings, and create_resources.
Details:
It sounds like you might want to look into hiera (baked into puppet 3 and
higher) and the create_resources function. Specifically that you list the
variable portions of things in your puppet configuration in hiera, and then use
the create_resources function to configure an arbitrary number of those things.
That way each vhost is another data entry which you can more easily parse and
validate than the equivalent puppet code.
Quick example:
a) your hiera data file
---
apache::vhosts::vhosts:
'www.example.com':
'default_vhost': true
'docroot': /var/www/html/www.example.com
'logroot': /var/log/httpd/www.example.com
'access_log_file': access_log
'error_log_file': error_log
'override': all
'www.otherhost.com':
'default_vhost': false
'docroot': /var/www/html/www.otherhost.com
'logroot': /var/log/httpd/www.otherhost.com
'access_log_file': access_log
'error_log_file': error_log
'override': all
b) a define representing one vhost, note variables named like yaml keys
define apache::onevhost (
$default_vhost,
$docroot,
$logroot,
$access_log_file,
$error_log_file,
$override,
) {
# your resource declarations here
}
c) a class wrapping that define and the create_resources function, also with
some chaining/collecting so that the resources are applied in the right order
class apache::vhosts ( $vhosts ) {
include apache
create_resources('apache::onevhost', $vhosts)
Class['Apache'] -> Apache::Onevhost <| |>
}
d) in your node definition (or better, in a profile included in a role) you
would include the apache::vhosts class
include ::apache::vhosts
Here's the read-until-eyes-bleed set of links:
http://docs.puppetlabs.com/hiera/1/
https://ask.puppetlabs.com/question/117/how-can-i-use-data-bindings-in-puppet-3/
http://docs.puppetlabs.com/puppet/latest/reference/lang_collectors.html
http://docs.puppetlabs.com/references/latest/function.html#createresources
http://docs.puppetlabs.com/puppet/latest/reference/lang_functions.html
(str2bool from stdlib could be important when declaring true/false in yaml)
http://docs.puppetlabs.com/guides/scope_and_puppet.html
http://www.craigdunn.org/2012/05/239/
http://garylarizza.com/blog/2014/02/17/puppet-workflow-part-1/
http://garylarizza.com/blog/2014/02/17/puppet-workflow-part-2/
https://ask.puppetlabs.com/question/1655/an-end-to-end-roleprofile-example-using-hiera/
Now all that said, the optimal way to write up your home/work puppet setup is
the one that makes your life easier. The above represents my opinion and no
more. Your mileage may definitely vary and that's perfectly fine too.
On Sun, Jun 22, 2014 at 05:49:59AM -0700, Ben Ruset wrote:
> Alright, this is definitely a Puppet 101 question, and I am sure that the
> Puppet docs have an answer for this and I am just dense and can't find
> it.
> I'm trying to teach myself Puppet, with the goal of managing the VPS I run
> with it. Additionally, when I get a better grasp on things, I want to
> deploy it at work. So while my home deployment will be small, I want to
> learn how to "do it right."
> I have a vanilla Puppet server and an agent. Both are managed through
> Puppet.
> Right now, on my agent node, I'm configuring Apache. I've got code like
> this in my nodes.pp:
> ###
> node 'hostname' {
> include 'ntp'
> include 'sudo'
> class { 'vim':
> opt_misc =>
>
> ['nu','fo=tcq','nocompatible','modeline','tabstop=2','expandtab','softtabstop=2','shiftwidth=2','backspace=indent,eol,start'],
> }
> class { 'apache':
> serveradmin => 'whatever',
> }
> apache::vhost{ 'www.example.com':
> default_vhost => true,
> docroot => '/var/www/html/www.example.com',
> logroot => '/var/log/httpd/www.example.com',
> access_log_file => 'access_log',
> error_log_file => 'error_log',
> override => 'all',
> }
> some more vhosts
> ...
> }
> ###
> It seems like best practice is to put all of these configs in some
> separate directory/file so I could end up with something like:
> ###
> node 'hostname' {
> include 'ntp'
> include 'sudo'
> class { 'vim':
> opt_misc => $std_vim_ops
> }
> include 'vhost1'
> include 'vhost2'
> }
> ###
> Now I guess I can make modules for each vhost, but that doesn't seem
> right. How would I go about doing this? (Bear in mind that my second block
> of code is just a rough approximation and I don't really know the right
> way to write out what I want to do.)
> Thanks for your patience. I've been searching for answers and not really
> understanding what I come up with.
>
> --
> 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 [1]puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
>
> [2]https://groups.google.com/d/msgid/puppet-users/41e9486d-c072-4e14-8ee6-d91804277f74%40googlegroups.com.
> For more options, visit [3]https://groups.google.com/d/optout.
>
> References
>
> Visible links
> 1. mailto:puppet-users+unsubscr...@googlegroups.com
> 2.
> https://groups.google.com/d/msgid/puppet-users/41e9486d-c072-4e14-8ee6-d91804277f74%40googlegroups.com?utm_medium=email&utm_source=footer
> 3. https://groups.google.com/d/optout
--
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/20140622184534.GA7651%40iniquitous.heresiarch.ca.
For more options, visit https://groups.google.com/d/optout.
