Let’s say you know nothing about Puppet.

Or maybe you already know something and have started to use it, but still don’t have a firm grasp on its components or a clear understanding of the whole picture.

Eventually someone has started to introduce it in your company and you have to deal with it.

Or you are a more or less experienced Puppet practitioner.

You might belong to one or more of these category of Puppet users:

• End user, dealing only with (Hiera) Data based on given internal directives
• Power user comfortable with using public or internal modules and eventually write custom classes (such as profiles)
• Modules developer, writing modules and profiles intended for local or public use
• Admin, who maintains the Puppet server infrastructure
• Architect, who designs the data structure, the code organisation, the classification approach

Bad news is that more you belong to the latter categories, more things you need to know, and their amount is not negligible.

Good news is that you don’t need to know everything, in order to successfully use Puppet.

Here is a list, with useful links, of the things to know, according to who you are and what you want to be, in Puppet terms.

Terms, command and components

Basic knowledge of Puppet ecosystem is essential for architects, admins and developers, and useful, even if not strictly necessary, for end users:

• Puppet terminology
• Components of an infrastructure
  • Server side:
    • Puppet Server
    • Puppet CA (by default on the master)
    • PuppetDB
    • Web Frontends:
      • Puppet Enterprise
      • Foreman
      • Puppetboard
      • Puppet Explorer
    • Hiera
  • Client side:
    • Puppet agent
    • Facter
• The puppet commands
• Help from:
  • Official documentation page
  • The Community
  • Support

Modules

If you are an end user, you might even know nothing about Puppet modules and blindly add the data you are told to manage, still for everybody else using, understanding and integrating modules is part of the job, so these concepts are given for granted:

• Modules structure and conventions
• Public modules on the Forge and GitHub
• stdlib and other common modules
• Conventions for templates and files
• Automatic class parameter lookup on Hiera data
• The puppet module command
• Modules development via PDK

Classification

Classification is how we decide what classes, from any module, to include in our nodes, in order to manage the desired resources.

Basically for each Puppet managed node we have to define a list of classes to use, each class comes from modules, either public (so we don’t have to write it) or written by a developer.

Once included, these classes can be parametrised via Hiera data and hence have different behaviours according to our data.

End users, if allowed to define what applications to install on a node, deal with the classification approach decided by architects.

Classication can be done in different ways using different, not necessarily alternative, tools:

• External Node Classifiers (ENC):
  • Custom ENC script getting data from any source
  • Classification in Puppet Enterprise console
  • Classification in The Foreman
• In the main manifests dir:
  • Node statement
  • Facts driven class inclusion
• In modules:
  • Roles module
  • Other modules or classes which include and group other classes
• On Hiera
  • Looking up a key (like classes or profiles with an array of classes to include
  • Classification via example42’s psick module [Shameless plug]

The Control Repo

A modern Puppet setup is based on a control repository. If you are an architect, you designed it, otherwise you might need to work on it (if hieradata is included in the control-repo) or use it while locallh testing any development.

In any case it’s important to know about it.

• Layout:
  • manifests directory, where Puppet code starts to be evaluated
  • Puppetfile, with list of external modules to use and
  • hiera.yaml with definition of hierarchy levels and backend for data lookup
  • Eventually the hieradata dir if backend is file based (json,yaml…) (Can stay in an external module)
  • site directory with local modules (such as profiles) (Can stay in an external module)
• Change management:
  • development environment (with pdk)
  • testing (syntax, unit, integration tests)
  • deployment (r10k or alike, with control-repo branches matching Puppet environments)
  • application (alternative ways to trigger Puppet runs)

Puppet DSL

Strictly speaking knowledge of Puppet language is not necessary for Puppet end users which may configure their data via Hiera.

Still a basic understanding of Puppet abstraction and idempotency principles and the basics of the language is enough to understand better the used modules and eventually write custom ones.

• The Resource Abstraction Layer:
  • Types and providers
  • Everything can be a Puppet resource (via the relevant module)
  • the command puppet resource
• Resources, classes, defined types and modules
• Ruby and Puppet DSL functions
• Data Types
• Facts
  • Native
  • Custom facts in ruby
  • External facts (in any language)
  • Trusted facts via csr_attributes.yaml file
• Builtin variables
• Language operators, expressions, conditionals, iterators…
• Resources ordering

…

Enough?

Enough for now :-)

Alessandro Franceschi