Last month we kicked off a contest to design the new tagline for our next t-shirt and now is the time for you to tell us who should win. We received a bunch of great entries and have narrowed it down to the following 8 finalists. Please vote for your favorite and decide the winner.

The person who submitted the winning entry will receive a BugBundle from Buglabs. It’s in your hands to determine who wins.

We are happy to make a new case study available from Sun Microsystems on how they are benefiting from their use of Puppet to manage their web server architecture. Martin Englund, a lead engineer at Sun Microsystems, describes how he uses Puppet to greatly accelerate system updates for the servers under his control as well as ensure a consistent environment across all his servers for his web developers.

Martin went on to say:

“With Puppet I don’t have to worry anymore. Once I have written and deployed the profiles I can count on Puppet ensuring timely updates and consistent configurations across all my systems. More than anything Puppet saves me time that I simply can’t afford to lose in supporting my data centers.”

Among the key benefits that Sun Microsystems has gained from using Puppet are:

• System consistency
• Improved effeciency
• Met compliance standards
• Increased visibility

Get the full details and download the case study by clicking below

Sun Microsystems Case Study

I came across this link today describing a few reasons why James Welcher at Berkeley Lab Commons decided to use Puppet instead of CFEngine. He includes a link to an article from Luke Kanies as well as some good links for migrating from CFEngine to Puppet.

In his words, the reason he ultimately decided on Puppet hinged on its ability to handle more complex tasks:

Puppet seems to handle more complex tasks, at the possible expense of more complex configuration, at least initially, but it can then handle “higher-level” funtions, like package management. This will be important to us if we are doing cross-platform (Linux as well as FreeBSD) management.

Many of the people we speak with are comparing Puppet with CFEngine and ultimately looking at the advantages they can gain from a more powerful tool. In part, Puppet was developed by Luke Kanies to address many of the shortcomings of CFEngine and to provide better tools to system administrators.

We are happy to make a new case study available from Los Alamos National Laboratory. Allan Marcus, a Solutions Architect, at Los Alamos, walks through how he used Puppet to gain visibility and control of their large deployed Mac OS X environment and meet NIST 800-53 security standards. Among the key benefits that they realized were:

• Enhanced Visibility
• Improved Effeciency
• Adherance to compliance standards
• Accelerated troubleshooting

When speaking about the benefits he realized from using puppet Allan says:

“Prior to using Puppet, managing the Mac OS X systems in our network was a challenge. There was a real lack of visibility into both the number of Macs on the network and their configuration. Puppet has made a real difference to our administrators who were previously having to walk to each Mac and service it individually.”

You can download the case study here:

Los Alamos National Laboratory Case Study

Calling the Puppet community.

We are currently looking for a replacement for our current t-shirt tagline “Because SSH and a ‘for’ loop doesn’t cut it” and we are asking you to help. Contribute your suggested tagline and if choose your tagline in our next t-shirt we will send you a BUGbundle from bug labs.

Submit your suggestions in one of the following ways:

• Submit it as a comment to this blog
• Submit it as a tweet with the hashtag #puppettee
• Add it to our Facebook wall for Reductive Labs
• Post it on the Puppet User group
• Email your idea to puppettee@reductivelabs.com

We look forward to seeing your ideas. We will choose a winner by the middle of February.

A common misconception about Puppet is that it can only be used in client/server mode. Although this is the most common use case, it is actually just one of three common deployment practices.

Client/Server model:

Client/server deployment is the most common and feature rich way to run Puppet. For any environments where multiple hosts are managed, client/server deployment is usually the way to go.

This mode has two executables, puppetmasterd (server), and puppetd (client). Knowing the roles of these executables is important for understanding the differences between these three deployment practices.

1. Client gathers local facts about its system using facter.
2. Client initiates a request to the server requesting the latest version of its catalog(description of desired configuration state)
3. Server compiles the configuration from source(manifests) into a catalog and returns it to the client.
4. Client applies the catalog, resulting in configuration changes.

This deployment strategy has several advantages over the standalone puppet execution.

• All configuration source is centrally stored and managed on the puppet server.
• The client only receives the configuration information that it needs (and can’t see the information that doesn’t).
  - The client doesnt have access to the source code, just the compiled catalog that applies to it.
• The server allows for more complicated management of nodes using an external node classifier (like the dashboard).
  - A node classifier allows assignment of classes and parameters to be handled by an external script. This allows information about how nodes are defined to be controlled by external data sources (think CMDB)
• Uses certificates to ensure that only authorized clients can retrieve configuration.
• Centralized function execution can simplify custom functions.

The main constraint of the client/server model of Puppet is that the server is CPU bound on catalog compilations. This can limit the scale at which puppet can be run on a single Puppet masters. The limiting factors of scale are:

• Number of hosts per Puppet server.
• Interval between client check-ins.

Many of these performance constraints have already been addressed in 0.25.x, and will continue to be improved upon as Puppet improves its ability to pre-compile catalogs

Single host:
One of the most overlooked features in Puppet is the puppet executable. This allows you to both compile and apply catalogs locally, removing the complexity of running in client/server mode.

This makes puppet a viable tool for application bootstrapping, even on one machine.

Executing:

#>puppet mymanifest.pp

will apply the configuration from the local source file mymanifest.pp to the local host. The puppet executable takes many of the same long options as puppet, namely:

• –noop – allows you to see the effects of the compiled catalog without making any modifications to the local machine
• –verbose, –debug – increased logging output
• –modulepath – puppet standalone can use modules to organize and re-use code just like client server
• –environment – standalone can also use multiple environments.

The puppet executable also reads configuration from the [puppet] section of puppet.conf

Running puppet on a single machine is not only a perfectly valid use case, it is also the best way to get started with the puppet language, and the best way to quickly develop and test new manifests.

Massively scalable deployments:

Some users have opted not to use the Puppet master at all for scaling reasons. Although we feel that we have addressed most of these scaling issues with performance improvements in .25.x, the PuppetMaster will always be the bottleneck in client/server mode.

For this deployment practice, users compile catalogs and apply configuration changes locally with the puppet executable. Code on all of the hosts is then kept in sync with a central repository using something like rsync.

This will always be the best way to scale Puppet deployments, but it suffers from a loss in security as well as ease of management.

As a follow up, I will give some examples of running puppet in standalone mode.