So we''ve got "resources". And "classes" and "nodes" and "defines" and "modules" and "plugins" and "templates". And I''m not sure I''ve got them all, by any means. Classes are singletons. I''m working on managing a batch of identical servers. The obvious thing, it seems to me, is to define a *thingy* (technical term meaning I want to not misuse any of the specifically meaningful terms above) which encapsulates exactly what I want these identical servers to do (presumably using lots of modules and things from elsewhere), and then associate the *thingy* with the list of nodes I want to be like that. Is this the propperly Puppetish best-practices approach? (It''s a small batch, 2 at the moment, unlikely to exceed a dozen ever; they''re actually *virtual* servers). And, if that is the right general approach -- what flavor of *thingy* should I be writing there? Is that a define, or a class, or a module, or what? Or is it best (since they''re really truly supposed to be identical) to skip the container and just import or define everything I want directly in the node, using the multiple titles syntax to create a batch of identical nodes? (And I''ve got my test node connecting to my puppet server and doing the trivial stuff from the "simplest recipe" correctly, and I''m moving on to bigger and better things! Thanks for all the help in stage one.) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Jeroen van Meeuwen
2008-Oct-01 17:24 UTC
[Puppet Users] Re: How to aggregate node attributes?
dd-b wrote:> So we''ve got "resources". And "classes" and "nodes" and "defines" and > "modules" and "plugins" and "templates". And I''m not sure I''ve got > them all, by any means. Classes are singletons. > > I''m working on managing a batch of identical servers. The obvious > thing, it seems to me, is to define a *thingy* (technical term meaning > I want to not misuse any of the specifically meaningful terms above) > which encapsulates exactly what I want these identical servers to do > (presumably using lots of modules and things from elsewhere), and then > associate the *thingy* with the list of nodes I want to be like that. > Is this the propperly Puppetish best-practices approach? (It''s a > small batch, 2 at the moment, unlikely to exceed a dozen ever; they''re > actually *virtual* servers). > > And, if that is the right general approach -- what flavor of *thingy* > should I be writing there? Is that a define, or a class, or a module, > or what? Or is it best (since they''re really truly supposed to be > identical) to skip the container and just import or define everything > I want directly in the node, using the multiple titles syntax to > create a batch of identical nodes? > > (And I''ve got my test node connecting to my puppet server and doing > the trivial stuff from the "simplest recipe" correctly, and I''m moving > on to bigger and better things! Thanks for all the help in stage > one.) >To "group" a bunch of servers to let them have the same manifests and settings applied, you could create a "groups/cluster-app1.pp" file saying: class cluster-app1 { include foo include bar include baz::zzz foo::gaga { "yada": something => notsomething } (...lots of other stuff...) } and then include the cluster-app1 class to each node: node ''node1.example.com'' { include cluster-app1 } node ''node2.example.com'' { include cluster-app1 } etc. Does that help? Kind regards, Jeroen van Meeuwen -kanarip --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Oct 1, 12:24 pm, Jeroen van Meeuwen <kana...@kanarip.com> wrote:> Does that help?Yes, thanks. I''m inferring from your answer that not only does that work, but you think it''s a reasonable approach. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On 10/1/2008 11:39 AM, dd-b wrote:> And, if that is the right general approach -- what flavor of *thingy* > should I be writing there? Is that a define, or a class, or a module, > or what?Probably some of each, depending on what you need to do. A module is more or less an encapsulated set of classes, defines, files, templates, etc. that occupy a single directory tree. I wrote up my first module at http://blogs.cae.tntech.edu/mwr/2007/08/02/the-new-file-server-puppet-and-modules/ - and it''s a combination of all of the above and may be a useful starting point. Its goal is to be the thingy that configures all my Amanda servers correctly. Honestly, I only have the one Amanda server, but it has three different configurations active at once, and I''d like to ensure that they''re all done consistently. And I''d also like to ensure that my next Amanda server gets set up the right way as well. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Jeroen van Meeuwen
2008-Oct-01 22:48 UTC
[Puppet Users] Re: How to aggregate node attributes?
dd-b wrote:> > > On Oct 1, 12:24 pm, Jeroen van Meeuwen <kana...@kanarip.com> wrote: > >> Does that help? > > Yes, thanks. > > I''m inferring from your answer that not only does that work, but you > think it''s a reasonable approach. >Yes sir I do, and I split these manifests up in different categories as well (usefulness depending on the scale of the environment of course): - classes/ Aggregations of classes (from modules?), environment specific settings for those classes, overriding/extension of classes (such as subclassing the ssh module to make it apply to your organization): class yum-repo-profile { include yum::standard yum::repository { "custom": enable => true } } - domains/ Branch offices / co-locations with different dns suffices, network settings, security profiles. Maybe some organization specific stuff if your environment is a merger hybrid. - groups/ A group of hosts getting the same configuration (cluster-app1, cluster-app2, reverse-proxy-dmz) - services/ Sets of services - webservice (hourly logrotate maybe some selinux config) - ldapservice (no ldap authentication for these, only local system administrators) Basically a complete configuration in one service specific class of what your organization defines as a "service" How does that sound? -Jeroen --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---