Puppet is a configuration management tool made to ease the management of your infrastructure by making it more traceable and easier to understand. It allows infrastructure-as-code, a major trend today to deal with the complexity of infrastructure management.

On the other side, Play framework is a promoting a new way to build web applications, making this sort of development more efficient and productive. By avoiding the turn over (compilation-packaging-deployment-navigation) after every change, it makes web development fun again.

This blog post explains how you can deploy your Play applications using Puppet. This allows you to develop web apps in a very productive way and deploy them reliably.

Treat your infrastructure as code

Infrastructure-as-code is a major trend in IT management. It aims to make infrastructure configuration more traceable and understandable. You can summarize this movement as “Treat your infrastructure as code. Programmable. Testable. Deployable”.

There are a couple of tools to help you make your infrastructure as code such as Chef, Vagrant and Puppet. There are already plenty of resources to compare them. In this blog post, we use Puppet.

Puppet is an open source configuration manager tool. Puppet follows one important philosophy: you describe what not how. In other words, you describe the resulting state and not how to reach it. This description is stored in a manifest specifying resources and desired states. Puppet discovers the system information and compiles the manifests into a system-specific catalog containing resources and resource dependency which is applied against the target systems. Any actions taken to remediate the system to the desired state will be reported.

In Puppet, everything is a resource. So, to support Play applications, we just have to define new resources.

Playing with resources

To support the provisioning of the Play framework and of Play applications, we wrote a Puppet module (available here) for Ubuntu, defining three resources: module, application and service.

But, before looking into those resources, let’s have a look at the Play class initializing the Play framework support. This class simply checks the availability of the Play framework on the target system and if not available, downloads and installs it.

So now that we’re sure that Play will be installed, let’s look at our resources.

• play::module handles a Play module. So this resource ensures the availability of a specified module. If not present, it installs the module.
• play::application handles a Play application. It ensures that the specified Play application is running (or stopped). If needed it starts (or stops) it. In case of starting, it resolves the dependencies. This resource supports the framework id, as well as JVM options.
• play::service handles a Play application started as a service. It ensures that a daemon script is present in /etc/init.d and is started. Similarly to play::application, it supports framework id and JVM options.

Less conversation, more action Please

Ok, enough talk; let’s see how you can deploy Play applications in practice. First, you need an Ubuntu server with Puppet, git and Java installed. Everything except Puppet can be installed with Puppet.
You can choose to install the Puppet module in /etc/puppet/modules or in any other directory. For that, just clone the Play Puppet Module:

git clone git://github.com/cescoffier/puppet-play.git play

Check that your Puppet Module path included the chosen module directory (in /etc/puppet/puppet.conf), or declare the modulepath parameter when launching Puppet.

The Puppet module does not define how your application is copied/delivered on your host. You can achieve it using scp, wget or even git. Just choose your preferred way. We just assume that we have our application copied in /var/data-www/bilderverwaltung.

Now, let’s have a look at our manifest, generally named site.pp:

Exec {
    path => ["/bin", "/sbin", "/usr/bin", "/usr/sbin"],
}
# Install mongoDB
include mongodb
#Install Play and define our Play service
include play
play::module {"mongodb module" :
 	module => "mongo-1.3",
	require => [Class["play"], Class["mongodb"]]
}
play::module { "less module" :
 	module => "less-0.3",
	require => Class["play"]
}
play::application { "bilderverwaltung" :
	path => "/var/data-www/bilderverwaltung ",
	require => [Play::Module["mongodb module"], Play::Module["less module"]
}

This manifest installs mongodb, defines two Play modules (less and mongodb), and starts the Play application. The require relationships are used to orchestrate the resolution of resources, i.e. first the Play framework, then the modules and finally the application.

So, if you apply this manifest, it installs the Play framework, installs the two modules, and starts your application:

sudo puppet apply --modulepath=/my/puppet/modules site.pp

That’s it. Thanks to Puppet, all the tricky configuration parts are managed for you. So just store your manifest in a source code management repository, and you can trace changes, rollback and re-apply the same manifest on different servers. You can also use the Play module in a Puppet master-client configuration to configure and manage sophisticated infrastructure. You can also enhance the manifest to configure an Apache 2 virtual host, or whatever you need.

Conclusion

This blog post has briefly introduced the advantage of using infrastructure as code and how you can manage Play applications with Puppet. The Play module web site contains more details about the module and the different resources.