ActiveBlog

Stackato, like Cloud Foundry, strives to get out of your way as much as possible when deploying web applications. We recently added support for Clojure through leiningen, the de-facto tool to setup and work with Clojure projects. To better understand the effort involved in porting a Clojure web application, we actually ported two applications well-known in the Clojure community: ClojureSphere and 4Clojure.

ClojureSphere

ClojureSphere was originally born out of the need to find all projects depending on a particular Clojure library.

ClojureSphere does not use any data services, so porting it to Stackato involved only a couple of trivial changes:

• Read web server port number from the VCAP_APP_PORT (see commit)
• Configure project.clj (leiningen project file) to respond to lein run - the command used by Stackato to launch your Clojure application.

You can browse these code changes at GitHub.

4Clojure

4Clojure helps beginner Clojure programmers learn the language by solving interactive problems. It provides a list of programming problems each of which can be solved by the user using Clojure. The application accepts the user's solution and runs it (in a sandbox) against the list of known test cases. The more problems one solves, the higher they get on the Top User's list. 4Clojure also features "code golf" that evaluates the submitted solutions based on conciseness.

4Clojure uses MongoDB to store problems, solutions and user profile data.

• Using MongoDB in stackato: After defining a mongo service in stackato.yml, we need to read the service credentials by parsing the JSON structure present in the VCAP_SERVICES environment variable. 4Clojure represents its configuration (holding port number, mongo credentials, etc.) as Clojure code itself. We had to modify the code reading this config file, to merge in Stackato's mongo service credentials and application port number. See code change.

• Adding files to $HOME directory: 4Clojure uses Clojail to safely run untrusted Clojure programs in a sandboxed environment.. This requires that a .java.policy file be created in the application's home directory (why?). Unlike Cloud Foundry, Stackato provides a way to run arbitrary commands during staging or starting of the application. These hooks can be defined in stackato.yml. A pre-running hook was added to copy the policy file to application's home directory just prior to starting it. See code change.

• A Stackato bug! - but, fortunately, we found a workaround. The application's environment contains a $HOME that is different from the one in /etc/password (this bug will be fixed in the next release of Stackato); to workaround that we had to force the JVM to consider $HOME as the value for the "user.home" property. This can be done by specifying a JVM_OPTS environment variable, which can be defined in stackato.yml as well. See code change.

• Missing programs: 4Clojure runs the git program to determine the release version/tag of the running application. Since git is not installed on the Stackato instances (LXC containers), we had to comment out the code that invoked git (only when running in Stackato) - by doing which no core functionality was lost. See code change.

For more details, visit the Stackato documentation on deploying Clojure applications.