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
- using CI (Jenkins likely) to provide a more robust capability of
checking manifests/modules before they get pushed out to puppet masters
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
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
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
Any suggestions would be greatly appreciated.
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 email@example.com.
To post to this group, send email to firstname.lastname@example.org.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.