• Choose a category
• All
• Classic-Fiction

For Debian-style distributions, including Ubuntu, you can use the a2enmod command to enable modules. Some modules may already be enabled. You can see the a2enmod command in Listing 6-11.

Listing 6-11. The a2enmod Command

After our modules, we define a Directory block for the root of our proxy and then a Proxy block. Inside the Proxy block, we specify the hostname of our proxy, in our case puppetmaster.testing. com. We also specify each load balanced member of the proxy.

Each of these members represents a puppetmasterd instance running Mongrel. In our configuration, each instance is started on a separate port on the local host, in our case ports 18140 and 18141. We can add as many instances as required. It is good practice to create instances by incrementing the port number, and we'll see how to do this later when we configure the Puppet master to support this configuration.

Then we configure our virtual host, again ensuring we specify the 8140 port. We turn on SSL for the virtual host and configure the location of our certificate files. These certificates are the Puppet certificates our master currently uses. The easiest way to do this is to create a symbolic link from the Puppet SSL directory, usually /etc/puppet/ssl, to our proxy directory, in our case /var/www/puppet.

We then specify our Puppet master's certificate and key file, and then the associated Certificate Authority (CA) certificate and certificate revocation list. Also inside our virtual host definition we define our ProxyPass statement that enables the proxy; you would replace puppetmaster.testing. com with the hostname of your proxy server.

Lastly, we specify the location, in our case /var/www/puppet, of a variety of logging files.

After configuring Apache, we need to start our Apache daemon. You can do this by running the Apache binary, for example, httpd on Red Hat-style hosts and apache2 on Debian-style hosts, and specifying the name of our configuration file.

Or

You could also integrate your Puppet proxy configuration into your existing Puppet configuration. Many distributions have a conf.d directory, for example, on Red Hat it's /etc/httpd/conf.d/, in which you can locate configuration files. You would then restart your Apache daemon to enable the new configuration.

Configuring Puppet for Mongrel

Enabling the Mongrel integration for Puppet is very simple. We start the puppetmasterd daemon with the --servertype mongrel option. To specify multiple puppetmasterd instances, we start each puppetmasterd with a different master port and process ID file.

We would then start the next instance with our port number incremented like so:

In Listing 6-12, you can see a simple script that you could easily convert into an init script, which allows you to start multiple puppetmasterd instances.

We would run the script in Listing 6-12 and pass in a variable for our master port like so:

We can now start as many Mongrel Puppet master instances as we like and our master host can sustain.

How Far Will Puppet Scale?

At this stage of Puppet development, there are no clear performance statistics regarding either the WEBrick or Mongrel web servers. Anecdotal evidence and some limited testing (conducted by Jeff McCune) indicate that the Mongrel web server is approximately 50% faster than the WEBrick web server. You can see the results of this indicative testing at http://reductivelabs.com/trac/puppet/wiki/PuppetScalability#MasterCompileTimings. The enhanced performance should extend Puppet's ability to service nodes and allow the connection of potentially thousands of nodes. At this stage, insufficient testing has been performed to determine exactly how many nodes can be connected and what volume of file serving and configuration supported for each node. The replacement of the XML-RPC architecture with a REST-based architecture is also likely to improve the performance of both the WEBrick and Mongrel web servers.