The time has come to move further in our Automation series, now that we’re pretty much done with the “physical” provisioning part using Razor.

One of the first things I’d like to share with you is how to get lighttpd up and running on a newly provisioned server, and make the deployment process fully automated using Puppet from Puppetlabs.

First though, a few notes:

Creating something that automates something else is not an automated process in itself (Quantum computing and smart AI might change that around year 2030). So while the configuration below might look complex to do a simple task, remember that you can reuse the same configuration for many nodes. One configuration for Many installations instead of Many installations with Many (often different) configurations.

I am using the free and open source verion of Puppet, which means we do not have a dashboard for even easier configuration. Might do a post about that later on.

Last but not least, Puppet focuses on WHAT needs to be done, not HOW. Do your customers care HOW a service gets installed and gets it’s configuration, or do they just care WHAT is installed? Thought so 🙂

Now that that’s out of the way, let’s get started!

For this exercise, we’ll install the lighttpd webserver (awesome httpd alternative to the bulky Apache IMHO) onto one of our newly provisioned nodes. As Razor during OS-provisioning will be giving the node a specific node name which will then be used in the handoff to the puppetmaster, this is the name we’ll be using throughout the tutorial. If you have a smaller test environment, or not using Razor at all, you could also give it a more userfriendly name, say “webserver01”, by just editing the puppet.conf file on the node itself.

1. Define

We need to define a configuration that includes everything that the node should do. This could be installing a package, ensure a file exists, or perhaps starting a service. We can do this by editing the site.pp file (which is seen as the common way), or do this by editing the /etc/puppet/manifests/nodes.pp file, just like we did here. I’ll add it to my nodes.pp file as we’re only applying this to one node at the moment. We’ll look at the site.pp file in another post:

“Package” means we’ll handle an installation package. This usually has a function such as installing a service (like a web server or SQL server) or some functionality (PHP for instance) or a software (like zsh, an alternative to bash). Here we “ensure” that the package “lighttpd” is installed.

“Service” means we’ll make sure we have a service tied to this configuration. We ensure the service is running, we’re enabling it on boot, and for this service to function we require the “Package” that we’ve defined.

Pretty easy to read and follow, right?

2 & 3: Simulate & Enforce

Let’s simulate applying this configuration on our node. Running the puppet agent in “noop” mode means that no changes will be made:

We see that it would set the package value for lighttpd to present (by choosing the package and making sure it gets installed properly), and it fails on making sure the service is running as the software isn’t installed. Looks good so far, let’s run the agent again but without the “noop” mode to enforce the changes to be made:

And we can now verify that the package is removed, the service isn’t running, and no config files are left.

Revert back your changes so that the package IS installed and the service IS running. Let’s continue.

4. Report

Puppet does have some nifty reporting tools, one of the foremost tools is of course the dashboard which we won’t use right now…

For now I just want to show you one easy way of getting the important information into your puppetmaster’s logs instead of having to go through each agent’s logs.

First, edit your /etc/default/puppet file on your node to include the “–report” option (which will make it automatically report everything back to the master everytime the puppet agent service is started) like this:

The puppet agent send “facts” about itself to the puppetmaster, the puppetmaster answers with the “catalog” which is a compiled list of all aggregated configuration changes that should be done, the puppet agent reports back to the puppetmaster and we can see that report by looking into the syslog file.

Revert the configuration back once again so that the service IS running, and you’ve come to the end of this post. Next time we’ll add a few files to the service, and perhaps do some more cool stuff 🙂