So you would recommend, when possible, to shove everything into one file? Say
there is a lengthy and/or complex implementation… are there any general best
practices to adhere to?
Also as a general guideline should one try and include all dependencies at the
module level or at the node level? For example, I have a rails application that
depends on nginx. Should I model that dependency in the node like:
node web {
include nginx
include rails
}
Or should it be modeled like:
node web{
include rails
}
class rails {
include nginx
}
Once again, thanks for your input.
- M
On Nov 24, 2012, at 3:19 PM, Ryan Coleman <r...@puppetlabs.com> wrote:
>
>
>
> On Sat, Nov 24, 2012 at 11:18 AM, Smashed <static.void....@gmail.com> wrote:
> I would like to have puppet manage a puppet server, puppet dashboard and
> puppet agents. Do you think it would be best to create one puppet module that
> does all of these or is it best to break these out into 3 separate modules
> (puppet-server, puppet-agent, puppet-dashboard, etc
> If you've got things that are related in concept, like these three, I'd
> suggest keeping them in the same module but in three separate classes. As you
> expand their functionality, if you find it's not worth maintaining everything
> as one module, you can easily split things out. For example, you could have a
> puppet module with puppet::agent, puppet::master & puppet::dashboard classes.
> Perhaps they interact with each other, perhaps they don't.
> Also within modules is there any general best practices for organizing your
> classes and configuration applications? For example I read in the Pro Puppet
> book its usually good to have an install, config and service class.
>
> Unless you're getting really complex and lengthy with your implementation, I
> don't recommend this practice. It might seem clean but you could quickly run
> into class containment and ordering issues. Start by properly expressing
> dependencies between resources inside your agent class for example and go
> from there. More on containment here:
> http://docs.puppetlabs.com/puppet/3/reference/lang_containment.html
>
>
> Also, check out the Puppet Forge for content that may suit your needs now or
> give you inspiration and a place to start from. http://forge.puppetlabs.com/
>
> The modules for managing Puppet (especially ours) there need a good bit of
> love but pull requests accepted!
>
>
> Thanks
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/puppet-users/-/W8PKqLTCrFUJ.
> 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.
>
>
>
> --
> Ryan Coleman | Modules & Forge | @ryanycoleman | ryancoleman in #puppet
>
>
>
>
> --
> 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.
