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
<millerjl1701@gmail.com>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.