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 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. 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On 11/24/2012 11:18 AM, Smashed 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 > > 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.It''s almost always better to have modules that do as little as possible. Easier to write, test, and set ordering between them. Also discrete bits of functionality are far more reusable than large do everything modules. And you can always create a wrapper class. class role::puppetserver { include puppet include puppetdashboard include puppetmaster } node /^puppetmaster\d+/ inherits basenode { include role::puppetserver } Also don''t use hyphens in class names. http://docs.puppetlabs.com/puppet/2.7/reference/modules_fundamentals.html#allowed-module-names Ramin -- 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 Sat, Nov 24, 2012 at 11:18 AM, Smashed <static.void.dev@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+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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 <ryan@puppetlabs.com> wrote:
>
>
>
> On Sat, Nov 24, 2012 at 11:18 AM, Smashed <static.void.dev@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+unsubscribe@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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
On 11/25/2012 8:50 AM, Mark wrote:> 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.Depends on your infrastructure. If you always use nginx with rails, then include ngnix within the Rails class makes sense. Of course you may create a new hostgroup sometime in the future that needs Rails and does not need nginix that will require you to make some changes. However I think you''ll get far more work done if you just plow ahead and don''t worry too much about having to refactor later. You''ll have to do it regardless because no system you create is going to be (or needs to be) that flexible. Also it''s poor etiquette to ask your questions repeatedly on other people''s threads. Create a new thread for your question. Ramin -- 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 Sun, Nov 25, 2012 at 8:50 AM, Mark <static.void.dev@gmail.com> wrote:> 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? >Well no, don''t just shove everything in one file. My advice is to keep things logically together. If you''re managing your nginx web service, do that in your nginx class. If you''re managing a rails plugin for nginx, perhaps nginx::rails is a better class name. There''s a lot of nuance to this, not hard and fast rules. One thing you really need to adhere to is the autoloader. Pay close attention to this doc: http://docs.puppetlabs.com/puppet/3/reference/lang_namespaces.html#autoloader-behavior> > 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: >Ramin covered my advice here. :)> > 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 <ryan@puppetlabs.com> wrote: > > > > > On Sat, Nov 24, 2012 at 11:18 AM, Smashed <static.void.dev@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+unsubscribe@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+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.