Plug-ins in modules
Puppet supports several kinds of plug-ins, which are distributed in modules. These plug-ins enable features such as custom facts and functions for managing your nodes. Modules that you download from the Forge can include these kinds of plug-ins, and you can also develop your own.
When you install a module that contains plug-ins, they are automatically enabled. At the start of every Puppet run, Puppet Server loads all the plug-ins available in the environment's modulepath. Agents download those plug-ins, so module plug-ins are available for use on the first Puppet run after you install them in an environment.
Plug-ins are available whether or not a node uses classes or defined
types from a given module. In other words, even if you don't declare any classes from
the stdlib module, nodes
still use the stdlib
custom facts. There is no way to exclude plug-ins in an environment in which they are
installed.
If the agent and primary server are both running Puppet 5.3.4 or newer, the agent also downloads any non-English translations included in the module.
Puppet supports several kinds of plug-ins. Puppet looks for each plug-in in a different subdirectory of the module. If you are adding plug-ins to a module, be sure to place them in the correct module subdirectory. In all cases, you must name files and additional subdirectories according to the plug-in type's loading requirements.
Environments aren't completely isolated for certain kinds of plug-ins. If you are using custom resource types or legacy custom functions, you can encounter conflicts if your environments contain differing versions of a given plug-in.In such cases, Puppet loads the first version it encounters of the plug-in, and then continues to use that version for all environments.
To avoid plug-in conflicts for resource
types, use the puppet
generate types command as described in the environment isolation
documentation. To fix issues with legacy custom functions, rewrite them with the
modern API, which is not affected by this issue.