Using Puppet Apply on-the-fly

Puppet Apply

Normally Puppet will run in a client – server mode where the client will poll the server every 30 minutes for configuration changes. However, there is no requirement for the Puppet Server and it is possible to apply from the Puppet client software. This is useful in new deployments where we only need an initial configuration and do not need on going configuration management. On these cases using Puppet Apply really does work well for us. This follows on from the first tutorial where we discuss “What is Puppet” . Puppet Open Source or Enterprise can be gained from Puppetlabs.

This also make a great starting point in learning Puppet as there is no work that we have to to in getting the infrastructure ready and in-place. You will see that we can apply until our heart is content directly from the command line.

In this tutorial we look at the dimple notify resource to write to the screen in this case and then manage the Avahi-Daemon service which is perhaps a little more world real.

Firstly we can check the version of Puppet that we have installed, mainly to confirm the client is in place but also for information.

$ puppet --version

From the output of my Raspberry Pi Raspbian based system we can see the version displayed as 3.7.2:

Hello World

We can then use the traditional and obligatory learning mantra of “Hello World”. Using the notify resource we can write back to the screen:

$ puppet apply -e ' notify { "Hello World" : }'

Note that we use single quotes to encapsulate the -e string and then double-quotes internally.

Manage Services

Moving onto something a little more practical we can use Puppet the manage services. In this case will will stop and disable the Avahi-Daemon. We don’t use the mDNS service and don’t want it running:

$ sudo puppet apply -e ' service { "avahi-daemon": ensure=>"stopped", enable =>false,}'

Don’t forget the terminating comma after the final key-value pair

Operating System Agnostic

Puppet is OS agnostic in the fact that we do not need to vary this command between systemd, upstart and sysvinit systems. For us this is great! The way in which the service is managed is nothing to do with Puppet. Puppet just dictates the desired state and not how it is to be achieved. In this way managing many systems through the one manifest is very easy. In the next tutorial we will move into understanding manifests.