Manifests, Resources & Classes

A Basic Manifest

# nginx.pp
class nginx {
  package { 'nginx':
    ensure => installed,
  }

  file { '/etc/nginx/nginx.conf':
    ensure  => file,
    source  => 'puppet:///modules/nginx/nginx.conf',
    require => Package['nginx'],
    notify  => Service['nginx'],
  }

  service { 'nginx':
    ensure => running,
    enable => true,
  }
}

Puppet's own custom declarative DSL (not a general-purpose language like Chef's Ruby) — more restrictive, but more purely declarative. ensure states desired state (installed/running/present); Puppet's providers figure out the actual OS-specific commands.

Idempotency & Providers

Running the same manifest repeatedly does nothing once the system already matches — package { 'nginx': ensure => installed } is a no-op if nginx is already there. A resource TYPE (package) is platform-agnostic; a PROVIDER (apt, yum) is the platform-specific implementation Puppet selects automatically.

Modules & Puppet Forge

nginx/
  manifests/init.pp
  files/nginx.conf
  templates/
  metadata.json

# Puppet Forge — public repo of shareable community modules,
# often preferred over writing common software configs from scratch

Facts (Facter)

System info (OS, hostname, IP, memory) auto-collected by Facter and exposed as variables manifests can reference for node-specific decisions — conceptually parallel to Chef's Ohai-gathered automatic attributes.