FAQ
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.

Search Discussions

  • Ramin K at Nov 24, 2012 at 8:26 pm

    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.
  • Ryan Coleman at Nov 24, 2012 at 11:19 pm

    On Sat, Nov 24, 2012 at 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
    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.
  • Mark at Nov 25, 2012 at 4:59 pm
    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 wrote:




    On Sat, Nov 24, 2012 at 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
    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.
  • Ramin K at Nov 25, 2012 at 6:07 pm

    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.
  • Ryan Coleman at Nov 25, 2012 at 7:13 pm

    On Sun, Nov 25, 2012 at 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?
    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 wrote:



    On Sat, Nov 24, 2012 at 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
    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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedNov 24, '12 at 7:18p
activeNov 25, '12 at 7:13p
posts6
users3
websitepuppetlabs.com

3 users in discussion

Mark: 2 posts Ryan Coleman: 2 posts Ramin K: 2 posts

People

Translate

site design / logo © 2022 Grokbase