Puppet with Foreman - Infrastructure
Source: Dev.to
Minimum Requirements
Puppet requires only a single primary server to function. This server acts as the central authority, compiling catalogs—detailed instructions for node configurations—and distributing them to agents. For open‑source Puppet, system requirements are straightforward, though scaling considerations apply based on the number of managed nodes.
Trial use:
- 2 CPU cores
- 8 GB RAM
- 20 GB for
/opt/ - 24 GB for
/var/
Small open‑source setups: a dual‑core processor with at least 4 GB RAM suffices for basic operations. Production environments benefit from quad‑core processors and 8 GB or more RAM.
Supported Operating Systems
The primary server can run on:
- Red Hat Enterprise Linux (RHEL) 7–10 – x86_64, ARM64, ppc64le (RHEL 9)
- Ubuntu 18.04–24.04 – amd64, aarch64
- Microsoft Windows Server 2012 R2 – for FIPS‑compliant setups
Architectures typically require x86_64 (or amd64 for Ubuntu).
Supported OS for agents mirrors the server list and includes various Linux distributions, Windows, macOS, and more.
High Availability (HA)
For enhanced reliability and scalability, additional compile masters can be added. These secondary servers offload catalog compilation from the primary server, distributing the workload in larger environments. The primary server remains the Certificate Authority (CA) and central point for data, while compile masters handle requests from agents.
Operational Modes
Puppet offers several modes, each suited to specific use cases:
| Mode | Description |
|---|---|
| Puppet server with Puppet agents | Traditional pull‑based model: agents periodically check in with a Puppet server to retrieve their catalog, which is then enforced locally. |
| Serverless Puppet | Catalog is compiled directly on the node, often combined with a remote version‑control repository for masterless, pull‑based deployments. |
| Puppet Bolt | Orchestration tool using a push model: the catalog is compiled on a controller and deployed to managed nodes. |
Local puppet apply | Simplest mode: catalog is compiled and applied locally without a server, commonly used for provisioning virtual machines or images. |
Selecting a mode depends on infrastructure size, security needs, and administrative preferences. The server‑agent model prevails in enterprise settings for centralized control.
PuppetDB
PuppetDB serves as a storage backend for Puppet data, enhancing query capabilities and enabling advanced features. It collects and stores:
- Facts (system details from agents)
- Catalogs
- Reports
This information becomes accessible for querying and analysis.
Puppet Agents
Puppet agents run on managed nodes, enforcing configurations by applying catalogs received from the server. They operate in the background, typically checking in every 30 minutes to ensure compliance.
- Hardware: Low overhead; at least 512 MB RAM and modest CPU for occasional runs. No dedicated resources beyond the node’s baseline are needed.
- Software: Ruby (version depends on Puppet release); the agent package handles dependencies.
- Communication: Agents communicate via HTTPS, requiring certificates signed by the primary server’s CA, ensuring secure, authenticated interactions.
Environments
Environments provide isolation for code and configurations, allowing different versions of modules or manifests to coexist. By default, Puppet includes a production environment, but custom ones such as development or staging can be created for testing changes without affecting live systems.