Puppet 0.24: declarative Infrastructure as Code before Chef and Ansible

Puppet 0.24.6 (April 2009) by Luke Kanies / Reductive Labs: declarative DSL for configuration management, agent/master model, compiled catalog and versionable manifests. The emergence of Infrastructure as Code before Chef and Ansible.

Open SourceWebR&D PuppetIaCInfrastructure as CodeConfiguration ManagementReductive LabsOpen Source

From shell scripts to declarative configuration

Managing the configuration of dozens or hundreds of Linux servers through shell scripts and manually synchronised template files becomes unsustainable beyond a certain scale. The system administration community has sought answers since the 1990s with tools like CFEngine (Mark Burgess, 1993), later bcfg2, and with the emergence of Infrastructure as Code.

Puppet — developed by Luke Kanies and his company Reductive Labs (renamed Puppet Labs in 2010) — took shape from 2005 as a modern answer. Written in Ruby, Puppet proposes a declarative model: the administrator describes the desired state of the machine, not the steps to get there.

Version 0.24.6, released on 3 April 2009, consolidates a year of improvements stabilising the 0.24 series as the reference maturation release of 2009. The licence is GPLv2 (transitioning to Apache 2.0 in later releases).

The declarative model

Puppet’s DSL describes resources — fundamental configuration units — with an ensure/state model:

package { 'nginx':
    ensure => present,
}

file { '/etc/nginx/nginx.conf':
    ensure  => file,
    owner   => 'root',
    group   => 'root',
    mode    => '0644',
    content => template('nginx/nginx.conf.erb'),
    require => Package['nginx'],
    notify  => Service['nginx'],
}

service { 'nginx':
    ensure  => running,
    enable  => true,
    require => Package['nginx'],
}

Puppet parses the manifest, builds a catalog with resource dependencies, and applies necessary changes. If the system is already in the desired state, Puppet does nothing — native idempotency.

The agent/master architecture

As of 2009 Puppet uses a client/server architecture:

  • Puppet Master — central server compiling manifests into catalogs per node. Typically a WEBrick or Passenger/Apache application
  • Puppet Agent — daemon on each managed node; every 30 minutes (default) contacts the master, downloads the catalog, applies changes, sends a report
  • Facter — introspection tool collecting system facts (OS, kernel, network interfaces, RAM, CPU) made available in manifests
  • Foreman (plugin) — web interface for node management, dashboards, reporting

Manifests are versionable in Git/Subversion, reviewable, testable. The concept of configuration as code starts to solidify.

Modules and ecosystem

0.24 establishes the Puppet modules pattern — reusable packages encapsulating the configuration of a specific component (Apache, MySQL, PostgreSQL, PHP, Postfix, BIND, …). The central Puppet Forge archive will launch in 2010-2011, becoming the official catalogue of community-shared modules.

As of 2009 dozens of community modules already exist, shared via GitHub, blog posts, mailing lists.

Emerging competitors

In 2009 the IaC field is forming:

  • Puppet — dominant at the moment, agent/master model, Ruby declarative DSL
  • CFEngine 3 — released 2008-2009, historical precursor with promise theory philosophy
  • Chef — under preparation by Opscode (founded 2008 by Adam Jacob), first public release January 2009. Slightly more imperative Ruby model than Puppet
  • bcfg2 — Argonne National Laboratory, less widespread
  • Salt — Thomas S. Hatch, first commit 2011 (does not yet exist in 2009)
  • Ansible — Michael DeHaan, first commit February 2012 (does not yet exist)

Puppet has first-mover advantage and a built community; Chef arrives with a slightly different model (Ruby recipes plus DSL) and will rapidly win the emerging DevOps community. Salt and Ansible will later enter with agentless philosophies. The IaC market between 2009 and 2015 will be dominated by Puppet vs. Chef competition.

Institutional adoption

As of 2009 Puppet has significant adopters:

  • Google — internal use for configuring parts of production infrastructure
  • Red Hat — integrates Puppet into Satellite (for RHEL configuration management)
  • Stanford University — campus server management
  • Twitter — early deployments (later growing toward Chef)
  • Wikipedia (WMF) — partial

In the Italian context

As of 2009 Italian Puppet adoption is still very niche:

  • System administrators with large-scale Linux server clusters
  • Hosting providers managing hundreds of VMs
  • Universities and research centres with substantial server parks (INFN, CNR, CNAF)
  • Startups with Amazon EC2 cloud environments — Puppet solves new-instance provisioning

Adoption will grow between 2010 and 2013 with the DevOps model’s diffusion and Chef as competitor, bringing many teams to adopt IaC tools as standard practice.

Puppet’s message

Puppet’s conceptual legacy — declarativity, idempotency, catalog as desired-state representation, Facter as introspection — will remain stable even through the container era (Kubernetes brings the same philosophy to a different domain: desired pods and services instead of packages and files). The idea that configuration is versioned, reviewed code will become universal practice in the next decade.


References: Puppet 0.24.x (2008-2009), Luke Kanies, Reductive Labs / Puppet Labs. GPLv2 licence. Facter for introspection. Apache/Passenger, WEBrick as master. CFEngine as historical precursor. Chef (Opscode, January 2009) as competitor.

Need support? Under attack? Service Status
Need support? Under attack? Service Status