Puppet is very extensible and allows you to create custom facts, functions, types and providers so that you can automate what you need to automate, how you need to automate it. It all still uses the same Puppet DSL, so you have the same look and feel in your Puppet code for your users.
Types and providers
Puppet's built-in types—like
service—describe types of resources available on a system, while providers describe how to manage those resources on specific platforms. You can write your own custom types and providers for them and you can also write custom providers for built-in types.
If you need to create a custom type with an (optional) single provider, the quickest way is to use the Resource API, which is available in Puppet 6 and later. The Resource API is a simplified interface for defining types and providers using a minimal amount of Puppet code. There are a few limitations, but the Resource API covers many use-cases for custom types.
Puppet's built-in functions—like
json_data—extend the puppet language to perform conversions, calculations, data lookups, and more. You can write your own custom functions in either puppet language or ruby, but keep in mind that functions run on the Puppet server while your puppet catalog is compiled, before it is sent to your agent nodes. This means that external calls in functions may impact catalog compile times, and functions will run on the server side (not in "real time" on the agent nodes) by default, although functions may be deferred to allow them to run on agent nodes if needed. For more on functions, check out these docs on writing custom functions.
Facts in Puppet describe the system—its OS, hardware or virtualization information, etc. If Puppet's built-in facts don't cover your needs, there are two ways to add your own:
- Write custom facts in puppet's ruby DSL, or
- Write an external fact by providing static data or an executable script in any language present on your nodes.
Custom facts and external facts can be distributed from your server to your agent nodes via pluginsync, so they can be used in catalogs anywhere. Modules you install can also provide their own custom facts. At the enterprise level, custom facts are often distributed in an organization-wide facts module. For example, such a module could be named
yourorganization-facts and contain organization-specific facts.
When writing custom facts that may run on multiple operating systems, keep in mind that facts run on each node directly. If it's difficult to keep your custom fact code platform-agnostic, you can confine the fact execution to only run on certain platforms.