I'm absolutely with John on this. As an example, for our JBoss application
we need the configuration file to be different based on the the hostname
(we only host one app per host/VM) and environment
(dev/integration/qa/staging/production). Further, some "dev" boxes need to
allow the developers to hand-update their configs. So what I have is a
templated configuration file that has all the configuration information in
it for all the environments, and only the pertinent information gets
shipped to the Puppet client. Further, I wrap this in a define{} so that
the file Puppet actually manages is "server.properties-default". There is
an exec{} in the define which checks for a "server.properties-noupdate"
file. If that file exists, the exec{} bails. If it doesn't, then it
rsync's the -default file onto the "server.properties" file that JBoss
references. Finally, the define{} also creates a
"server.properties-README" which tells the developer about how the file is
managed and what they can do if they want to override Puppet.
On Wed, Apr 11, 2012 at 1:52 PM, jcbollinger <john.bollin...@stjude.org>wrote:
>
>
> On Apr 11, 12:04 pm, Josh <joshua.l.greenb...@gmail.com> wrote:
> > This is more of a style question than implementation. I have a bunch of
> > nodes running the same software but in many cases they need config files
> > that are customized for that specific node. I was thinking I could push
> all
> > the main files from the app through a central class and have separate
> > classes for each individual node that has the config files. Is this the
> > best way to do this or does it go against the purpose of using puppet?
>
>
> There is no inherent problem with that approach, but for a little
> extra effort you can get something that will be easier to maintain.
> I'm not a big fan of parameterized classes myself, but I heartily
> endorse an external data store, accessed via Hiera. Instead of using
> per-node classes, record per-node data where needed. You can use that
> data to fill templates, choose among alternatives in your manifests,
> set resource properties, etc..
>
>
> > Also, for implementation, is it best practice to create a separate module
> > and class for each node where the class includes only that module?
> Thanks.
>
>
> I would say not. It might or might not make sense to put the per-node
> classes in the module with the main classes for the application in
> question, but I certainly see no reason to separate them from each
> other. But the question is moot if you choose a cleaner strategy.
>
>
> John
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
