Pro Puppet (25 page)

The problem of scaling HTTP-based web services to tens of thousands of clients has been around for quite some time. There are many technical solutions provided by commercial products like Citrix NetScaler, Cisco IOS, and F5 BIG-IP. Many open-source software projects also exist, including Apache itself, HAProxy, Nginx, and Pound. Puppet fits into the overall problem of HTTP load balancing nicely because of its use of SSL and HTTP for communication.

We’re going to build upon the single Puppet master configuration we just created and then split the work across two Puppet master systems. We’ll use the Apache Web server to handle the incoming Puppet agent requests and route them to an available back-end Puppet master. If we require additional capacity, we can add additional Puppet master processes. This configuration has the added benefit of high availability. If a particular Puppet master system has trouble or needs to be taken out of service, the front-end load balancer will stop routing Puppet agent requests to that master process.

We’re going to configure two Puppet master Apache virtual hosts, much like the virtual host we created in the previous section. However, there is one important difference: we will disable SSL for the Apache virtual hosts. Instead, we’ll configure a new front-end Apache virtual host to authorize incoming Puppet agent requests and handle the SSL encryption and decryption of the traffic. This front-end load balancer will terminate the SSL connection, be responsible for authenticating the Puppet agent request and then present this authentication information to the back-end Puppet master workers for authorization.

You’ll see how Apache is able to pass the authentication information along through the use of client request headers, and how the back-end virtual hosts are able to set environment variables for the Puppet master based on the values of these client request headers.

When running the Puppet master behind a load balancer, there will be multiple Puppet master processes running on different hosts behind the load balancer. The load balancer will listen on the Puppet port of 8140. Incoming requests will be dispatched to available back-end worker processes, as illustrated in
Figure 4-1
. The example configuration presented in this chapter configures the Puppet CA and workers all on the same host using unique TCP ports bound to the loopback interface.

Figure 4-1.
Puppet master workers

To get started with our load-balancing configuration, you’ll copy the existing Puppet master virtual host we configured in the previous section into two additional virtual host configurations. Each of these two virtual hosts will have SSL disabled. You’ll then create a third virtual host listening on the standard Puppet master port of 8140 with SSL enabled. This virtual host will forward a request to any available back-end virtual host.

First, move the existing Puppet master to port 8141 to free up port 8140 for the new front-end load balancer virtual host. To do this, update the Listen and VirtualHost configuration items in the Apache Puppet master configuration, in our case in the
20_puppetmaster.conf
file we created earlier:

This change to the virtual host only required two small edits to the TCP port configuration in
20_puppetmaster.conf
.

Next, create a new Puppet master virtual host configuration for the first back-end worker in
/etc/httpd/conf.d/40_puppetmaster_worker_18140.conf
.

In
Listing 4-9
, we configure a unique Rack
DocumentRoot
in order to uniquely identify the first Puppet master worker. Commands such as
passenger-status
identify processes by their configured
DocumentRoot
.

In addition to the configuration file, you need to duplicates the Rack configuration directory into the new
DocumentRoot
location (see
Listing 4-10
).

Note the trailing slash in the
rsync
command, which is important and ensures that the directory contents are copied into one another.

After we configure the first back-end Puppet master worker, we need to configure the front-end virtual host. This front-end virtual host is going to perform a number of tasks:

1. Terminate the SSL connection
   
2. Authenticate the client request
   
3. Set the authentication information in client request headers
   
4. Pass the request along to one of the available back-end worker processes.
   

The configuration file for the front-end load balancer is very similar to the original Apache Passenger configuration file with the addition of a reverse proxy stanza and the removal of the Passenger and Rack configuration stanzas (
Listing 4-11
).

There are three main differences between the front-end load balancer configuration file in
Listing 4-11
and the stand-alone Apache Puppet master configuration in
Listing 4-6
. At the top of the load balancer virtual host configuration, a pool of back-end virtual hosts is defined in the
Proxy
stanza. Notice that two virtual hosts are listed, port 18140 and port 18141, even though we have only configured the one listening on port 18140 so far.

Part of the responsibility of the front-end load balancer is to determine if each back-end worker is online and available to handle requests. Since no worker virtual host is available on port 18141 yet, the front-end virtual host will automatically take http://127.0.0.1:18141 out of rotation until it becomes available. The Puppet agent nodes will not see an error message unless all back-end worker virtual hosts are marked as offline.

In addition to defining the list of back-end worker virtual hosts, the
Proxy
stanza gives the name
balancer://puppetmaster
to the collection. When additional back-end virtual hosts are added to the system, they should be listed using the
BalancerMember
keyword in the
Proxy
stanza. Once listed, they’ll automatically be added to the rotation of back-end workers used by the front-end virtual host listening on port 8140.

The second important section of the front-end virtual host configuration file is the three
RequestHeader
lines. These three configuration statements configure the front-end load balancer to set three client request headers containing authentication information. When a back-end Puppet master virtual host receives a client request from the load balancer, it will inspect these client request headers and set environment variables based on their contents. The Puppet master process will look to these environment variables while authorizing the Puppet agent request.

For the Puppet agent running on
mail.example.com
, the client request headers used for authentication look as shown in
Listing 4-12
.