Puppet is a configuration management platform used to define and enforce system state as code. This guide helps DevOps engineers, system administrators, and build/release teams turn a broad course outline into a practical learning path with labs, workflow understanding, and implementation-ready examples.
Originally published on 2015-02-17; fully revised and updated.

Who this training path is for
- SCM engineers and build/release engineers moving into infrastructure automation
- DevOps engineers who need repeatable server configuration
- System administrators standardizing Linux or Windows node management
- Developers and QA engineers who need to understand infrastructure-as-code workflows
Structured Puppet curriculum from the original agenda
Foundation topics
- Configuration management fundamentals
- Why Puppet and where it fits in DevOps delivery
- Accessing and organizing lab working files
Core platform setup
- Installing and configuring Puppet Server (called Puppet Master in older materials)
- Installing and configuring Puppet Agent nodes
- Understanding facts, node matching, and catalog compilation
Puppet language and code organization
- Writing manifests and defining resources
- Using modules and Forge modules
- Package, file, and service patterns
- Templates and conditional logic
- Hiera-driven parameterization
Operations and ecosystem topics from the original post
- Reporting and environment organization
- Version control integration
- Windows configuration management
- MCollective, r10k, Librarian-Puppet, and Puppet Dashboard (as listed in the original syllabus)
Puppet run workflow to teach in labs
For most learners, understanding the run cycle is the turning point. The sequence below gives a simple, teachable model for what happens between node facts and applied configuration.
flowchart TD
A[Write or update manifests and modules] --> B[Store code in version control]
B --> C[Agent requests catalog]
C --> D[Agent sends system facts]
D --> E[Puppet Server compiles catalog]
E --> F[Agent applies resources]
F --> G[Agent sends run report]
G --> H{State matches desired config}
H -- no --> A
H -- yes --> I[System remains compliant]
Hands-on commands and manifest examples
These commands and snippets are suitable for classroom labs and self-practice. They focus on discovery, dry-runs, module usage, and baseline resource enforcement.
puppet --version
puppet config print server certname environment
puppet agent -t --noop
puppet apply site.pp --noop
puppet module install puppetlabs-stdlib
puppet resource service cronCode language: JavaScript (javascript)
class profile::baseline {
package { 'vim':
ensure => installed,
}
file { '/etc/motd':
ensure => file,
content => "Managed by Puppet\n",
mode => '0644',
}
service { 'cron':
ensure => running,
enable => true,
}
}
if $facts['os']['family'] == 'Debian' {
package { 'apache2':
ensure => installed,
}
} else {
package { 'httpd':
ensure => installed,
}
}Code language: JavaScript (javascript)
Comparison: execution modes and ecosystem tools
| Mode or command | Best for | Trade-off |
|---|---|---|
puppet apply | Fast local testing of manifests | No central catalog compilation workflow |
puppet agent -t | On-demand agent test run against server | Requires server-side setup and connectivity |
| Scheduled agent runs | Continuous state enforcement at scale | Needs disciplined environment and code promotion practices |
| Tool/topic from original agenda | Primary role | Current course design note |
|---|---|---|
| Hiera | Externalized data and variable lookup | Keep as a core topic for reusable code |
| Puppet Forge | Reusable community modules | Teach module vetting before production use |
| r10k | Environment and module deployment | Useful in Git-based multi-environment workflows |
| Librarian-Puppet | Module dependency management | Include only if it matches your current stack |
| MCollective | Orchestration and remote action patterns | Treat as legacy/compatibility content unless required |
| Puppet Dashboard | Reporting and ENC-related workflows | Validate relevance against your present tooling |
Suggested workshop structure: 1-day vs 2-day
| Format | Focus | Expected outcomes |
|---|---|---|
| 1-day intensive | Core architecture, run cycle, manifests, and agent runs | Participants can read/write basic manifests and execute controlled runs |
| 2-day hands-on | Everything in 1-day plus modules, Hiera, templates, and reporting | Participants can organize reusable code and operate team-ready Puppet workflows |
Original training links and contact details
The following details are retained from the original post for reference.
- Email: info@scmGalaxy.com
- Phone: +91 700 483 5930
- Skype: scmGalaxy
- Training: http://bit.ly/scmgalaxy-training
- Calendar: http://bit.ly/scmgalaxy-calender
- Original article: https://www.devopsschool.com/blog/puppet-training-for-devops-and-system-administrators-2/
Locations listed in the original content: Bangalore, Hyderabad, Pune, Mumbai, Delhi, USA, Australia, and Canada.
Common pitfalls
- Jumping into module downloads before understanding facts, resources, and idempotency
- Testing only with direct apply runs and skipping server-agent validation
- Hardcoding values in manifests instead of using Hiera
- Ignoring environment strategy (dev/test/prod) during early setup
- Keeping legacy tooling in the curriculum without checking current operational relevance
I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.
I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.
Find Trusted Cardiac Hospitals
Compare heart hospitals by city and services — all in one place.
Explore Hospitals