Puppet Glossary

Introduction

Navigating the landscape of IT infrastructure management can be complex and challenging without a solid grasp of essential terms and concepts.

Delve into the world of Puppet, where we've detailed all the essential terminology associated with configuration management, automation, and infrastructure orchestration. Elevate your understanding of Puppet and enrich your knowledge of IT infrastructure management seamlessly.

Puppet Terms

A

Abstract Data Type: A categorization of a specific data type. Abstract data types allow for more sophisticated type validation, such as optional or variant.

Agent: The software agent package, Puppet, is commonly implemented in a client-server setup. Installing Puppet on a device involves installing the agent software along with its related tools and dependencies. In Unix systems, this package is referred to as puppet-agent. The Puppet agent service. You can activate the agent software by executing the puppet agent command, or you can have it operate in the background as a daemon. In a Puppet infrastructure, an agent node, running the agent software, regularly performs Puppet runs by sending node information to a primary server, receiving a configuration catalog, and applying it using providers to manage configuration. This process ensures that all nodes, including server nodes, maintain their configurations in alignment with the desired state defined in the catalog, making the agent node a crucial component in managing and maintaining the infrastructure's configuration consistency.

Agentless: In the Puppet infrastructure, the term "agentless" describes a node or device that functions independently without needing a Puppet agent installed. For instance, agentless nodes lack an active agent service but can be integrated into the Puppet Enterprise inventory using protocols like Secure Socket Shell (SSH) or Windows Remote Management (WinRM). Devices such as network switches or firewalls, which cannot support a Puppet agent, fall under the category of agentless devices. Despite the absence of a Puppet agent, these devices can still be connected to the Puppet infrastructure for management purposes and task execution.

Attribute: Attributes define the desired state of a specific configuration resource. Each resource type has its own unique set of attributes, and each attribute has a defined set of allowed values that can be assigned to it. These attributes serve as the building blocks for specifying the desired configuration for a node or system managed by Puppet.

C

Catalog: In the Puppet infrastructure, a catalog is a consolidated file outlining the desired state of each managed resource on a node, encompassing all resources and their interrelations applied by the Puppet agent. Compiled by the primary server from manifests, agent-provided data (such as facts, certificates, and environment), and optional external data (like from an external node classifier or functions), catalogs are then delivered to the agent upon request. Unlike the source manifests, catalogs lack conditional logic or functions, ensuring they are node-specific, unambiguous documents that guide the agent in accurately implementing the desired configuration for the designated node.

Class: In Puppet, a class is a grouping of interconnected resources that, once defined, can be declared as a cohesive unit. For instance, a class could encompass all necessary resources (like files, configurations, modules, and scripts) for setting up the Apache web server on a host. Classes may also include other classes, offering modularity and organization. While classes are unique and can be applied just once within a configuration, the include function permits multiple declarations, with Puppet evaluating it only once. Additionally, relationships between classes can be established using the require and contain functions, providing further insights into containment within the Puppet language reference.

Classify: Node classification is the process of assigning classes to a node and providing any necessary data required by those classes. By defining a class, you establish a set of configurations that can then be applied to a node through the classification process. This allows you to describe the desired configuration for a particular node. There are several ways to classify nodes in Puppet: Through node definitions in the main manifest, Using the Puppet Enterprise node manager, and Leveraging an external node classifier. Regardless of the method, the classification process associates the relevant classes and their associated data with the target node, ensuring the desired configuration is implemented.

Compile: The primary server creates a catalog by compiling manifests, agent-provided data, and any external data that may be available. During a Puppet run, the agent requests the compiled catalog for its specific node and then applies the catalog to configure the node according to the desired state.

Compiler: A tool that transforms Puppet code into a Puppet catalog file, which outlines the desired state of each managed resource on a node. During a Puppet run, the agent utilizes this catalog to configure individual nodes. Another Puppet Server instance specialized in catalog compilation can be incorporated to alleviate the primary server's workload. By adding additional Puppet Server instances for catalog compilation, you can distribute tasks, expedite catalog compilation, and enhance the capacity to manage a larger number of agents effectively.

Console: Puppet Enterprise incorporates a web-based user interface known as the console, offering a range of tools for overseeing your Puppet infrastructure. This interface enables tasks such as node classification, Puppet service management, report and metric viewing for Puppet runs and activities, as well as inspection of inventory data and resources.

Core data type: Concrete data type. A categorization of a specific data type. The core data types are the most commonly used types of data, such as string or integer.

Corrective change: A corrective change refers to a remedial measure implemented by a Puppet agent to rectify unauthorized or unintended alterations on a node, ensuring alignment with the node catalog. Following an unauthorized or unintended modification, the subsequent Puppet run conducts a comparison between the node catalog and the current state of each property across managed resources on the node. Any disparities identified are then rectified by Puppet to restore consistency.

D

Data Type: A classification for data.

Declare: Instructing Puppet to incorporate a specific class or resource within a designated configuration involves declaring the class or resource using the Puppet language. For class declarations, utilize functions like include or the syntax class {'my_class':}. When declaring resources, employ the lowercase file {'/tmp/my_file':} syntax. Furthermore, customization of a resource or class upon declaration can be achieved by incorporating attribute-value pairs.

Define: Verb- In Puppet, defining the contents and functionality of a class or a defined type involves utilizing the Puppet language to establish the class or type. Defining a class or type does not inherently integrate it into a configuration; rather, it renders it accessible for declaration. Noun- An antiquated term denoting a defined type, where a module may make reference to its existing defines. Keyword- The define keyword in the Puppet language is employed to generate a defined type.

Defined Type: Defined resource type.

Design Pattern: A design pattern is an informal term that characterizes a set of interconnected manifests crafted to address a specific problem or oversee a particular configuration element. For instance, the term "Apache pattern" denotes the manifests tailored for configuring Apache.

E

Environment: An environment represents a segregated cluster of agent nodes that a primary server can cater to with its distinct main manifest and module collection. Environments can be utilized, for instance, to establish test nodes for preliminary testing prior to implementing alterations in production, or to segment a site based on hardware categories.

Exported Resource: An exported resource is a resource that has been specified to be accessible to other nodes, enabling them to retrieve and control their own versions of the exported resource. This functionality allows for the dissemination of a resource's desired state among nodes, facilitating scenarios where one node relies on data from another node for its configuration, or when monitoring the state of a resource is necessary.

Expression: An expression in the Puppet language is a statement that evaluates to a value. Various types of expressions, such as Boolean expressions, comparison expressions, and arithmetic expressions, are supported for comparison and evaluation within the language.

External Node Classifier: An external node classifier (ENC) is an executable script that, when invoked by a primary server, returns information about the classes to be applied to a node. For instance, Puppet Enterprise functions as an ENC.ENCs offer an alternative to using a site's main manifest for node classification. An ENC can be written in any programming language and leverage data from various sources (such as a Lightweight Directory Access Protocol database) when classifying nodes. The ENC is called with the node's name as an argument and responds by returning a YAML document detailing the node's classification.

F

Fact: A fact is a data point concerning a node, encompassing details like its hostname, IP address, or operating system. Facter retrieves facts from a node and presents them to Puppet. By incorporating custom facts, Facter can be expanded to reveal site-specific information about your systems to your Puppet manifests.

Facter: Facter serves as Puppet's system inventory tool, gathering information about a node like its hostname, IP address, and operating system, and then providing this data to Puppet. It comes equipped with numerous pre-defined facts, which can be accessed by executing the facter command on the node's command line to view their names and corresponding values. In Puppet setups involving agents and servers, agents transmit their nodes' facts to the primary server.

Filebucket: The storage location where Puppet retains file backups for replaced files is known as a filebucket. Filebuckets can either be local, belonging to the managed node, or site-global, under the ownership of the primary server. Generally, a network will define a single filebucket as the default backup destination.

Function: A function in the Puppet language is a statement that either yields a value or alters a catalog. Puppet encompasses numerous pre-existing functions, with modules having the ability to introduce their own. Additionally, custom functions can be authored.Typically, functions require at least one argument, execute Puppet code, and produce a result. As Puppet evaluates functions during compilation, they are executed by the primary server in an agent-server setup. It's important to note that Puppet functions can solely access the facts provided by an agent. This differs from a lambda.

H

Hiera: The Hiera tool, included with the agent, offers a hierarchical key-value search for site-specific information. Utilizing Hiera allows you to extract site-specific data from your manifests and relocate it to a centralized repository. This approach enables the establishment of default data and the ability to override specific values as required.

Host: In Puppet documentation, a host is any physical or virtual device connected to a network. Specifically, a host can denote a device running the agent daemon. Regarding resource types, a host can also represent an entry within a system's hosts file, utilized for name resolution. Puppet incorporates a module type to oversee hosts management.

I

Idempotent: Idempotence pertains to the idea of achieving the same result even when an action is repeated multiple times. Puppet resources exhibit idempotent behavior by defining a desired end state rather than a sequence of actions to execute. An exception within Puppet resources is the exec resource type, which, while idempotent, requires users to structure the resource appropriately to maintain idempotent behavior.

Inheritance: In Puppet, inheritance involves a Puppet class deriving from another class through the use of the inherits keyword. The derived class encompasses all the resources of the parent class but has the ability to modify certain attributes and introduce new resources. It is advisable to exercise caution and limit the use of inheritance in your Puppet code.

Intentional change: When the Puppet code is updated, the Puppet agent deliberately modifies the node to ensure its properties align with the latest changes in the node catalog. After a node catalog is updated, the subsequent Puppet run compares the catalog with the current state of each managed resource property on the node, and then rectifies any discrepancies.An intentional change can also be applied to a newly provisioned node, transitioning it from an unconfigured state to the expected desired state.This differs from a corrective change, which addresses unauthorized or unintentional modifications on a node.

J

JRuby: JRuby is a version of the Ruby programming language that operates within the Java Virtual Machine (JVM). Puppet Server functions within the JVM as JRuby processes, receiving and handling requests from Puppet agents. The JVM enables Puppet Server to operate multiple compilers simultaneously, catering to catalog requests concurrently as required.

L

Lambda: Also known as code block. A lambda in Puppet is a parameterized block of Puppet language code that can be passed to specific functions.

Local scope: An area of Puppet code.

M

Main manifest: Also known as site manifest. A manifest is a file that holds Puppet code. In Puppet, the main manifest serves as the entry point for a primary server when compiling a catalog.
The primary, or site, manifest file is commonly named site.pp. Its location is determined by the manifest setting in the environment.conf file, with the default location specified by the default_manifest setting in the puppet.conf file.

Manifest: A manifest is a file that holds Puppet code written in the Puppet language, typically identified by a .pp file extension. Within a manifest, you can: Declare resources and classes, Define variables, Execute functions, Establish classes, defined types, functions, and nodes. Manifests are commonly found within modules, with each manifest in a module defining a single class, defined type, or function. The primary server service reads the main manifest of an environment, which typically defines nodes to ensure each managed agent receives a distinct catalog.

Manifest Ordering: Manifest ordering involves executing unrelated resources in the sequence they are declared within their manifests. These ordering relationships are considered "soft," indicating that they can be superseded by any explicit ordering relationships defined in the code.

Metaparameter: A metaparameter is a resource attribute that can be applied to any resource type. These metaparameters are integral to the Puppet framework rather than being tied to a particular resource type, and typically influence the interactions and relationships between resources.

Module: A module is a compilation of classes, resource types, files, functions, and templates structured to serve a specific objective. For instance, a module might be designed to set up an Apache web server or manage a Rails application. Modules are accessible for download from the Puppet Forge.

N

Namevar: aka name. The namevar attribute signifies the distinct identity of a resource on a specific system. For instance, it ensures that two distinct files cannot share the same path, and two separate services cannot have identical names. Each resource type includes a specified namevar, typically denoted as name. However, certain resource types like file or exec utilize a namevar other than name (such as path and command, respectively). If a type's namevar differs from name, this variation is detailed in the type reference documentation.

Node: A node within Puppet is a device under Puppet's management. Nodes can function as primary servers responsible for compiling manifests into catalogs, or as agents that receive and implement these catalogs during a Puppet run. While the majority of nodes are typically computers like workstations and servers, some may include supported network switches and storage appliances.Furthermore, a node serves as a fundamental component within a puppetized infrastructure.

Node Definition: aka node statement. A node definition is a set of classes, resources, and variables within a manifest that are exclusively applied to a specific agent node. Node definitions commence with the node keyword and can include the node's full name or a regular expression.When a node retrieves or compiles its catalog, it receives the contents of a single matching node statement, as well as any classes or resources declared outside any node statement. However, the classes defined in all other node statements are hidden from that node.

Node Management: Puppet Enterprise offers node management workflows and tools that assist in categorizing nodes through fact-based rules within the console.

Node Run Status: During a Puppet run, Puppet endeavors to align the node with its catalog to ensure compliance. The state of the node post-run, monitored by Puppet Enterprise, is referred to as the node run status. Various node run statuses can occur, including: With failures, With corrective changes, With intentional changes, and Unchanged. In cases where a no-op Puppet run identifies that modifications would have occurred during a standard Puppet run, the node run status signifies that the change would have been implemented but was not. Additionally, there are run statuses for nodes that are unresponsive or incompletely configured.

Node Scope: An area of Puppet code.

no-op: aka noop. Executing Puppet in no-op mode (referred to as noop in code, derived from "no operations" mode) enables you to simulate Puppet's actions without making actual changes. This mode facilitates a dry run that logs intended activities without impacting nodes. To activate no-op mode, run puppet agent or puppet apply with the --noop flag.

Notification: A notification is a relationship type that establishes resource order and triggers refresh events. This relationship is established using the notify metaparameter or the wavy chaining arrow ~> symbol.

O

Ordering: Resource ordering allows you to control the sequence in which resources are managed. By default, Puppet utilizes manifest ordering, which processes resources in the order they are declared within their manifests. Additionally, Puppet respects any relationships you specify that establish resource dependencies.

P

Parameter: A parameter is a piece of data that can be received by a class or resource. In custom type and provider development: A parameter defines characteristics of a specified resource. When this resource is applied on a node, Puppet leverages the logic contained within the resource type and provider to align the node's state with the desired state indicated by the resource parameters. In defined types and parameterized classes: A parameter serves as a variable within the definition of a class or defined type, with its value determined by a resource attribute when an instance of that type or class is declared. The parameters defined when creating a type or class outline the attributes accessible when the type or class is instantiated. In the context of external nodes: A parameter represents a top-level variable established by an external node classifier. While termed parameters, they function as variables and are typically employed to configure class behavior.

Plug-in: A plugin is an extension to Puppet's functionality, typically in the form of a custom type, function, or fact, and is distributed within a module.

Plusignment Operator: The plusignment operator +> allows you to add values to resource attributes using the plusignment syntax. This operator is beneficial when you need to override resource attributes without having to respecify previously declared values. For more details, refer to the section on appending to resource attributes in Classes.

PostgreSQL: PostgreSQL serves as the backend data storage layer for PuppetDB. When installing PuppetDB using the Puppet module, the PostgreSQL server is automatically configured, requiring no additional steps. However, if PuppetDB is not installed using the Puppet module, you will need to set up a PostgreSQL server, including creating a user and an empty database for PuppetDB.

Primary Server: aka primary Puppet server. In a typical Puppet client-server deployment, the server is referred to as the primary server. The primary server is responsible for compiling and serving configuration catalogs on-demand to agent nodes.The primary server provides catalogs to agents through an HTTP server. This primary server can run as a standalone daemon with an integrated web server, or, particularly when managing more than 10 nodes, as part of Puppet Server.

Profile: Within the Puppet code development roles and profiles pattern, a profile embodies the setup of a technology stack for a site, often comprising multiple classes. Roles can encompass numerous profiles to establish their identity, with profiles being integrated into both role and profile modules.

Property: In the development of custom types and providers, a property represents a value linked to a visible aspect of the target node's state. When fetching a resource's state, a property invokes the designated method on the provider, extracting the state from the system. If the existing state differs from the specified state, the provider modifies it accordingly. These properties are manifested as attributes when defining instances of this resource type.

Provider: A provider implements a resource type on a specific system by leveraging the system's own tools. This separation of types and providers enables a single resource type (such as package) to manage packages across various systems, utilizing tools like yum on Red Hat systems and dpkg and apt on Debian-based systems. Providers are frequently Ruby wrappers around shell commands.

Puppet: "Puppet" encompasses various meanings within the realm of IT and software development. It can denote the suite of automation products offered by Puppet, the open-source Puppet project, the command utilized to activate the agent daemon on a node, the Puppet language employed for writing manifests, and the Puppet business unit housed within Perforce Software, Inc. Each of these interpretations plays a distinct role in the context of configuration management, automation, and infrastructure as code practices.

Puppet Enterprise: Puppet Enterprise (PE) serves as an automated IT infrastructure management software solution. Positioned as the flagship product within the Puppet suite of IT automation tools, PE is capable of overseeing a multitude of nodes, encompassing computers, workstations, and various devices. To commence operations, users can leverage the console, a web-based interface, to organize and categorize nodes. The primary server maintains the desired state for each node within a catalog. Puppet agents receive this catalog, compare nodes against the desired state, and rectify any non-compliant nodes. Through this process, PE plays a pivotal role in ensuring all nodes adhere to the organization's specified requirements.

Puppet Enterprise deployment: A Puppet Enterprise deployment involves setting up Puppet Enterprise infrastructure components and agents on nodes within your environment. Centralized deployments are employed for managing operations across all regions, while federated deployments entail deploying an autonomous Puppet cluster for each region. Deployments can be structured based on various architectures, such as standard, large, and extra-large installations.

Puppet language: Puppet code is written in the Puppet language, with the files containing this code referred to as manifests and using the .pp file extension. During a Puppet run, the primary server compiles this Puppet code into a catalog.

Puppet run: A Puppet run occurs when an agent sends its facts and identifying certificate to the primary server, requesting a compiled catalog in return. The agent then applies this catalog to the node, utilizing operating system-specific providers to align the node's properties with the catalog's definitions. Finally, the agent transmits a report of logs and metrics to the primary server.By default, a Puppet run is scheduled to take place every 30 minutes, regardless of whether any changes have occurred in the agent's catalog or configuration.

Puppet Server: Puppet Server is a Java Virtual Machine application, available as open source, that delivers scalable primary server functionalities and an administrative API for maintenance purposes.

PuppetDB: PuppetDB, an open-source database, serves as a repository that caches and stores data essential to the Puppet infrastructure. It offers an API for external applications to retrieve Puppet's accumulated data and facilitates the utilization of advanced Puppet functionalities, including exported resources.

Puppetfile: A Puppetfile is a definitive and independent inventory that instructs Puppet Enterprise on which modules to install, the specific versions to install, and the designated source to utilize. Employing a Puppetfile enables efficient management of module installations as sets.

Puppetize: Puppetizing your infrastructure involves automating its management by translating the configuration into Puppet language and leveraging Puppet to achieve and uphold the desired state. This process is iterative, incremental, and continuous, gradually extending Puppet's management to encompass a growing number of services, applications, nodes, and devices within your infrastructure.

R

r10k: The r10k tool within Puppet Enterprise is one of the available options to assist in managing and deploying Puppet code, including environments and modules, through the utilization of Puppetfiles.

Realize: When indicating that a virtual resource should be implemented on the current system, it needs to be realized. Once a virtual resource is declared, there are two approaches to realizing it: employing the spaceship syntax <||> or utilizing the realize function. Although a virtually declared resource is included in the catalog, it remains inactive on a system until it is realized.

Refresh: When a resource undergoes a refresh, it occurs in response to a modification in a resource it subscribes to or one that notifies it. The actions taken during a refresh vary based on the resource type. For example, services may restart, mount points could unmount and remount, and the exec resource type executes if the refreshonly attribute is configured.

Relationship: Establishing a sequence for managing resources forms a connection between them, defining their order of execution.

Report: Agents can be set up to transmit reports comprising logs and metrics after each Puppet run. These reports are then processed by a report processor to convert them into an alternative format before dispatching them to another application, destination, or service.

Report Processor: A report processor receives a Puppet report, converts it into a designated format, and forwards it to another application, destination, or service. Puppet includes pre-installed report processors, and users have the option to develop custom ones as well.

Resource: A resource within Puppet is a configuration unit whose state is controllable. Each resource is characterized by a type (like file, service, or user), a title, and various attributes with defined values. Resources can vary in size and complexity, ranging from straightforward to intricate. They may not always correspond directly to individual client details, potentially encompassing tasks like distributing information across multiple files or adjusting devices. For instance, while a service resource represents a singular service, its implementation could entail tasks such as executing an init script, running external commands to verify its status, and adjusting the system's run level configuration.

Resource Declaration: A resource declaration in Puppet code outlines the intended state of a resource and directs Puppet to oversee it. This term serves to distinguish between the actual resource present on a system and the guidelines for managing it. Despite this distinction, resource declarations are commonly known simply as resources.

Role: Within the roles and profiles pattern of Puppet coding, a role specifies the operational function carried out by a node. Typically, a role comprises a single class capable of fully configuring groups of nodes using profiles. Nodes should be classified with a single role; if a node necessitates multiple roles, a new role should be created to accommodate this requirement.

Role and Profile Module: A role and profile module in Puppet is a module that assigns configuration data to node groups based on roles and profiles. While it doesn't possess any unique features, the role and profile module embodies an abstract, private, and site-specific approach to leveraging modules for configuring technology stacks and node descriptions.

S

Scope: Puppet code has different scopes, including local scope, node scope, and top scope, which determine the variable's reach and resource defaults. Scopes can be named, such as those created by class definitions, or anonymous, like those generated by lambdas and defined resources. In general, Puppet prioritizes the variable from the most local scope when multiple variables with the same name are available. In Puppet, you commonly encounter three scopes: Top scope: Variables are accessible globally by their short name (e.g., $my_variable) but can be overridden locally. Top scope variables are accessed using the double-colon namespace separator with an empty string ($::my_variable). Node scope: A specific scope within a node definition where variables can be referenced by their short name and can override top-scope variables. Local scope: Variables are accessible by their short name within the scope and its children but are usually not accessible from other scopes.

Serverless: Serverless denotes a Puppet node that operates independently without requiring a primary server to provide its catalog.

Singleton: In Puppet, a singleton is an object like a class that can be evaluated just once. This means that within a manifest or catalog, you cannot have multiple unique classes with the same specific name, thus making that class a singleton.

Site: In Puppet, a site encompasses the complete IT environment under management. This includes all primary server servers, agent nodes, serverless Puppet-managed nodes, as well as nodes or devices with agentless connections to Bolt or PE management within your organization.

Site Module: A site module is a module housing classes tailored to a particular Puppet site. These classes outline comprehensive configurations for a specific system or a set of systems. For instance, the site::db_replica class would detail the complete setup of a database server, allowing the configuration of a new database server by applying this class to it.

Subclass: A subclass is a class that derives its properties and behaviors from another class.

Subscribe: A subscription is a notification relationship established using the subscribe metaparameter or the wavy chaining arrow ~>.

T

Template: A template is a template document that is populated with data from variables. Puppet can utilize Embedded Puppet (EPP) templates written in the Puppet language or Embedded Ruby (ERB) templates written in Ruby to produce customized configuration files specific to a particular system.

Title: A title serves as the unique identifier for a resource or class within a Puppet catalog. For a class, the title is the class name. In a resource declaration, the title is the part between the first curly brace and the colon. For example, in the resource declaration file { '/etc/passwd': }, the title is /etc/passwd. In native resource types, the name or namevar uses the title as its default value if you don't explicitly specify a name. Within a defined type or class, the title is available for use throughout the definition as the $title variable. Unlike the name or namevar, a resource title need not map to any attribute of the target system; it is only a referent. You can give a resource a single title even if its name must vary across different kinds of systems.

Type: A type represents a category of resource that Puppet can oversee. For instance, file, cron, and service are examples of resource types. Each type defines the attributes available for resources of that type and mirrors the functionality of that specific resource on the target system. Multiple resources of the same type can be declared. Puppet includes a collection of pre-installed resource types. Puppet allows for the addition of new native types as plugins, and the creation of defined types by combining existing resource types.

Type (data): Every value is associated with a data type, which categorizes the kind of data a variable or parameter can store. This classification includes abstract data types and core data types.

Type (defined): A defined type, also known as a define or definition, is a resource type composed of multiple other resources, written in the Puppet language, and stored in a manifest. For instance, a defined type might utilize a mix of file and exec resources to set up and populate a Git repository. Once a type is defined, new resources of that type can be declared similar to any native or custom resource, referred to as defined resources. Unlike Ruby plug-ins, defined types are written in the Puppet language and can be likened to macros in other programming languages. This differs from native types.

Type (native): A native type, also known as a native resource type, is a resource type developed in Ruby. Puppet comes with a range of pre-installed native types, while custom native types can be shared as plugins within modules. Native types offer more direct access to the target system compared to defined types, enabling them to leverage the system's tools for modifications. Typically, native types are associated with providers that can manage the same resources across various systems.

V

Value: Within the Puppet language, a value is a data element with a specific data type or, in certain instances, signifies a literal data type. Values can be assigned to variables and parameters.

Variable: In a Puppet manifest, a variable is a named placeholder representing a value. Once a variable is assigned a value, it cannot be reassigned a different value within the same scope, although other scopes can assign the variable a new value.Variables in Puppet are denoted with a dollar sign ($) and assigned using the equal sign (e.g., $operatingsystem = "Debian"). In certain scopes, variables can also be accessed using a qualified name consisting of the scope name, followed by a double-colon namespace separator, then the variable name, which can be repeated to traverse multiple scopes (e.g., $apache::params::confdir).Facts from nodes are represented as variables within Puppet manifests and are automatically assigned before compilation begins. Puppet also has several other pre-assigned variables.

Virtual resource: A virtual resource is a resource that is included in the catalog but remains inactive until explicitly realized.