Principal Developer Rhodri Pugh explains the process we've put in place at Box UK to effectively and stably package Clojure applications.
25 June 2013
Rolling out Clojure
At Box UK we try, where practical, to be technology agnostic and pick the best tool for the job. Over the next few years I see Clojure (and possibly other JVM languages like Scala) becoming more and more important in solving the problems that both we and our clients encounter.
Internally I’ve been trialling small Clojure applications and libraries for some time, but if we’re going to be rolling these out to production environments then we’re going to need a stable way to do it.
In our current deployment process, using RPMs for all our applications has become standard. But doing some casual Googling on how to get started building these for Clojure projects turned up very few results…There’s a plugin for Leiningen, but we use a slightly more custom process with Mock to create a clean chroot’d build environment, and I couldn’t see how this was going to work for us.
Another problem (before even being able to consider the previous plugin) is Leiningen itself. This is the de facto standard tool for managing Clojure projects, but unfortunately the packaged version is way out of date. This causes problems as our build servers need to be managed in the same way as all our other boxes: packaged software only please.
None of this is too challenging though, so I’ll go over what we put in place to effectively package Clojure applications.
The first step is packaging Leiningen. With the most recent version I could find being 1.7-something, we needed to roll our own, which we’ve packaged under the name boxuk-leiningen to avoid naming conflicts should an official package appear. Here’s the interesting bit:
If someone tries to self-install they’ll probably get some unexpected behaviour…but at the moment we’re mainly just pulling this in for our RPM builds so it doesn’t matter too much.
With Leiningen now available the second part is packaging individual applications. The setup we’ve started rolling with is far from perfect, but it’s a work in progress and something we will improve. The project is available on Github, so go check it out if you’re interested. Again, while it’s tailored slightly to our specific process, it should be a good starting point if this is your first attempt at doing this kind of thing.
As you can see, we pull in our custom Leiningen RPM as a build dependency. Rather than embedding web applications within a container like Tomcat we’re using the lein-bin plugin to create standalone ‘binaries’ for each application. This then packages all the dependencies and just requires Java on the servers being deployed to. It also lets the application decide which kind of web server it uses (if any of course).
The rest of the file is standard RPM stuff; setting the application up using chkconfig with an init script to manage it:
And hopefully if you’re looking to do the same then this will be a helpful starting point – let me know in the comments.
About the author
Rhodri Pugh is a Principal Developer at Box UK. With experience in a variety of systems Rod is particularly interested in writing code to solve interesting problems, whether that’s individual client support items or applications with millions of users.