You can define custom resource types for managing your infrastructure by defining types and providers. This original method has largely been replaced by the Resource API method, but you might already have a setup that uses this low-level method, or your situation might fall into one of the Resource API limitations.
Using this types and providers method, you can add new resource types to Puppet. This section describes what types and providers are, how they interact, and how to develop them.
Low-level Puppet types and providers development is done in Ruby. Previous experience with Ruby is helpful. Alternatively, opt for the more straightforward Resource API method for developing types and providers.
The internals of how types are created have changed over Puppet’s lifetime, and this documentation describes effective development methods, skipping over all the things you can but probably shouldn’t do.
- The type definition, which is a model of the resource type. It defines what parameters are available, handles input validation, and determines what features a provider can (or should) provide.
- One or more providers for that type. The provider implements the
type by translating its capabilities into specific operations on a system. For
aptproviders which implement package resources on Red Hat-like and Debian-like systems, respectively.
Deploying types and providers
To use new types and providers:
- The type and providers must be present in a module on the primary
server. Like other types of plug-in (such as custom
functions and custom facts), they go in the module’s
- Type files:
- Provider files:
lib/puppet/provider/<TYPE NAME>/<PROVIDER NAME>.rb
- Type files:
- If you are using an agent-server deployment, each agent node must have its pluginsync setting in
true, which is the default. In serverless Puppet, using
puppet apply, the
pluginsyncsetting is not required, but the module that contains the type and providers must be present on each node.