Pulling Strings With Puppet - James Turnbull [5]
To provide the client-server connectivity, Puppet uses XML-RPC web services running over HTTPS on TCP port 8140. To provide security, the sessions are encrypted and authenticated with internally generated self-signed certificates. Each Puppet client generates a self-signed certificate that is then validated and authorized on the Puppet master.
Note - Puppet currently uses XML-RPC web services, but at the time of writing a significant update and refactor of the code was taking place to migrate it to a REST-based web services model (http://en.wikipedia.org/wiki/Representational - State_Tra nsf er). This migration should provide much more efficient and elegant web service functionality.
Thereafter each client contacts the server, by default every half hour, to confirm that its configuration is up to date. If new configuration is available or the configuration has changed, it is recompiled and then applied to the client. If required, a configuration update can also be triggered from the server, forcing configuration down to the client. If any existing configuration has varied on the client, it is corrected with the original configuration from the server. The results of any activity are logged and transmitted to the server.
You can see Puppet's client server model in Figure 1-1.
Figure 1-1. Puppet client-server model
Puppet, however, is more than just a client-server configuration management tool-it's a tripartite architecture combining a declarative language, transactional layer, and resource abstraction layer. Let's take a closer look at each.
A Declarative Language
At the heart of how Puppet works is a language that allows you to articulate and express your configuration. Your configuration components are organized into entities called resources, which in turn can be grouped together in collections. Resources are made up of a type, title, and a series of attributes. You can see an example of a simple resource in Listing 1-1.
The resource in Listing 1-1 alters the configuration of the /etc/passwd file, changing its ownership to the root user. Inside Listing 1-1 the type being used is the file type. The resource type tells Puppet what type of resource you are managing, for example, the user and file types that are used for managing user and file operations on your nodes, respectively. Puppet comes with a number of resource types by default including types to manage files, services, packages, cron jobs, and file systems, among others. Inside our type we've specified the file to be managed, /etc/passwd; this becomes the title of our resource. When referring to the resource in other parts of our configuration, we'd reference this title. Lastly, we've specified a single attribute, owner, which tells Puppet to set the ownership of the file to the root user.
Note - As you'll learn in Chapter 7, you can also extend Puppet to add your own resource types.
We can extend beyond these single resources with collections. Collections allow you to group together many resources; for example, an application such as Apache is made up of a package, a service, and a number of configuration files. Puppet calls these collections classes. Each of these components would be represented as a resource (or resources) and then collected together in a class and applied to a node.
The Puppet language also defines the nodes you wish to configure. After a client is connected to Puppet, a node definition can be created that defines what resources and collections of resources are applied to each node. This allows you to apply appropriate configuration to all nodes running a particular platform or a particular service, for example, specifying all resources required for Red Hat Enterprise Linux nodes or all configuration required for a database or web server.
The Puppet language also allows the use of features you'll find in many programming languages, such as variables, arrays, and conditional statements