如何使用一个木偶代理的多个不同的木偶大师？

Question

There is the need that one puppet agent contacts some different puppet masters.

Reason: there are different groups that create different and independent sets of manifests.

Possible groups and their tasks

• Application Vendor: configuration of application
• Security: hardening
• Operations: routing tables, monitoring tools

Each of these groups should run it's own puppet master - the data (manifests and appropriate data) should be strictly separated. If it is possible, one group should even not see / have access to the manifests of the others (we are using MAC on the puppet agent OSes).

Thoughts and ideas that all failed:

• using (only) hira is not flexible as needed - there is the need to have different manifests.
• r10k: supports more than one environment, but in each environment can only access one set of manifests.
• multi but same puppet server using eg DNS round robin: this is the other way round. We need different puppet masters.

Some ways that might be possible but...

• running multiple instances of puppet agents. That 'feels' strange. Advantage: the access rights can be limited in the way as needed (eg the application puppet agent can run under the application user).
• patching puppet that it can handle more than one puppet master. Disadvantage: might be some work.
• using other mechanisms to split responsibility. Example: use different git-repositories. Create one puppet master. The puppet master pulls all the different repositories and serves the manifests.

My questions:

1. Is there a straight forward way implementing this requirement with puppet?
2. If not, is there some best practice how to do this?

Answer 1

While I think what you are trying to do here is better tackled by incorporating all of your modules and data onto a single master, and that utilizing environments will be effectively the exact same situation (different masters will provide a different set of modules/data) this can be achieved by implementing a standard multi-master infrastructure (one CA master for cert signing, multiple compile masters with certs signed by the same CA master, configured to forward cert traffic elsewhere) and configure each master to have whatever you need. You then end up having to specify which master you want to check in to on each run (a cronjob or some other approach), and have the potential for one checkin to change settings set by another (kinda eliminating the hardening/security concept). I would urge you to think deeper on how to collaborate your varied aspects (git repos for each division's hiera data and modules that have access control) so that a central master can serve your needs (and access to that master would be the only way to get data/modules from everywhere). This type of setup will be complex to implement, but the end result will be more reliable and maintainable. Puppet inc. may even be able to do consultation to help you get it right.

There are likely other approaches too, just fyi.

Answer 2

I've often found it convenient to multi-home a puppet agent for development purposes, because with a local puppet server you can instantly test manifest changes - there's no requirement to commit, push and r10k deploy environment like there is if you're just using directory environments and a single (remote) puppet server.

I've found the best way to do that is to just vary the path configuration (otherwise you run into problems with eg the CA certs failing to verify against the other server) - a form of your "running multiple instances of puppet agents" suggestion. (I still run them all privileged, so they can all use apt package {} etc.)

For Puppet 3, I'd do this by varying the libdir with --libdir (because the ssldir was under the libdir), but now (Puppet 4+) it looks more sensible to vary the --confdir . So, for example:

$ sudo puppet agent -t                 # Runs against main puppet server
$ sudo puppet agent -t \
  --server=puppet.dev.example.com \
  --confdir=/etc/puppetlabs/puppet-dev # Runs against dev puppet server