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+unsubscr...@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.
