Puppet

Schéma de base

Description

We suggest to use two HAProxy servers for load balancing the requests to the Puppet servers.

At TCP level, HAProxy will be configured as transparent TCP proxy. If HAProxy should be subject to some scalability issues, the machines can be configured in such a way to send HTTP redirects – if the puppet client can still follow the requests.

Load balancing can be achieved by dispatching the number of connections for the puppet servers running on the WORKERs. For safety reasons, the number of connections should be limited. The two HAProxy servers are accessed via an DNS server in round robin mode - which is common to all clients.

We suggest to not rely on Puppet’s the default certificate mangament structure, which is based on on a CSR (certificate signing request) per client manually signed by an admin. Our approach is to cope with the certificates in advance. The certificate generation is supported by an additional script of the puppet-addon package, and will also generate the correct dns-alt-names for configuring correctly the servers in case you do not use the HAProxy based solution. This approach requires the deployment of the certificates before launching puppet. The CA and the certificates will be deployed locally (and not on the gluster file system). Only the CRLs are to be shared amongst all puppet servers.

Via git hooks we can launch an r10k deployment.`r10k` will use a git repository shared on gluster (and not shared via ssh).