Puppet (Configuration Management)

Workflow

• Puppet agent running on a host collects information about the host it is running on, and sends it along to the server
• Server uses that system information and Puppet modules on local disk to compile a configuration for that particular host, and returns that configuration to the host.
• The agent applies that configuration locally, thus affecting the local state of the host, and files the resulting report

Data Types

• Facts: System data collected on each machine and used to compile configurations
• Manifest: Files containing Puppet code, generally organized into modules
• Catalog: A graph of a given host’s resources to be managed and the dependencies between them.
• Report: The collection of all events generated during application of a given Catalog.

Components

• Agent

• Facter

  • tool gathers data about the host on which it runs.
  • Is extensible with plugins

• External Node Classifier / ENC

  • Usuallly a separate service or application, needs only to indicate which classes a given host belongs to and what parameters should be used to configure those classes.

• Compiler

  • Most Puppet configuration code is lazily loaded on first reference, so there don’t need to be explicit calls to load and parse code.
  • Every statement in grammar that is parsed ends up in an AST, meaning for the lifetime of the server process won’t need to be parsed again
  • Given the AST and a Node object from the ENC, the compiler looks up the classes of the Node object and evaluates them
    • During this, the compiler builds up a tree of variable scopes, meaning that if class X includes class Y, class Y can look up variables from class X.
  • During compilation two types of relationships are created
    • classes containing a definition (each of which may contain 0 or more other definitions; and 0 or more resources)
    • services depending on a package

• Transaction

  • Puppet agent polls the server for the Catalog, which declares containment and dependency relationships
  • The Transaction converts the containment graph into dependency relationships, and selects each resource needed in topological order.
  • For each resource
    • retrieve the current state of the resource
    • compare it to the desired state
    • make any changes necessary to fix discrepancies
    • fixing of discrepancies is handled by a ResourceHarness, which defines the entire interface between Transaction and Resource

• Resource Abstraction Layer

  • Defines what it means to be a resource and how resources can get work one on the system
  • Providers
    • This abstraction lets you specify multiple ways of managing different types of resources, with ways of getting and setting values
  • Another major class type is responsible for parameters, of which Puppet has 3 types
    • metaparameters, which affect all resource types (e.g., are we running in simulation mode)
    • parameters, which are value sthat aren’t reflected on disk (e.g., whether you should follow links in files)
    • properties, which model aspects of the resource that you change on disk (e.g., a file’s content, or whether a service is running)
    • The difference between properties and parameters can be summed up as: properties have getters and setters in the Providers, parameters do not.

• Reporting

  • As the transaction walks the graph and uses the RAL to change the system, it progressively logs its progress.

Infrastructure

• Plugins
  • At the start of every puppet run, the agent downloads all plugins the server has available.