Hi Kenneth, I'm also creating a setup from scratch and want to do similar things like you. Therefore i cannot provide a big experience report.
However we disussed quite a lot internally how we want to setup it correctly. One outcome was to create a generic node which holds all module available on all machines (dns, nagios daemons, ntp,...). A node therefore builds together from that generic node and the node specific modules. In order to define different setups for each module (test, dev,...) we are going to use tags. You can then use the central puppet run and pass a list of tags you want deploy. You should check the tag section of the puppet documentation. I hope that helps a bit. I would be interested if experienced puppet user would agree with this setup suggestion. Christian On 16 Jul., 12:40, Kenneth Holter <[email protected]> wrote: > Hi all. > > We're building our puppet infrastructure from scratch, and need to > decide on how to organize our modules. As the puppet best practice > document suggests, we're going to put all building blocks modules in > the "modules" area, and make use of the services and clients areas to > make up server configurations. > > But how does others build server configurations from these modules in > a dynamic and structured way? How to you handle situations where one > have multiple projects, environments environments (dev, test, qass, > prod), and so forth - do you go for a > "<project>::<environment>::<role>" type of module/class structure? > Before starting to model our servers in the services and clients areas > I'd like to make sure we don't start out wrong. > > Best regards, > Kenneth Holter -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
