I''ve been running puppet for a couple of years without using
environments. Now, I manage more servers and I think it''s time to
implement puppet environments. I have a couple of questions about design
best practice.
Probably 80% of the modules in use across the various environments would
be common to all environments. To avoid duplication of modules, I want
to have a separate directory of common modules, and specify two
modulepaths in the environment declaration, like this:
[resnet]
modulepath = $confdir/environments/resnet/modules:$confdir/modules
manifest = $confdir/environments/resnet/manifests/site.pp
My question is, can I put a module named "httpd" in my common module
directory, and then in specific environments have subclasses like
"httpd::vhost1", "httpd::vhost2", etc? How will the module
fileserving work?
As I''m refactoring my whole puppet environment this is a good
opportunity to "do things right" so any advice about managing multiple
environments, sharing modules, extending classes, etc, will be
gratefully received.
Cheers,
Jonathan
--
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+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
> My question is, can I put a module named "httpd" in my common module > directory, and then in specific environments have subclasses like > "httpd::vhost1", "httpd::vhost2", etc? How will the module fileserving > work?The autoloader will not support having one module spread over two modulepaths like you want - it will stop at the first module, so if it finds httpd in /modulepath/1 it''s never going to find httpd::vhost1 in /modulepath/2 Even if that did work it would be unwise and confusing. A better idea maybe to have a httpd class in your common module and then your vhosts in a separate class namespace (sites::vhost1)... that should work. Regards Craig -- Craig Dunn Professional Services Puppet Labs Inc. http://www.puppetlabs.com -- 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+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
On 21/02/13 14:16, Craig Dunn wrote:> >> My question is, can I put a module named "httpd" in my common module >> directory, and then in specific environments have subclasses like >> "httpd::vhost1", "httpd::vhost2", etc? How will the module >> fileserving work? > > The autoloader will not support having one module spread over two > modulepaths like you want - it will stop at the first module, so if it > finds httpd in /modulepath/1 it''s never going to find httpd::vhost1 in > /modulepath/2 > > Even if that did work it would be unwise and confusing. A better idea > maybe to have a httpd class in your common module and then your vhosts > in a separate class namespace (sites::vhost1)... that should work. >Thanks for your message. I discovered through testing that the autoloader does not support this behaviour. I had sort of resolved to implement your suggestion although it seems a little bit messy. Taking a step back, are there any better solutions? I want to achieve a common repository of modules, and a handful of environments with different sysadmins, who will be able to call upon the common modules, include them, and extend them in their own environments. Surely there must be some sort of prior art? :) Cheers, Jonathan -- 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+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
On 02/21/2013 03:23 PM, Jonathan Gazeley wrote:> > Thanks for your message. I discovered through testing that the > autoloader does not support this behaviour. I had sort of resolved to > implement your suggestion although it seems a little bit messy. > > Taking a step back, are there any better solutions? I want to achieve a > common repository of modules, and a handful of environments with > different sysadmins, who will be able to call upon the common modules, > include them, and extend them in their own environments. Surely there > must be some sort of prior art? :)I believe that the best way to achieve this is to put your modules in source control, preferably with multiple repositories like git. Each environment can thus be a branch of the main environment. All the voodoo of keeping up-to-date etc. happens outside of puppet, which is a good thing imo. HTH, Felix -- 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+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.