Kahibaro
Discord Login Register

6.3.3 Puppet overview

Where Puppet Fits in Configuration Management

Puppet is one of the oldest and most widely used configuration‑management tools. In the broader configuration‑management ecosystem (Ansible, Chef, Salt, etc.), Puppet is:

For DevOps work, Puppet is commonly used to:

This chapter focuses on Puppet’s concepts, workflow, and how it differs from other tools, not on step‑by‑step installation.

Puppet Architecture in a Nutshell

Puppet’s “classic” architecture (Puppet Enterprise and open‑source Puppet) is built around a client‑server model:

You can also use Puppet apply in a masterless setup:

Declarative Model and Resources

Puppet is declarative. Instead of writing step‑by‑step commands, you define desired state using resources.

A resource describes one component on a system:

Example resource declarations:

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

Key points:

The Puppet Language (Puppet DSL)

Puppet has its own domain‑specific language (DSL). For beginners, you mainly deal with:

Example of a simple class:

class webserver (
  String $docroot = '/var/www/html',
) {
  package { 'nginx':
    ensure => installed,
  }
  file { $docroot:
    ensure  => directory,
    owner   => 'www-data',
    group   => 'www-data',
    mode    => '0755',
    require => Package['nginx'],
  }
  service { 'nginx':
    ensure     => running,
    enable     => true,
    subscribe  => File[$docroot],
  }
}

Concepts visible here:

You include or assign classes to nodes (more on that in classification).

Catalogs: From Code to Actions

Understanding catalogs is key to Puppet:

  1. Agent gathers facts (system information like OS, IPs, CPU, memory) using Facter.
  2. Agent sends facts to the Puppet server.
  3. Puppet server compiles a catalog for that specific node:
    • Applies your manifests, modules, and Hiera data.
    • Resolves variables and templates.
    • Orders all resources and their relationships.
  4. Agent applies the catalog:
    • Checks each resource’s current state.
    • Changes only what’s necessary to match the catalog.
  5. Agent sends reports back to the server/PuppetDB.

A catalog is:

Idempotence and Convergence

Puppet aims for idempotent behavior:

Examples:

Puppet converges systems toward the defined state at each agent run, useful for:

Node Classification

Node classification is how you decide which classes apply to which machines.

Common methods:

  1. Site manifest (site.pp)
    • Central place in an environment for node definitions.
    • Example:
   node 'web01.example.com' {
     include webserver
   }
   node /^db\d+\.example\.com$/ {
     include database_server
   }
  1. External Node Classifier (ENC)
    • External script/API that tells Puppet which classes and parameters to assign.
    • Often integrated with CMDBs, ticket systems, or Puppet Enterprise’s console.
  2. Role and Profile pattern (very common modern pattern):
    • Profiles: implement specific technology stacks (profile::nginx, profile::postgresql).
    • Roles: business roles that group profiles (role::web, role::db).
    • Nodes are assigned only one role class, and that role pulls in profiles internally.

Example:

   class role::web {
     include profile::base
     include profile::nginx
     include profile::app
   }
   node 'web01.example.com' {
     include role::web
   }

Puppet Modules

A module is Puppet’s unit of organization and reuse. A module typically includes:

Example simple module layout:

nginx/
  manifests/
    init.pp       # class nginx
    config.pp     # class nginx::config
  templates/
    nginx.conf.epp
  files/
    default_site.html

You usually place modules in:

You can download community modules from:

For example, instead of writing your own Nginx logic, you might install puppet/nginx and use its classes.

Data Separation with Hiera

Puppet’s design encourages separating code from data:

Hiera is Puppet’s hierarchical data lookup system:

Puppet code then uses functions like lookup() to retrieve values:

class webserver (
  String $docroot = lookup('webserver::docroot'),
) {
  # ...
}

Benefits:

Facter and Facts

Facter is a tool that gathers facts about the system:

Within Puppet manifests you can use facts directly, like:

Facts influence:

This enables writing cross‑platform modules that adapt to the underlying system.

Typical Puppet Workflow

A common beginner‑level lifecycle with Puppet in a team looks like:

  1. Design
    • Decide what you want to manage: services, users, configs, etc.
    • Plan your modules, profiles, and roles.
  2. Develop
    • Write or modify Puppet code in a Git repository.
    • Use modules and Hiera for reuse and data separation.
  3. Test
    • Use puppet apply locally or in a test environment.
    • Optionally use unit tests (e.g., rspec-puppet) and linters.
  4. Deploy
    • Push code to a Puppet server environment (production, staging, etc.).
    • Agents pull catalogs and apply them on their next run or via a triggered run.
  5. Monitor
    • Check Puppet reports, logs, and dashboards.
    • Ensure runs are successful and changes behave as expected.

Comparison to Other Configuration Management Tools

From a beginner’s perspective, Puppet differs from some other tools you may encounter:

Understanding these differences helps you decide when Puppet is a good fit:

Getting Hands‑On (Conceptual Overview)

Without going into full installation details, the basic commands and artifacts you’ll see in Puppet usage are:

For a beginner, the first steps usually are:

  1. Learn to read and write basic resources and classes.
  2. Use puppet apply to test manifests on a single VM.
  3. Explore a simple module from Puppet Forge to see structure and style.

When to Consider Puppet in Your Toolset

Puppet is particularly appealing when you:

Even if you ultimately use a different tool in production, understanding Puppet gives you:

Views: 79

Comments

Please login to add a comment.

Don't have an account? Register now!