In very large environments, we may worry about having enough resources to serve all of our agents. We start building more compile masters and our agents need to connect to them. There are only a few key additional concerns when placing our compile masters behind a load balancer: certificate management and load balancing strategy.

Puppet builds trusted SSL connections between agents and masters at compile time using self-signed certificates. The FQDN of both the master and the agent are recorded in their respective certs by default. During each connection, the agent inspects the certificate to ensure that the requested domain name is in the certificate. If our agent uses DNS or a VIP from load balancing to connect to a master at puppet.example.com, and the certificate does not contain that name explicitly, the agent will reject the connection. We want to identify a common name for our pool of compile masters (often just a shortname, such as puppet), and embed that into the certificate. We can include multiple DNS alt names in the puppet.conf in the main section on each compile master:

[main]
dns_alt_names = puppet,puppet-portland
...

When we connect to the Puppet Master for the first time, these dns_alt_names will be embedded into our certificate. For Enterprise users, this certificate will not show up in the Puppet Enterprise console, so that no one can accidentally approve DNS alt names from the GUI. You'll need to log in to the Puppet Master and run puppet cert sign <name> --allow-dns-alt-names to sign the certificate, and accept it with alternate names. If you have already built this compile master and need to regenerate the certificates, you can run puppet cert clean <name> on the Master of Masters, and remove the SSL directory with sudo rm -r $(puppet master --configprint ssldir) on the compile master prior to running the agent again.

Your agents should now be referring to all compile masters by their common DNS alt name. You'll need to decide a load balancing strategy: using DNS round robin, DNS SRV records, or a dedicated load balancer. Major DNS providers provide a mechanism for DNS round robin and SRV records, and you should consult their documentation. We'll walk through a sample of setting up HAProxy as a software load balancer for our compile masters, as if they were all in a single pool. We'll be using puppetlabs/haproxy and the usage sample on the forge to build a HAProxy instance for multiple compile masters. We could use our exported resources sample from Chapter 9, Exported Resources, but we'll use a simple example as we don't often add Puppet Masters to our load balancer:

class puppet::proxy {

  include ::haproxy

  haproxy::listen { 'puppetmaster':
    collect_exported => false,
    ipaddress        => $::ipaddress,
    ports            => '8140',
  }

  haproxy::balancermember { 'master00':
    listening_service => 'puppetmaster',
    server_names      => 'master00.packt.com',
    ipaddresses       => '10.10.10.100',
    ports             => '8140',
    options           => 'check',
  }
  haproxy::balancermember { 'master01':
    listening_service => 'puppetmaster',
    server_names      => 'master01.packt.com',
    ipaddresses       => '10.10.10.101',
    ports             => '8140',
    options           => 'check',
  }
}

Using this configuration, our HAProxy will be able to serve requests to all agents requesting a connection to a compile master.