Pro Puppet (26 page)

The
X-SSL-Subject
and
X-Client-DN
headers contain the same information, the common name from the verified SSL certificate presented by the Puppet agent. This information is provided in two headers to support back-end HTTP servers other than Apache. The
X-Client-Verify
header indicates to the back-end worker whether or not the load balancer was able to verify the authenticity of the client SSL certificate. This value will be
SUCCESS
in Apache if the client certificate is signed by a trusted Certificate Authority, is not listed in the Certificate Revocation List, and has not expired.

The information set in the client request headers directly matches the
SetEnvIf
configuration lines configured in the back-end Puppet master virtual host. We can see these lines in
/etc/httpd/conf.d/40_puppetmaster_worker_18140.conf
as we configured them in
Listing 4-9
:


The authentication information in a load-balanced Puppet master configuration is passed from the load balancer to the back-end workers using client request headers. This design allows heterogeneous front-end and back-end HTTP systems to work together as long as the back-end HTTP server is able to read the Puppet agent certificate common name and determine whether or not the certificate is currently valid. Once read from the headers, the back-end HTTP server sets this information in two environment variables for Puppet to reference.

The third important section in the front-end load balancer configuration in
Listing 4-11
tells Apache to route all requests to the pool of Puppet master virtual hosts. This section is composed of the three lines,
ProxyPass
,
ProxyPassReverse
,
ProxyPreserveHost
. These three statements tell Apache the virtual host listening on port 8140 should forward all Puppet agent requests to the pool of Puppet master workers named
balancer://puppetmaster
.

We’re now almost ready to test the new Puppet master configuration using the Puppet agent. Before doing so, you need to make sure each virtual host is logging information in a clearly defined location. This will allow you to trace the Puppet agent request as it passes through the front-end load balancer to the back-end worker virtual host.

To make it easier, let’s separate out the logging events for each virtual host by adding
ErrorLog
and
CustomLog
configuration options to each configuration file, as shown in
Listing 4-13
.

Only three lines need to be inserted into the
…
stanza to enable logging on the front end. Every request coming into the Puppet master infrastructure will pass through the front-end virtual host and will be logged to the
balancer_access.log
file.

Worker virtual hosts do not handle SSL encrypted traffic and only require two configuration lines to be inserted into the
VirtualHost
stanza. Every request routed to a specific worker will be logged into that worker’s access log file. In
Listing 4-14
, we’ve included the TCP port number of the worker to uniquely identify the log file and the associated worker.

Once the front-end load balancer and back-end worker virtual hosts have been configured to log to their own log files, you need to restart Apache and makes sure the log files were created properly.

With the appropriate log files in place, you can now test the load balancer and the single back-end worker using
puppet agent
:

Here we’ve run the
puppet agent
command and obtained a catalog from the Puppet master. The Apache load-balancing virtual host listened on
puppet.example.com
port 8140 and received the Puppet agent request, forwarded it along to the back-end Puppet master virtual host listening on port 18140, and then provided the response back to the Puppet agent.

We can check the Apache logs to verify that this is what actually happened, as shown in Listings 4-15 through 4-17.

In
Listing 4-15
, you can see the incoming Puppet agent catalog request at 3:40:51 PM. The front-end load balancer receives the request and, according to the
balancer_error.log
shown in
Listing 4-16
, disables the worker virtual host on Port 18141. This leaves one additional worker in the
balancer://puppetmaster
pool, which receives the request, as indicated in
puppetmaster_worker_access_18140.log
shown in
Listing 4-17
. Finally, the Puppet agent uploads the catalog run report a few seconds later.

What happens, however, if all the back-end workers are disabled?  Well, let’s see. To do this, disable the Puppet master virtual host by renaming the configuration file:

Restarting Apache:

And then running the Puppet agent again:

We’ve discovered that the Puppet agent receives error 503 when no back-end Puppet master worker virtual hosts are available. The front-end load balancer runs through its list of back-end workers defined in the
Proxy balancer://puppetmaster
section of
30_puppetmaster_frontend_8140.conf
file. Finding no available back-end workers, the front-end returns HTTP error code 503, Service Temporarily Unavailable to the client. This HTTP error code is also available in the front-end load balancer’s error log file (
Listing 4-18
).

Now that you’ve seen one and no back-end masters working, let’s bring back both workers back online. In doing so, you will configure the second Puppet master worker.

The second back-end worker running on TCP port 18141 is almost identical to the first worker virtual host configuration, except the port number is incremented by one. First re-enable the first back-end worker, and then define the second back-end worker:

This command renamed the disabled configuration file back to the original name of
40_puppetmaster_worker_18140.conf,
effectively re-enabling the worker virtual host listening on port 18140.

This command reads the configuration file of the first worker and writes out a new configuration file for the second worker. While the original file is being read and the new file written, the sed command is performing a search-and-replace, replacing all instances of “18140” with “18141.”  The results are two nearly identical worker virtual hosts, the only difference being the port and the log files:

The Rack configuration for each worker process is identical and needs no modification when bringing additional workers online. Using the rsync command, we’re able to create an identical copy of the existing Puppet rack configuration for use with the new worker virtual host.

Using the diff command, we’re able to easily visualize the lines modified by the sed command. As you can see in
Listing 4-19
, the difference between the two worker configuration files is only a matter of the listening port and the log files.

As you can see, we configure a unique Rack
DocumentRoot
for each back-end Puppet master worker process. This is important to allow Passenger to track and identify each of the multiple Puppet masters. After configuring the second back-end worker virtual host, restart Apache:

And test the Puppet agent again: