Puppet with Foreman - Pilot

Source: Dev.to

Introduction to Puppet DSL

Puppet DSL (Domain‑Specific Language) is a declarative language used to define the desired state of systems within an infrastructure. It enables automation and ensures consistent configuration management across varied environments.

Puppet boasts a vibrant community and offers flexibility similar to Linux: it can be tailored to meet the specific needs of any infrastructure. While many environments share common configuration practices, each one inevitably includes unique elements. This diversity often prompts a key decision—whether to rely on community modules or develop custom ones.

This series explores building a custom infrastructure using proprietary modules, with Foreman employed as the External Node Classifier (ENC).

With over a decade of evolution in Puppet (from its open‑source roots to what is now known as Puppet Core), the author has developed approximately 75 modules. This expertise forms the foundation for the insights and best practices shared in this series.

Configuration Management vs. Infrastructure as Code

Configuration Management (CM) and Infrastructure as Code (IaC) are foundational concepts in modern IT operations. Both aim to automate and standardize deployment and maintenance, but they differ in scope, focus, and application.

Basics and Principles

• Configuration Management

  • Systematic handling of changes to keep systems in a desired, consistent state over time.
  • Emphasizes repeatability, auditability, and control.
  • Core principle: idempotency—operations can be applied repeatedly without altering the result after the first application.
  • Typically coupled with version control for configuration files.

• Infrastructure as Code

  • Treats infrastructure elements (servers, networks, databases, etc.) as software code.
  • Enables provisioning, configuration, and management of entire environments through code repositories.
  • Supports versioning, collaboration, and automated testing similar to software development.
  • Uses declarative definitions (“what” the infrastructure should look like) or imperative scripts (“how” to achieve it).
  • Strong emphasis on scalability and integration with CI/CD pipelines.

In essence: CM focuses on ongoing maintenance and compliance of existing systems, while IaC covers the full lifecycle—from creation to decommissioning—treating infrastructure as a programmable entity.

Common Tools

Where and When to Use Which

• Chef or Puppet – Traditional CM scenarios where long‑term drift prevention, detailed auditing, and enterprise‑grade stability are critical (e.g., legacy servers, regulated environments).
• Ansible – Simpler, agentless deployments; when speed and ease of learning are priorities; ideal for DevOps teams handling diverse tasks from configuration to orchestration.
• SaltStack – High‑performance needs in large, dynamic environments; cloud‑native setups demanding real‑time responses.
• Terraform – Pure IaC focus, especially for provisioning infrastructure from scratch in cloud‑heavy workflows; ensures reproducibility across dev, staging, and prod.

Hybrid approaches are common: e.g., use Terraform for initial provisioning, then Puppet for ongoing CM. The best tool aligns with the infrastructure’s scale, the team’s workflow, and integration requirements.

Deep Dive into Puppet

Puppet Hiera vs. ENC

In Puppet, data management and node classification are handled through mechanisms like Hiera and External Node Classifiers (ENC), each serving distinct yet complementary roles.

• Hiera – Built‑in hierarchical key‑value lookup system integrated directly into Puppet.

  • Separates data (configuration parameters, secrets, environment‑specific values) from code, promoting reusability and modularity.
  • Organizes data in a hierarchy—often based on facts such as operating system, environment, or hostname.
  • During catalog compilation, Puppet queries Hiera for the appropriate values. For example, a default value can be overridden by a more specific one for a particular node.

• ENC – External service (or script) that provides node classification information to the Puppet master.

  • Determines which classes, parameters, and environment a node should receive.
  • Allows integration with external systems (e.g., Foreman, custom databases, CMDBs).
  • Enables dynamic classification based on inventory, policies, or other business logic.

Both mechanisms can be used together: Hiera supplies data inside the catalog, while the ENC decides what catalog to compile for each node. This separation of concerns leads to a clean, maintainable Puppet architecture.

## Hiera vs. ENC

**Hiera** is Puppet’s built‑in key/value lookup tool. It stores data in a hierarchical structure, allowing you to retrieve values based on node facts, environment, or any other criteria. Hiera supports backends like YAML, JSON, or even custom databases, making it efficient for static data retrieval without external dependencies.

An **ENC** (External Node Classifier), conversely, is an external system that classifies nodes and provides class inclusions and parameters to Puppet. Rather than being embedded in Puppet’s codebase, an ENC operates as a separate service or script that Puppet queries via an API during the node request process. This external approach enables dynamic classification based on external data sources, such as databases or inventory systems. ENCs return YAML‑formatted responses specifying which classes to apply to a node and any associated parameters, offering greater flexibility for complex, enterprise‑level setups.

### Key Differences

- **Scope & Integration**  
  - *Hiera*: Primarily for data lookup within Puppet’s internal workflow, focusing on parameterising manifests without altering class assignments.  
  - *ENC*: Handles both classification (deciding which modules or classes apply to a node) **and** parameterisation externally, allowing for more programmatic control outside Puppet’s core.

- **Encryption**  
  - Hiera can use **eyaml** to keep lookup files fully encrypted at rest, decrypting them on the compile master during compilation.  
  - ENCs do not provide encryption themselves; they rely on the transport security of the API they expose.

What Makes Foreman Superior as an ENC

Foreman stands out as a superior ENC option compared to relying solely on Hiera, particularly in environments demanding comprehensive management and scalability.

Unlike Hiera’s internal, file‑based hierarchy, Foreman provides a full‑featured web‑based interface for managing nodes, hosts, and configurations. As an ENC, it integrates seamlessly with Puppet by classifying nodes based on rich metadata, including host groups, smart classes, and facts. This enables automated, rule‑based assignments—such as applying specific classes to nodes matching certain criteria (e.g., all web servers in a production environment)—without manual manifest edits.

Highlights

In summary, while Hiera excels at simple data separation, Foreman as an ENC elevates Puppet deployments by offering an all‑in‑one platform for classification, provisioning, and oversight—making it the preferred choice for robust, enterprise‑grade automation.

What’s Next

• Planning your Puppet infrastructure
• Setting up your first Puppet master with Foreman

Did you find this post helpful? You can support me.

Related Posts

• Puppet with Foreman – R10k