Puppet Coding Style

In Puppet, the coding style describes all the requirements that must be followed when attempting to transform infrastructure on the system configuration into code. Puppet requires resources to work and execute all of its defined tasks.

As we know, the puppet employs Ruby language as its encoding language, which provides several predefined features, and with the help of these features, it is very easy to complete the things with the simple configuration on code.

Fundamental Units

There are many fundamental coding styles used by a puppet that is easy to understand and use. Let's see some of them:

Resources

In puppet, resources are the basic unit used for modeling the system configurations.

Resources are the building blocks of a puppet. Each resource describes the desired state for some aspects of a system, such as service, file, and package.

Resources are the predefined functions that allow the users or developers to develop custom resources, with the help of which we can manage any particular unit of a system.

Resources in the puppet are aggregated together by using either "define" or "classes." This feature provides help in organizing a module.

Every resource declaration at least contains a resource type, a title, and a set of attributes.

Syntax:

Let's see one sample resource where a title and a list of attributes are defined. Each resource contain a default value which could be overridden as per our requirement.

The above command specifies the permission for a particular file.

Each time the command is executed on any system, it will validate that the system's passwd file is configured as described. Here, the file defined before the colon (:) is the title of the resource, which we can use as a resource in other puppet configuration section.

Let's define local name in addition to the title:

It is very convenient to refer to file resources in the configuration by using the title, which is always the same, which helps to reduce the repetition of OS-related logic.

Example of a user resource declaration:

Another example may be using a service which is dependent on a file:

Here, the sshd service will always restart once the sshdconfig file changes. The important thing is File[sshdconfig] is a declaration as file as in the lower case, but if we modify it to FILE[sshdconfig], then it would have been a reference.

The main point to be noted is that we can declare a resource only once per Config file. If we repeat the declaration of the same resource, then it will cause an error.

Even we can manage multiple relationships through the resource dependency: