Dealing with many puppet masters

Hi,

I wrote a note [1] to the list a while back about provisioning
smart-proxies with puppet masters. It was briefly discussed that Foreman
assumes that all puppet class/environment combinations are the same across
all puppet masters, and that if puppet masters need to have different
classes, then the only way to accomplish that is to use unique environments
on each master. I'm looking for some thoughts/advice on how to organize or
manage a foreman infrastructure with multiple Org+Loc based puppet masters
whose classes are locally managed…e.g. the proxy/master's system admin is
not the enterprise foreman system admin.

Maybe I'm way off, but I imagine this concept is a fairly common user story
for large enterprise that's using Satellite Server or Foreman with multiple
locally admin'd proxies.

In my specific user story, we have roughly of 10,000 Linux workstations of
various distributions that belong to various orgs+locs, and at the
enterprise level we need to ensure policy compliance, but give flexibility
at the local level to deviate from policy and manage configurations beyond
the policy via puppet as required. On the Windows Desktop side, they use
SCCM and AD to ensure compliance, but Linux - especially distro-diverse
Linux - needs something like Puppet/Foreman. Foreman is a great tool here
because it gives us the ability to combine policy that is only enforceable
at provision time with policy that is required to be enforced throughout
the system's life cycle. There is also the added bonus of having the SCAP
plugin to produce compliance reports. The catch is, we also have
restricted access silos and I (the enterprise Foreman Admin) would not have
direct access to any of the smart-proxy/puppet-masters which are provided
by various org+loc IT groups.

The strategy I'm currently developing begins with using r10k to populate
the policy oriented puppet modules on the masters in the
/etc/puppet/environments/common directory. Each puppet master unique
dev/test/prod environments (e.g. environment names would be prefixed with
org/loc info and default environments would be removed) where the local
admins can deposit their modules. I have not used r10k yet, and do not
quite understand how it works yet. Also, I wonder if r10k can cooperate
with Foreman and its need to import classes from the masters if it can at
all.

Any thoughts on this strategy or suggestions on a better one would be much
appreciated.

Thank you kindly!

[1] https://groups.google.com/forum/#!topic/foreman-users/duFppG71Jaw

Broadly speaking, Foreman doesn't care how you get the classes onto the
masters - scp, git, r10k, librarian, it really doesn't matter. What does
matter is that they are there when you do the import into Foreman, since
that's the point at which it will call out to the proxy to scan the puppet
files and report back on what's there.

In other words, you should be fine with that strategy. Bonus points for
automatically calling an import when a class deploy is completed, via the
Foreman API :slight_smile:

Greg

··· On 18 February 2016 at 16:42, Sean A wrote:

The strategy I’m currently developing begins with using r10k to populate
the policy oriented puppet modules on the masters in the
/etc/puppet/environments/common directory. Each puppet master unique
dev/test/prod environments (e.g. environment names would be prefixed with
org/loc info and default environments would be removed) where the local
admins can deposit their modules. I have not used r10k yet, and do not
quite understand how it works yet. Also, I wonder if r10k can cooperate
with Foreman and its need to import classes from the masters if it can at
all.