Low-level method for developing types and providers
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
example, the
package
type hasyum
andapt
providers 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
lib
directory:- Type files:
lib/puppet/type/<TYPE NAME>.rb
- 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 inpuppet.conf
set totrue
, which is the default. In serverless Puppet, usingpuppet apply
, thepluginsync
setting is not required, but the module that contains the type and providers must be present on each node.
-
Type development
When you define a resource type, focus on what the resource can do, not how it does it. -
Provider development
Providers are back-ends that support specific implementations of a given resource type, particularly for different platforms. Not all resource types have or need providers, but any resource type concerned about portability will likely need them. -
Creating resources
You can write resource types and providers in the Puppet language. The following example shows you how to create resources in Puppet using the low-level types and provider method.