[Puppet Users] Re: Creating classes for individual nodes
Thanks everyone! This is a good start. I'll have to research most of
this but at least I know what to research now. Thanks.
Josh
On Apr 12, 10:19 am, Brian Gallew g...@gallew.org wrote:
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.orgwrote:
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.
Re: [Puppet Users] Re: Creating classes for individual nodes
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.orgwrote:
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.
[Puppet Users] Re: Creating classes for individual nodes
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.
