Tiny Puppet

Essential Application Management
with Puppet

Puppet Forge Version

View the Project on GitHub example42/puppet-tp


TP playground



Tiny Data

Essential Application Management

Tiny Puppet is a Puppet module we can use to manage virtually any application on any Operating System (here’s the current Compatibility Matrix).

We can install an application and start its eventual services with:

tp::install { 'apache': }

This and the following examples use defines optimized for Puppet 4, with earlier versions we can use the alternatives the suffix 3, such as:

tp::install3 { 'apache': }

We can configure the main configuration file of our application with a custom template populated from an custom hash of options with something like:

conf { 'openssh'
  template     => 'site/openssh/sshd_config.erb',
  options_hash => hiera_hash('openssh::options'),

Tiny Puppet takes care of dependencies (file is managed after the package and triggers a service restart, by default) and correct paths and names for the underlying Operating System.

It just assumes that we know how to configure our files, and allows us to have full control on how to shape the data that feeds them.

It also saves us from the efforts to find, understand and integrate a dedicated component module and make it produce the output we need.

We can manage actually any configuration file related to an application. For example to manage directly the content of a file in a conf.d directory we specify the base_dir type and the name of the file in the title (in the following example file managed is /etc/rsyslog.d/logserver.conf):

tp::conf { 'rsyslog::logserver.conf':
  content  => "*.* @@syslog.example.com\n",
  base_dir => 'conf',

In the previous examples the actual paths of the managed files have been somehow automagically calculated, if we don’t believe in magics and want to be sure of the path, we can just specify it. In the following example we also set the mode and the name of the epp template we want to use for it.

tp::conf { 'openssh::root_config': #
  path   => '/root/.ssh/config',
  epp    => 'site/openssh/root/config.epp',
  mode   => '0640',

In this case the title of the define is not used as file name, but it still needs to be set, have the application namespace(openssh), and be unique in our catalog (root_config):

We can also manage the content or whole directories from a given fileserver:

tp::dir { 'openssh':
  source => 'puppet:///modules/site/openssh',

And we can even specify the source from a given VCS tool (in this case we place the content of a git repo in the data directory of nginx (exposing directly the content of a repo on a webserver is not a recommended practices, this example is just to give an idea of what can be done):

tp::dir { 'nginx::website':
  source   => 'https://git.example.com/apps/website/',
  vcsrepo  => 'git',
  base_dir => 'data',

For more details on how to use Tiny Puppet defines and the logic behind some automatic path choices check the usage page.


Tiny Puppet may look like a joke, but it works.

As long as our application can be installed via a native package (Tiny Puppet manages eventual additional repos) and there’s the correct tinydata to handle it.

So, this Tiny Puppet is about:

All the data used by Tiny Puppet to support different applications is stored in the separated tinydata module. Check this page for more info about it.

Tiny Puppet defines

Tiny Puppet provides the following defines (Puppet 4 compatible only)

If you use Puppet 3 or earlier, use the alternatives : tp::install3, tp::conf3, tp::dir3 and so on.

Other defines are under work, planned or envisioned: