bluebay2014 - Fotolia
How the Puppet architecture manipulates configurations
Puppet is intrinsically scalable, enabling IT teams to manage one machine or hundreds. Its architecture makes the configuration management tool compatible with a range of IT setups.
Puppet is a top configuration management tool for IT operations administrators and developers alike. It allows automated deployment of a desired state to target machines, which eases server management.
Puppet users describe a desired state that the machine should be in using Puppet's configuration language. The Puppet architecture enforces this state, even if an administrator or user makes accidental or out-of-spec changes to a managed machine. The benefit of this approach is scalability: It works for a single machine, as well as for hundreds in a large data center.
Inside the Puppet architecture
Puppet uses a client-server model, in which the Puppet master acts as the server and stores manifest files that describe the desired state of managed client machines. On the client -- also referred to as the Puppet node -- a Puppet process continuously runs, periodically asking the Puppet master for its manifest file and then applying it if necessary. Within the Puppet architecture, the Puppet node initiates the action and requests the manifest file on a regular basis with the Puppet master. This can happen every 30 minutes, for instance.
The node runs the facter command when starting a session. This part of the configuration gathers data about the current state and sends it to the Puppet master. Based on that information, the Puppet master creates a catalog for each individual node. This catalog describes the work for a specific node. Puppet creates an idempotent configuration by describing the target state in an absolute way -- no matter how often the catalog is applied, the result will always be the same target state.
Once compiled, the catalog is sent to the node that runs it, thus acquiring the desired state. At the end of this procedure, the node reports any applied changes to the master. The master knows what occurred on all nodes, allowing reporting tools to request more information for administrators.
Manageable items
The Puppet architecture handles basically every aspect of a node configuration, such as users, files, packages and services. For example, it can ensure that a user is created -- or removed -- or that a service is running or stopped. To do so, it uses the high-level Puppet programming language, of which you'll find a simple example below:
user { 'bob':
ensure => 'absent',
}
This example code ensures that, on any node system where it is applied, no user with the name Bob will exist. If an administrator or a process creates such a user, Puppet removes the user the next time the node contacts the Puppet master. A somewhat more complex code defines that a file should exist, and which properties it should have:
file { '/srv/www/index.html';
ensure => 'file',
owner => 'root',
group => 'root',
mode => '0640',
}
The Puppet architecture manages state by defined resources, such as users, service, files and packages. When issuing the puppet-resource --types command on a node, you'll see a full list of available resources. For example, the exec resource allows you to run a command, and the notify resource allows a log message to be written.
While some resources are described simply, administrators must describe dependencies to build a sophisticated Puppet environment. Dependencies define how resources interrelate. This enables administrators to efficiently organize code and build conditional trees where specific actions only execute if prerequisite conditions are met.
The resources in a Puppet architecture are written in manifest files, which typically use the extension .pp, and are applied to the client machine using the puppet command. Puppet users can write manifest files with a text editor or more sophisticated manifest build and management tools, such as the graphical Geppetto interface.
The strength of the Puppet architecture is in its scalability. These components aid IT teams in a small environment, using only one type of operating system. But the same design also applies to large environments, where multiple operating systems can benefit from the abstracted Puppet descriptive language and the idemopotent directives ensure that each server meets the state that Puppet defined for it.
