FAQ
We have several internal customers that we would like to start offering
"Puppet as a Service" to. Our central group would manage Puppet masters,
ENC, etc. But, we want other independent groups to be able to use our
Puppet services.

Is anyone currently doing this? If so, how are you handling segregation of
manifests? Are you creating multiple environments for each internal
customers (perhaps with one common environment shared amongst all for base
configuration).

Any suggestions would be greatly appreciated.

Thanks,

Josh

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Jeffrey Miller at Sep 11, 2013 at 3:00 pm
    Thanks for raising the question! One of the primary points I explored at
    this year's PuppetConf was to see what others were doing in this area and
    figure out what is possible with the puppet in its current state. Your
    mileage may vary on this... and keep in mind we are in the exploration
    stages of how to do this and that I work in a university environment...

    We setup separate environments for groups based on administrative domain
    boundaries (i.e. common sets of admins). Access to the environments is done
    at the code repository level and then the repositories are pulled into the
    puppet masters. This prevents modules/manifests from spilling over and
    affecting servers that a particular set of admins don't (and shouldn't)
    manage. We are currently moving to three layers modules for puppet masters
    to parse: a common set of modules, an "org" set of modules, and then the
    environment set of modules. The common set of modules primarily comes from
    the puppet forge. The second layer of "org" modules are placed where we
    have overlaps of admins and/or services across multiple environments but
    where those methods/modules are not (or should not) be available for all
    environments site wide... (think University - College - Department...
    disparate system monitoring tool preferences for groups... etc.). The last
    layer of modules would be the modules found in the environment itself.

    Currently, I am working on how to provide access to PuppetDB and a
    reporting dashboard that respects the administrative boundaries. PuppetDB
    does not support environments (yet... there is an open feature request for
    that) so separate PuppetDBs need to be setup along some administrative
    boundary partition scheme... it looks like the ORG layer will suffice for
    that and those ENVs that aren't in an ORG would get a separate PuppetDB if
    needed. One of the major problems that I see with this are how you do a
    site wide look at the PuppetDB information for those operations that need
    it as well as mimicking federated queries using multiple PuppetDB backends.
    But, if it works, then the ORGs or groups can have their separate instances
    of puppet-dashboard or whatever web front end they want to use, and we
    won't have to worry about some complex convoluted way of putting access
    control in there... standard web access methods will work. PuppetDB will be
    key though in order to be able to automate this beast as much as possible
    as things progress.


    Other things on the to explore/figure out list for me are:
      - ENC? do groups of admins actually want this? provide via
    puppet-dashboard? theforeman? someotherwhizbangmethod?
      - dynamic branching git repositories being served side by side with more
    traditional static environment repositories
      - hiera availability for use in environments
      - automated horizontal scaling of puppet masters to handle additional
    loads as more systems are added in (hiera again likely key)
      - figure out how mcollective and subcollectives can fit into the mix... if
    at all...
      - using CI (Jenkins likely) to provide a more robust capability of
    checking manifests/modules before they get pushed out to puppet masters
      - ??
      - profit!

    There is a lot more in the ??... but this seems like a long enough response
    for now. :) It seems that setting up Puppet-as-a-Service is doable so
    that all the various administrative groups (and the auditors) will be
    happy.

    -Jeffrey




    On Wednesday, September 11, 2013 7:27:25 AM UTC-5, Josh wrote:

    We have several internal customers that we would like to start offering
    "Puppet as a Service" to. Our central group would manage Puppet masters,
    ENC, etc. But, we want other independent groups to be able to use our
    Puppet services.

    Is anyone currently doing this? If so, how are you handling segregation
    of manifests? Are you creating multiple environments for each internal
    customers (perhaps with one common environment shared amongst all for base
    configuration).

    Any suggestions would be greatly appreciated.

    Thanks,

    Josh
    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Josh Baird at Sep 11, 2013 at 3:35 pm
    Thanks for the detailed reply. I envision a setup similar to yours.

    We will be using Foreman for ENC, reporting, etc. The Foreman can already
    handle segregation of organizations/units/locations with ACLs very nicely
    so it should be a good fit for this type of scenario. In addition, we can
    easily allow customer's to provision their own servers/VM's etc.

    I haven't even began to think about the PuppetDB stuff, but I do envision
    separate prod/dev/qa environments for each "administrative team" or
    "customer" in our organization. I'm not sure we would need separate
    instances of PuppetDB. Perhaps we will have a common/"org" layer as well
    which will pull in modules that are common to each and every customer in
    our environment.

    Josh

    On Wed, Sep 11, 2013 at 10:57 AM, Jeffrey Miller wrote:

    Thanks for raising the question! One of the primary points I explored at
    this year's PuppetConf was to see what others were doing in this area and
    figure out what is possible with the puppet in its current state. Your
    mileage may vary on this... and keep in mind we are in the exploration
    stages of how to do this and that I work in a university environment...

    We setup separate environments for groups based on administrative domain
    boundaries (i.e. common sets of admins). Access to the environments is done
    at the code repository level and then the repositories are pulled into the
    puppet masters. This prevents modules/manifests from spilling over and
    affecting servers that a particular set of admins don't (and shouldn't)
    manage. We are currently moving to three layers modules for puppet masters
    to parse: a common set of modules, an "org" set of modules, and then the
    environment set of modules. The common set of modules primarily comes from
    the puppet forge. The second layer of "org" modules are placed where we
    have overlaps of admins and/or services across multiple environments but
    where those methods/modules are not (or should not) be available for all
    environments site wide... (think University - College - Department...
    disparate system monitoring tool preferences for groups... etc.). The last
    layer of modules would be the modules found in the environment itself.

    Currently, I am working on how to provide access to PuppetDB and a
    reporting dashboard that respects the administrative boundaries. PuppetDB
    does not support environments (yet... there is an open feature request for
    that) so separate PuppetDBs need to be setup along some administrative
    boundary partition scheme... it looks like the ORG layer will suffice for
    that and those ENVs that aren't in an ORG would get a separate PuppetDB if
    needed. One of the major problems that I see with this are how you do a
    site wide look at the PuppetDB information for those operations that need
    it as well as mimicking federated queries using multiple PuppetDB backends.
    But, if it works, then the ORGs or groups can have their separate instances
    of puppet-dashboard or whatever web front end they want to use, and we
    won't have to worry about some complex convoluted way of putting access
    control in there... standard web access methods will work. PuppetDB will be
    key though in order to be able to automate this beast as much as possible
    as things progress.


    Other things on the to explore/figure out list for me are:
    - ENC? do groups of admins actually want this? provide via
    puppet-dashboard? theforeman? someotherwhizbangmethod?
    - dynamic branching git repositories being served side by side with more
    traditional static environment repositories
    - hiera availability for use in environments
    - automated horizontal scaling of puppet masters to handle additional
    loads as more systems are added in (hiera again likely key)
    - figure out how mcollective and subcollectives can fit into the mix...
    if at all...
    - using CI (Jenkins likely) to provide a more robust capability of
    checking manifests/modules before they get pushed out to puppet masters
    - ??
    - profit!

    There is a lot more in the ??... but this seems like a long enough
    response for now. :) It seems that setting up Puppet-as-a-Service is
    doable so that all the various administrative groups (and the auditors)
    will be happy.

    -Jeffrey




    On Wednesday, September 11, 2013 7:27:25 AM UTC-5, Josh wrote:

    We have several internal customers that we would like to start offering
    "Puppet as a Service" to. Our central group would manage Puppet masters,
    ENC, etc. But, we want other independent groups to be able to use our
    Puppet services.

    Is anyone currently doing this? If so, how are you handling segregation
    of manifests? Are you creating multiple environments for each internal
    customers (perhaps with one common environment shared amongst all for base
    configuration).

    Any suggestions would be greatly appreciated.

    Thanks,

    Josh
    --
    You received this message because you are subscribed to a topic in the
    Google Groups "Puppet Users" group.
    To unsubscribe from this topic, visit
    https://groups.google.com/d/topic/puppet-users/HJOJSrqTmb4/unsubscribe.
    To unsubscribe from this group and all its topics, send an email to
    puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedSep 11, '13 at 12:27p
activeSep 11, '13 at 3:35p
posts3
users2
websitepuppetlabs.com

2 users in discussion

Josh Baird: 2 posts Jeffrey Miller: 1 post

People

Translate

site design / logo © 2022 Grokbase