prose :: and :: conz

Deploying Lift to CloudBees

In this post, I am going to outline out to get an existing Lift application up and running on the cloud. It’s so easy, it’s barely worth writing a blog. However, I’ve recently seen the question asked both on LinkedIn and Stackoverflow, so I feel it may be valuable for someone out there… perhaps even myself when I forget how to do it. I’ll show you how to use CloudBees in particular. It allows you quickly and easily run any WAR file, including a Lift application.

First a few comments on what I tried before settling on CloudBees. They were certainly not my first choice as I had not actually heard of them initially. I wanted to go with Google App Engine the first time I wanted to deploy. However, I never gave it a chance since David Pollak strongly advised against it, albeit possibly outdated coming from 2010. The first I tried was Heroku due to it’s popularity. Unfortunately I was never able to successfully deploy my application. I couldn’t even get the tooling to work in my Windows environment (yeah I know, Windows is notoriously annoying for development, but I don’t always get to choose). I had no use for patience as I’m interested in building and deploying an application. The whole cloud thing is supposed to remove all of the headaches that distract from development. Next I gave a chance was OpenShift by Red Hat. While I found that the community is certainly helpful, I still was unable to get deployed. Furthermore, I was getting more than I really wanted because it provides me the entire JBoss 6 stack. I just need Tomcat. Finally I stumbled across CloudBees.

Getting started with CloudBees is stupid easy as you shall soon see. That alone was reason enough for me to stick with them. What is even better is they have free offerings, which is great for me considering I’ve yet to have an idea that is worth spending money on. Finally, the tooling works on Windows (so probably everywhere else too).

Full disclosure: I am in no way affiliated with the CloudBees service. I’m just a thoroughly pleased customer. I also need to caution the reader that I have never had an application need more resources than the freebie service. I cannot vouch for how well scaling your application will go.

First things first. Sign up. Once you’re in, you should be able to add an application from your dashboard. It’s right in the middle:

Add Applications

The next thing you need to do is set the run.mode JVM system property to production. (Read about Lift Run Modes if you don’t know what I’m talking about). This is the part I wasted the most time debugging the first time around. I’ll also say this is the one part CloudBees could improve. (EDIT on 9/3/2014: They did! Now I can edit system properties in the dashboard. Thanks for listening, Cloudbees!) To do something as simple as setting a property, you have to download and configure CloudBees SDK on your system. Even the hopelessly discombobulated AWS allows me to configure system properties from the GUI. Oh well… Once you’ve set up the SDK, you can add all the system properties to your application you want/need.

To add a system property, start by executing bees config:list. This will perform some initial setup, including logging into CloudBees. If everything looks good there, run bees config:set as shown below along with sample output:

bees config:set -P run.mode=production
Do you want to set global or application parameters: (g/a) a
Enter application ID (ex: account/appname) : barnesjd/joe-app
Application config parameters for barnesjd/joe-app: saved

Application Parameters:

For more details on all of this configuration stuff, go to Environment variables, configuration parameters and system properties.

Now the stage is set. You may have already noticed that you can directly upload the war file produced by running package in sbt, but doing things through the GUI is lame and we want to use the command line (wait, didn’t he just complain about having to use the command line to configure system properties!?). Ah, astute observation, good reader. A momentary digression. If it’s one-time configuration, I want a GUI. That’s a good way to lead a dumb user down the right path. If it’s something I’ll do repeatedly, as in the case of uploading new versions of my app, I want a command line interface for that.

Thankfully Tim Perrett has built an excellent CloudBees sbt plugin. He has done an outstanding job documenting how to install and configure the plugin, allowing me to really gloss over these last steps.

Add the plugin to your sbt build file. At the time of this writing, version 0.4.1 is the latest. You only need to add four values to your project: the API Key, API Secret, username, and application ID. Get your API Key and Secret by navigating to your CloudBees user account page, and opening the Secret Keys page. Note that the first three values will apply to all of your projects deployed on CloudBees, so you may want to make those global.

After you’ve added those properties to your sbt build file(s), you just run the cloudbees-deploy task and you are done. Your application will be packaged into a war file and uploaded. The first time will be slowest, as it uploads the entire job. Every subsequent upload will only send the diff. Don’t panic if you see an exception after the task completes. I’ve seen this error both in Windows and Linux Mint environments and it appears harmless. Navigate to your CloudBees URL and see your running application.

Olde Comments
  1. info says:

    Hello there! Do you know if they make any plugins to
    protect against hackers? I’m kinda paranoid about losing everything
    I’ve worked hard on. Any tips?

    • barnesjd says:

      Lift is very secure by default. No need for plugins. CloudBees likewise does a good job of protecting your assets. It’s tough to answer such a general question, tho. You’ll have to consider what your application does and what types of threats it is vulnerable to.

Tagged with: scala (41), web-development (19), liftweb (9), tutorial (5), cloud (4), cloudbees (1)