Puppet Training and Workshops

Training built around the work your team does

Generic courses teach a common syllabus. Smart Puppet Training starts from your objectives: onboarding engineers, repairing inconsistent coding practices, modernizing an older control repository, preparing an upgrade, improving testing, or giving operators the confidence to diagnose failed runs.

Theory and hands-on work are mixed according to the participants’ experience. When appropriate, exercises use your code and development workflow, so the outcome is directly applicable after the workshop.

Possible workshop topics

• Puppet’s resource model, declarative language, catalogs, and dependency graph.
• Classes, defined types, roles and profiles, module design, and public interfaces.
• Hiera 5 hierarchy design, lookup behavior, data ownership, and secrets handling.
• Facts, templates, functions, custom types and providers, and Ruby extension boundaries.
• Control-repository structure, environments, Puppetfile management, and deployment workflows.
• Unit, integration, and acceptance testing; linting; CI; and safe code promotion.
• Puppet Server, PuppetDB, reports, performance signals, and troubleshooting techniques.
• Puppet 8 compatibility, strict mode, structured facts, Ruby 3.2, and upgrade planning.
• Puppet Enterprise, Puppet Core, OpenVox, Bolt, Ansible, and mixed-tool operating models.

The agenda is agreed before delivery. Topics can be combined into a focused workshop or expanded into a progressive course.

Delivery formats

Remote sessions can be split into two-hour blocks, which gives participants time to apply each topic between meetings and return with real questions. Full-day remote or onsite workshops work well for concentrated team training.

There is no artificial participant limit from example42. For practical exercises and discussion, smaller groups naturally provide more interaction; larger sessions can combine shared instruction with breakouts led by your senior engineers.

Learn through your own infrastructure

Working on a representative branch of your control repository exposes the decisions that matter: where data belongs, how profiles should be bounded, which dependencies are accidental, how changes move through CI, and how an operator can prove what a catalog will do.

This approach also leaves useful artifacts behind. A workshop may produce a corrected profile pattern, a test example, a Hiera convention, an upgrade checklist, or a documented debugging workflow that the team can continue using.

Training as part of delivery

Knowledge transfer is already built into every example42 service. Choose a dedicated workshop when capability building is the primary outcome. Choose the Infrastructure Kickstart when training should happen while building a new platform, or Smart Support for ongoing coaching during normal work.