Puppet's Services: The WEBrick Puppet Master
Puppet master is the application that compiles configurations for any number of puppet agent nodes, using Puppet code and various other data sources.
Puppet has the built-in capability to run a complete puppet master server using Ruby’s WEBrick library.
The WEBrick puppet master server is not capable of handling production-level numbers of agent nodes. Since it can’t handle concurrent connections, it will be quickly overwhelmed by as few as 10 agents. You should never run a WEBrick puppet master in production, and should always configure a Rack puppet master server instead.
Controlling the Service
The WEBrick puppet master runs as a single Ruby process. You can manage it in one of two ways.
1.Use the puppetmaster Init Script
2.Run puppet master on the Command Line
The WEBrick Puppet Master’s Run Environment
The WEBrick puppet master runs as a single Ruby process. This single process does everything related to handling puppet agent requests: It terminates SSL, routes HTTP requests, and executes the Ruby methods that recognize agent requests and build responses to them.
Configuring a WEBrick Puppet Master
As described elsewhere, the puppet master application reads most of its settings from puppet.conf and can accept additional settings on the command line.
When running from the command line, puppet master can directly accept command line options. When running via an init script, it sometimes gets command line options from an init script config file. The location and format of this file will vary depending on your platform.
To change the puppet master’s settings, you should generally use puppet.conf. The only two options you may want to set on the command line or in the init script config file are --verbose or --debug, to change the amount of detail in the logs.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Puppet's Services: The Rack Puppet Master
Puppet includes a basic puppet master web server based on Ruby’s WEBrick library. (This is what Puppet uses if you run puppet master on the command line or use most puppetmaster init scripts.)
You cannot use this default server for real-life loads, as it can’t handle concurrent connections; it is only suitable for small tests with ten nodes or fewer. You must configure a production quality web server before you start managing your nodes with Puppet.
Any Rack-based application server stack will work with a puppet master, but if you don’t have any particular preference, you should use Passenger combined with Apache. This guide shows how to configure Puppet with this software.
Controlling the Service
Under Rack, the puppet master processes are started and managed by your Rack web server. The way to start and stop the puppet master will depend on your specific web server stack.
If your Rack stack isn’t running any other applications or sites, you can simply start and stop the whole server process; if it also provides other services, as a Passenger/Apache stack sometimes does, you may need to disable the puppet master’s virtual host and do a graceful restart.
The Rack Puppet Master’s Run Environment
Rack and the puppet master application each have various expectations about their environment. To make them work together, you’ll need to make sure these expectations are met.
Configuring a Rack Puppet Master
As described elsewhere, the puppet master application reads most of its settings from puppet.conf and can accept additional settings on the command line. When running under Rack, puppet master gets its command line options from the config.ru file. By default, it only sets the confdir and vardir settings and the special --rack option.
To change the puppet master’s settings, you should use puppet.conf. The only two options you may want to set in config.ru are --verbose or --debug, to change the amount of detail in the logs.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Aside: How a Rack Puppet Master Works
A Rack web server loads and executes a special part of Puppet’s Ruby code, which creates a puppet master application object that can respond to specially formatted requests. To handle parallel requests, it can do this any number of times. (The number of workers depends on how the Rack server is configured.)
When an HTTPS request comes in, the web server passes it to Rack. Rack reformats the request, turning it into a Ruby object that contains all of the relevant information (URL, method, POST data, headers, SSL info). It then passes the formatted request to the application object.
The puppet master application reads information from the request, then builds a response, doing whatever is necessary to construct it. This may involve returning file contents, returning certificates or other credentials, or the full process of catalog compilation (request a node object from an ENC, evaluate the main manifest, load and evaluate classes from modules, evaluate templates, collect exported resources, etc.). The puppet master object then formats its response and passes it to Rack, which passes it on to the web server and the agent node that made the request.