Puppet class with parameters

Puppet class with parameters DEFAULT

Classes

Declaring a class in a Puppet manifest adds all of its resources to the catalog.

You can declare classes in node definitions, at top scope in the site manifest, and in other classes or defined types. Classes are singletons — although a given class can behave very differently depending on how its parameters are set, the resources in it are evaluated only once per compilation. You can also assign classes to nodes with an external node classifier (ENC) .

Puppet has two main ways to declare classes: include-like and resource-like. Include-like declarations are the most common; they are flexible and idempotent, so you can safely repeat them without causing errors. Resource-like declarations are mostly useful if you want to pass parameters to the class but can't or don't use Hiera. Most ENCs assign classes with include-like behavior, but others assign them with resource-like behavior. See the ENC interface documentation or the documentation of your specific ENC for details.

CAUTION: Do not mix include-like and resource-like declarations for a given class. If you declare or assign a class using both styles, it can cause compilation failures.

Include-like declarations

Include-like resource declarations allow you to declare a class multiple times — but no matter how many times you add the class, it is added to the catalog only once. This allows classes or defined types to manage their own dependencies and allows you create overlapping classes, in which a given node can have more than one role.

Include-like behavior relies on external data and defaults for class parameter values, which allows the external data source to act like cascading configuration files for all of your classes.

You can declare a class with this behavior with one of four functions: , , , and .

When a class is declared with an include-like declaration, Puppettakes the following actions, in order, for each of the class parameters:
  1. Requests a value from the external data source, using the key . For example, to get the class's parameter, Puppet searches for .
  2. Uses the default value, if one exists.
  3. Fails compilation with an error, if no value is found.

The function

The function is the most common way to declare classes. Declaring a class with this function includes the class in the catalog.

Tip: The function refers only to inclusion in the catalog. You can include a class in another class's definition, but doing so does not mean one class contains the other; it only means the included class will be added to the catalog. If you want one class to contain another, use the function instead.

This function uses include-like behavior, so you can make multiple declarations and Puppet relies on external data for parameters.

The function accepts one of the following:
  • A single class name, such as .
  • A single class reference, such as .
  • A comma-separated list of class names or class references.
  • An array of class names or class references.
This single class name declaration declares the class only once and has no additional effect:
This example declares a single class with a class reference:
This example declares two classes in a list:
This example declares two classes in an array:

The function

The function declares one or more classes, then causes them to become a dependency of the surrounding container. This function uses include-like behavior, so you can make multiple declarations, and Puppet relies on external data for parameters.

Tip: The function is used to declare classes and defined types. Do not confuse it with the metaparameter, which is used to establish relationships between resources.

The function accepts one of the following:
  • A single class name, such as .
  • A single class reference, such as .
  • A comma-separated list of class names or class references.
  • An array of class names or class references.
In this example, Puppetensures that every resource in the class is applied before any resource in any instance:

The function

The function is used inside another class definition to declare one or more classes and those classes in the surrounding class. This enforces ordering of classes. When you contain a class in another class, the relationships of the containing class extend to the contained class as well. For details about containment, see the documentation on containing classes.

This function uses include-like behavior, so you can make multiple declarations, and Puppet relies on external data for parameters.

The function accepts one of the following:
  • A single class name, such as .
  • A single class reference, such as .
  • A comma-separated list of class names or class references.
  • An array of class names or class references.
In this example class declaration, the class contains the class. Any resource that forms a relationship with the class also has the same relationship to the class.

For example, if a resource has a relationship with the class, that resource will also be applied before the class. Similarly, any resource that forms a relationship with will be applied after .

The function

The function requests a list of class names from Hiera, then declares all of them.

This function uses include-like behavior, so you can make multiple declarations, and Puppet relies on external data for parameters. The function accepts a single lookup key.

Because uses the array lookup type, it gets a combined list that includes classes from every level of the hierarchy. This allows you to abandon node definitions and use Hiera like a lightweight external node classifier. For more information, see the Hiera documentation.

For example, this declaration in the site manifest applies classes across the site infrastructure, as specified in Hiera.
Given the Hieradata below, the node in the production environment gets the classes , , , and . On all other nodes, only the class is declared.

Resource-like declarations

Resource-like class declarations require that you declare a given class only once. They allow you to override class parameters at compile time — for any parameters you don't override, Puppet falls back to external data.

Resource-like declarations must be unique to avoid conflicting parameter values. Repeated overrides cause catalog compilation to be unreliable and dependent on order evaluation. This is because overridden values from the class declaration:
  • Always take precedence.
  • Are computed at compile time.
  • Do not have a built-in hierarchy for resolving conflicts.
When a class is declared with a resource-like declaration, Puppettakes the following actions, in order, for each of the class parameters:
  1. Uses the override value from the declaration, if present.
  2. Requests a value from the external data source, using the key . For example, to get the class's parameter, Puppet searches for .
  3. Uses the default value.
  4. Fails compilation with an error, if no value is found.

Resource-like declarations look like normal resource declarations, using the pseudo-resource type. You can provide a value for any class parameter by specifying it as a resource attribute.

You can also specify a value for any metaparameter. In such cases, every resource contained in the class will also have that metaparameter. However:
  • Any resource can specifically override metaparameter values received from its container.
  • Metaparameters that can take more than one value, such as the relationships metaparameters, merge the values from the container and any resource-specific values.
  • You cannot apply the metaparameter to resource-like class declarations.

For example, this resource-like declaration declares a class with no parameters:
This declaration declares a class and specifies the version parameter:
Sours: https://puppet.com/docs/puppet/6/lang_classes.html

Class parameters

{% include '/version.md' %}

Quest objectives

  • Understand the value of writing configurable classes.
  • Learn the syntax for creating a parameterized class.
  • Learn how to use the resource-like class declaration syntax to set the parameters for a class.

Getting started

In the last quest, you used variables to introduce some flexibility to your module. So far, however, all of the variables are assigned within the class itself.

A well-written module in Puppet should let you customize all of its important variables without editing the module itself. This is done with class parameters. Writing parameters into a class allows you to declare that class with a set of parameter-value pairs similar to the resource declaration syntax. This gives you a way to customize all the important variables in your class without making any changes to the module that defines it.

When you're ready to get started, enter the following command:

Writing a parameterized class

A class's parameters are defined as a comma-separated list of parameter name and default value pairs (). These parameter value pairs are enclosed in parentheses () between the class name and the opening curly bracket () that begins the body of the class. For readability, multiple parameters should be listed one per line, for example:

classclass_name ( $parameter_one = default_value_one, $parameter_two = default_value_two, ){ ... }

Notice that this list of parameters must be comma-separated, while variables set within the body of the class itself are not. This is because the Puppet parser treats these parameters as a list, while variable assignments in the body of your class are individual statements. These parameters are available as variables within the body of the class.

Task 1:

To get started, let's modify the main class to use class parameters. Open your manifest.

Your parameter list will replace the variables assignments you used in the previous quest. By setting the parameter defaults to the same values you had assigned to those variables, you can maintain the same default behavior for the class.

Remove the variables set at the beginning of your class and add a corresponding set of parameters. When you're done, your class should look like the following example.

classpasture ( $port = '80', $default_character = 'sheep', $default_message = '', $pasture_config_file = '/etc/pasture_config.yaml', ){ package { 'pasture': ensure => present, provider => 'gem', before => File[$pasture_config_file], } $pasture_config_hash = { 'port' => $port, 'default_character' => $default_character, 'default_message' => $default_message, } file { $pasture_config_file:content => epp('pasture/pasture_config.yaml.epp', $pasture_config_hash), notify => Service['pasture'], } $pasture_service_hash = { 'pasture_config_file' => $pasture_config_file, } file { '/etc/systemd/system/pasture.service': content => epp('pasture/pasture.service.epp', $pasture_service_hash), notify => Service['pasture'], } service { 'pasture': ensure => running, } }

When you're done making these changes, save and exit your file. Use the tool to check your syntax.

Resource-like class declarations

Now that your class has parameters, let's see how these parameters are set.

Until now, you've been using to declare the class as part of your node classification in the manifest. This function declares a class without explicitly setting any parameters, allowing any parameters in the class to use their default values.

To declare a class with specific parameters, use the resource-like class declaration. As the name suggests, the syntax for a resource-like class declaration is very similar to a resource declaration. It consists of the keyword followed by a set of curly braces () containing the class name with a colon () and a list of parameters and values. Any values left out in this declaration are set to the defaults defined within the class.

class { 'class_name': parameter_one => value_one, parameter_two => value_two, }

Unlike the function, which can be used for the same class in multiple places, resource-like class declarations can only be used once per class. Because a class declared with the uses defaults, it will always be parsed into the same set of resources in your catalog. This means that Puppet can safely handle multiple calls for the same class. Because multiple resource-like class declarations are not guaranteed to lead to the same set of resources, Puppet has no unambiguous way to handle multiple resource-like declarations of the same class. Attempting to make multiple resource-like declarations of the same class will cause the Puppet parser to throw an error.

Though we won't go into detail here, you should know that external data-sources like and can give you a lot of flexibility in your classes even with the include syntax. For now, you should be aware that though the function uses defaults, there are ways to make those defaults very intelligent.

Task 2:

Now let's go ahead and use a resource-like class declaration to customize the class from the manifest. Most of the defaults will still work well, but for the sake of this example, let's set this instance of our Pasture application to use the classic cow character instead of the sheep we had set as the parameter default.

Open your manifest.

Modify your node definition for to include a resource-like class declaration. We'll set the parameter to the string , and leave the other two parameters unset, letting them take their default values.

node 'pasture.puppet.vm' { class { 'pasture': default_character => 'cow', } }

Notice that with your class parameters set up, all the necessary configuration for all the components of the Pasture application can be handled with a single resource-like class declaration. The diverse commands and file formats that would ordinarily be involved in managing this application are reduced to this single set of parameters and values.

Task 3:

Let's connect to the node.

And trigger a Puppet agent run to apply this parameterized class.

When the run is complete, return to the Puppet server.

And check that your configuration changes have taken effect.

Review

In this quest, we introduced class parameters, a way to customize a class as it's declared. These parameters let you set up a single interface for you to customize any aspect of the system your Puppet module manages.

We also revisited the function and covered the resource-like class declaration, the syntax for specifying values for a class's parameters as they are declared.

In the next quest, we'll introduce facts, which can be used to easily introduce data about your agent system into your Puppet code.

Additional Resources

Sours: https://github.com/puppetlabs/puppet-quest-guide/blob/master/quests/class_parameters.md
  1. Lutron outlets smart
  2. Weather dee why
  3. Plotly graph objects
  4. 300ex honda parts

Variables

Exploring variables, facts, and parameters.

This is part of a series of articles starting with Puppet Code by Example: Part 1. The final body of Puppet Code developed through this series is available for download.

So far we have only been using hard-coded values, e.g., the string Hello World. Here we introduce Puppet variables (which behave more like constants) to help eliminate duplicated hard-coded values.

Variables store values so that those values can be accessed in code later.

After you’ve assigned a variable a value, you cannot reassign it. Variables depend on order of evaluation: you must assign a variable a value before it can be resolved.

— Puppet — Variables

To illustrate a basic use of variables, let’s create a new module by executing the following from the modules folder:

$ pdk new module my_variables

And the executing the following from the modules/my_variables folder:

$ pdk new class local_variables

We update modules/my_variables/manifests/local_variables.pp:

Things to observe:

  • Here we follow Puppet’s variable naming constraints; seems like the convention is to also stick with lower case letters
  • By switching to using double-quotes in defining strings, we can include variables as shown (referred to as interpolation)

So far we have only used locally (to class) scoped variables; let’s change that by first creating a new class by executing the following from the modules/my_variables folder.

$ pdk new class scoped_variables

We update modules/my_variables/manifests/scoped_variables.pp as shown:

Things to observe:

  • Notice that we can reuse the same variable name, $my_content, in a different class
  • (/tmp/scoped_variables_1 resource) Notice that we can reference the variable, $my_content, in a different class, local_variables, by using a fully qualified reference
  • (/tmp/scoped_variables_2 resource) While we need to create it (which we will do shortly), we can reference module variables
  • (/tmp/scoped_variables_3 resource) While we also need to create it (we will also do this shortly), we can reference global variables

Let’s define that module variable, by creating the module’s main class by executing the following from the modules/my_variables folder.

$ pdk new class my_variables

And updating modules/my_variables/manifest/init.pp:

Let’s define the global variable by updating manifest/site.pp:

So far we have used variables that we have created; here we use variables supplied to us from the agent itself (facts).

Before requesting a catalog for a managed node, or compiling one with puppet apply, Puppet collects system information, called facts, by using the Facter tool. The facts are assigned as values to variables that you can use anywhere in your manifests. Puppet also sets some additional special variables, called built-in variables, which behave a lot like facts.

— Puppet — Facts and Built-in Variables

To see what variables are available from an agent, we can log in to the system running the agent and execute:

$ facter -p
...
os => {
architecture => "amd64",
distro => {
codename => "buster",
description => "Debian GNU/Linux 10 (buster)",
id => "Debian",
release => {
full => "10.6",
major => "10",
minor => "6"
}
},
family => "Debian",
hardware => "x86_64",
name => "Debian",
...
}
...

Please note: This is only a small sample of the output.

To illustrate a basic use of facts, let’s create a new module by executing the following from the modules folder.

$ pdk new module my_facts

And executing the following from the modules/my_facts folder:

$ pdk new class my_class

We update modules/my_facts/manifests/my_class.pp as shown:

Things to observe:

  • Here we use the preferred hash syntax for access facts
  • I was going to show the older syntax to access facts but my editor (VSCode with Puppet extension) complained; basically forcing me to use the preferred syntax

And for completeness, we create a main class for my_facts, include my_class in it, and include it in the site manifest.

Here we explore how to make classes more flexible by passing external data into them using parameters.

Parameters allow a class to request external data. If a class needs to use data other than facts for configuration, use a parameter for that data.

You can use class parameters as normal variables inside the class definition. The values of these variables are set based on user input when the class is declared, rather than with normal assignment statements.

— Puppet — Classes

So far our classes have not accepted parameters and we have declared our classes (used them) in our node definitions using include-like declarations, e.g., include my_module.

Please note: There is a separate, less flexible way to declare our classes, resource-like declarations, that we will not be using for now.

As a side-bar, one subtle but important feature of classes is that they are singletons:

Include-like resource declarations allow you to declare a class multiple times — but no matter how many times you add the class, it is added to the catalog only once. This allows classes or defined types to manage their own dependencies and allows you create overlapping role classes, in which a given node can have more than one role.

— Puppet — Classes

Please note: In object-oriented languages, the concept of a class, template-like, is very different than Puppet’s singleton-like implementation.

Let’s first create a parametrized class by creating a my_parameters module with the classes my_class and the usual main (my_parameters) class.

Please note: In the interest of brevity, I will stop explicitly providing the commands for things that we have done multiple times.

We update modules/my_parameters/manifests/my_class.pp as shown:

Things to observe:

  • This class requires a string parameter $greeting
  • The type-definition, String, is optional (but a good practice)

We then include the class in our node definition as we have done in the past, manifests/site.pp:

Things to observe:

  • We did not supply a value for the $greeting parameter as include-like declarations do not support passing parameters
  • Because one can include the same class multiple time using include-like declarations; it makes sense that they do not support passing parameters (otherwise one could introduce discrepancies)
  • We have a problem as we have not supplied a value for the required $greeting parameter yet

The solution is to use a set of configuration files collectively referred to as Hiera (presumably short for hierarchy) to supply parameters to our classes.

Puppet’s strength is in reusable code. Code that serves many needs must be configurable: put site-specific information in external configuration data files, rather than in the code itself.

Puppet uses Hiera to do two things:
- Store the configuration data in key-value pairs
- Look up what data a particular module needs for a given node during catalog compilation

— Puppet — About Hiera

The default production environment Hiera configuration uses a file, data/common.yaml, to supply parameter values. In this case, we update it to supply a value for the $greeting parameter for the class my_class in the my_parameters module:

We will wrap up this series in the next article in the series, Puppet Code by Example: Part 3.

Sours: https://codeburst.io/puppet-code-by-example-part-2-b1099b4ff9a1
Puppet Class with Seth MacFarlane - SNL

Language: Classes

Classes are named blocks of Puppet code that are stored in modules for later use and are not applied until they are invoked by name. They can be added to a node’s catalog by either declaring them in your manifests or assigning them from an ENC.

Classes generally configure large or medium-sized chunks of functionality, such as all of the packages, config files, and services needed to run an application.

Defining classes

Defining a class makes it available for later use. It doesn’t yet add any resources to the catalog; to do that, you must declare it (see below) or assign it from an ENC.

Syntax

The general form of a class definition is:

  • The keyword
  • The name of the class
  • An optional parameter list, which consists of:
    • An opening parenthesis
    • A comma-separated list of parameters (e.g. ). Each parameter consists of:
      • An optional data type, which will restrict the allowed values for the parameter (defaults to )
      • A variable name to represent the parameter, including the prefix
      • An optional equals () sign and default value (which must match the data type, if one was specified)
    • An optional trailing comma after the last parameter
    • A closing parenthesis
  • Optionally, the keyword followed by a single class name
  • An opening curly brace
  • A block of arbitrary Puppet code, which generally contains at least one resource declaration
  • A closing curly brace

Class parameters and variables

Parameters allow a class to request external data. If a class needs to configure itself with data other than facts, that data should usually enter the class via a parameter.

Each class parameter can be used as a normal variable inside the class definition. The values of these variables are not set with normal assignment statements or looked up from top or node scope; instead, they are set based on user input when the class is declared.

Note that if a class parameter lacks a default value, the module’s user must set a value themselves (either in their external data or an override). As such, you should supply defaults wherever possible.

Each parameter can be preceeded by an optional data type. If you include one, Puppet will check the parameter’s value at runtime to make sure that it has the right data type, and raise an error if the value is illegal. If no data type is provided, the parameter will accept values of any data type.

The special variables and are both set to the class name automatically, so they can’t be used as parameters.

Location

Class definitions should be stored in modules. Puppet is automatically aware of classes in modules and can autoload them by name.

Classes should be stored in their module’s directory as one class per file, and each filename should reflect the name of its class; see Module Fundamentals and Namespaces and Autoloading for more details.

A class definition statement isn’t an expression and can’t be used where a value is expected.

Other locations

Most users should only put classes in individual files in modules. However, it’s technically possible to put classes in the following additional locations and still load the class by name:

  • The main manifest. If you do so, they can be placed anywhere in the main manifest file and are not evaluation-order dependent. (That is, you can safely declare a class before it’s defined.)
  • A file in the same module whose corresponding class name is a truncated version of this class’s name. That is, the class could be put in ’s file, .
  • Lexically inside another class definition. This puts the interior class under the exterior class’s namespace, causing its real name to be something other than the name with which it was defined. (For example: in , the interior class’s real name is .) Note that this doesn’t cause the interior class to be automatically declared along with the exterior class.

Again: You should never do these.

Containment

A class contains all of its resources. This means any relationships formed with the class as a whole will be extended to every resource in the class.

Classes can also contain other classes, but you must manually specify that a class should be contained. For details, see the “Containing Classes” section of the Containment page.

A contained class is automatically tagged with the name of its container.

Auto-tagging

Every resource in a class gets automatically tagged with the class’s name and each of its namespace segments.

Inheritance

Classes can be derived from other classes using the keyword. This allows you to make special-case classes that extend the functionality of a more general “base” class.

If a base class has parameters, those parameters must either have default values, or have their values supplied by automatic external data lookup. You can’t specify values in the Puppet language for parameters in an inherited class.

Inheritance causes three things to happen:

  • When a derived class is declared, its base class is automatically declared first (if it wasn’t already declared elsewhere).
  • The base class becomes the parent scope of the derived class, so that the new class receives a copy of all of the base class’s variables and resource defaults.
  • Code in the derived class is given special permission to override any resource attributes that were set in the base class.

Aside: When to Inherit

Class inheritance should be used very sparingly, generally only in the following situations:

  • When you need to override resource attributes in the base class.
  • To let a “params class” provide default values for another class’s parameters:

This pattern works by guaranteeing that the params class is evaluated before Puppet attempts to evaluate the main class’s parameter list. It is especially useful when you want your default values to change based on system facts and other data, since it lets you isolate and encapsulate all that conditional logic.

In nearly all other cases, inheritance is unnecessary complexity. If you need some class’s resources declared before proceeding further, you can include it inside another class’s definition. If you need to read internal data from another class, you should generally use qualified variable names instead of assigning parent scopes. If you need to use an “anti-class” pattern (e.g. to disable a service that is normally enabled), you can use a class parameter to override the standard behavior.

Note also that you can use resource collectors to override resource attributes in unrelated classes, although this feature should be handled with care.

Overriding resource attributes

The attributes of any resource in the base class can be overridden with a reference to the resource you wish to override, followed by a set of curly braces containing attribute => value pairs:

This is identical to the syntax for adding attributes to an existing resource, but in a derived class, it gains the ability to rewrite resources instead of just adding to them. Note that you can also use multi-resource references here.

You can remove an attribute’s previous value without setting a new one by overriding it with the special value :

This causes the attribute to be unmanaged by Puppet.

Note: If a base class declares other classes with the resource-like syntax, a class derived from it cannot override the class parameters of those inner classes. This is a known bug.

Appending to resource attributes

Some resource attributes, such as the relationship metaparameters, can accept multiple values in an array. When overriding attributes in a derived class, you can add to the existing values instead of replacing them by using the (“plusignment”) keyword instead of the standard hash rocket:

Declaring classes

Declaring a class in a Puppet manifest adds all of its resources to the catalog. You can declare classes in node definitions, at top scope in the site manifest, and in other classes or defined types. Declaring classes isn’t the only way to add them to the catalog; you can also assign classes to nodes with an ENC.

Classes are singletons — although a given class can have very different behavior depending on how its parameters are set, the resources in it will only be evaluated once per compilation.

Include-like vs. resource-like

Puppet has two main ways to declare classes: include-like and resource-like.

Note: These two behaviors should not be mixed for a given class. Puppet’s behavior when declaring or assigning a class with both styles is undefined, and will sometimes work and sometimes cause compilation failures.

Include-like behavior

The , , , and functions let you safely declare a class multiple times; no matter how many times you declare it, a class will only be added to the catalog once. This can allow classes or defined types to manage their own dependencies, and lets you create overlapping “role” classes where a given node can have more than one role.

Include-like behavior relies on external data and defaults for class parameter values, which allows the external data source to act like cascading configuration files for all of your classes. When a class is declared, Puppet will try the following for each of its parameters:

  1. Request a value from the external data source, using the key . (For example, to get the class’s parameter, Puppet would search for .)
  2. Use the default value.
  3. Fail compilation with an error if no value can be found.

Resource-like behavior

Resource-like class declarations require that you only declare a given class once. They allow you to override class parameters at compile time, and will fall back to external data for any parameters you don’t override. When a class is declared, Puppet will try the following for each of its parameters:

  1. Use the override value from the declaration, if present.
  2. Request a value from the external data source, using the key . (For example, to get the class’s parameter, Puppet would search for .)
  3. Use the default value.
  4. Fail compilation with an error if no value can be found.

Aside: Why do resource-like declarations have to be unique?

This is necessary to avoid paradoxical or conflicting parameter values. Since overridden values from the class declaration always win, are computed at compile-time, and do not have a built-in hierarchy for resolving conflicts, allowing repeated overrides would cause catalog compilation to be unreliable and evaluation-order dependent.

This was the original reason for adding external data bindings to include-like declarations: since external data is set before compile-time and has a fixed hierarchy, the compiler can safely rely on it without risk of conflicts.

Using

The function is the standard way to declare classes.

The function uses include-like behavior. (Multiple declarations OK; relies on external data for parameters.) It can accept:

  • A single class name (like ) or class reference (like )
  • A comma-separated list of class names or class references
  • An array of class names or class references

Using

The function (not to be confused with the metaparameter) declares one or more classes, then causes them to become a dependency of the surrounding container.

In the above example, Puppet will ensure that every resource in the class gets applied before every resource in any instance.

The function uses include-like behavior. (Multiple declarations OK; relies on external data for parameters.) It can accept:

  • A single class name (like ) or class reference (like )
  • A comma-separated list of class names or class references
  • An array of class names or class references

Using

The function is meant to be used inside another class definition. It declares one or more classes, then causes them to become contained by the surrounding class. For details, see the “Containing Classes” section of the Containment page.

In the above example, any resource that forms a or relationship with class will also be applied before or after class , respectively.

The function uses include-like behavior. (Multiple declarations OK; relies on external data for parameters.) It can accept:

  • A single class name (like ) or class reference (like )
  • A comma-separated list of class names or class references
  • An array of class names or class references

Using

The function requests a list of class names from Hiera, then declares all of them. Since it uses the array lookup type, it will get a combined list that includes classes from every level of the hierarchy. This allows you to abandon node definitions and use Hiera like a lightweight ENC.

On the node in the production environment, the example above would declare the classes , , , and . On other nodes, it would only declare .

The function uses include-like behavior. (Multiple declarations OK; relies on external data for parameters.) It accepts a single lookup key.

Using resource-like declarations

Resource-like declarations look like normal resource declarations, using the special pseudo-resource type.

Resource-like declarations use resource-like behavior. (Multiple declarations prohibited; parameters can be overridden at compile-time.) You can provide a value for any class parameter by specifying it as resource attribute; any parameters not specified will follow the normal external/default/fail lookup path.

In addition to class-specific parameters, you can also specify a value for any metaparameter. In such cases, every resource contained in the class will also have that metaparameter:

However, note that:

  • Any resource can specifically override metaparameter values received from its container.
  • Metaparameters which can take more than one value (like the relationship metaparameters) will merge the values from the container and any resource-specific values.

Assigning classes from an ENC

Classes can also be assigned to nodes by external node classifiers and LDAP node data. Note that most ENCs assign classes with include-like behavior, and some ENCs assign them with resource-like behavior. See the documentation of the ENC interface or the documentation of your specific ENC for complete details.

Appendix: Smart parameter defaults

This design pattern can make for significantly cleaner code while enabling some really sophisticated behavior around default values.

To summarize what’s happening here: When a class inherits from another class, it implicitly declares the base class. Since the base class’s local scope already exists before the new class’s parameters get declared, those parameters can be set based on information in the base class.

This is functionally equivalent to doing the following:

This is a significant readability win, especially if the amount of logic or the number of parameters grows beyond what’s shown in the example.

Sours: https://puppet.com/docs/puppet/5.5/lang_classes.html

With puppet parameters class

.

Puppet 5 – From Beginner to Pro : Classes - packtpub.com

.

You will also like:

.



1427 1428 1429 1430 1431