Pivotal Web Services trial

Preconditions: Windows 7.

The Story:

Yesterday I received an invitation for a two-month free trial of the rising Pivotal Web Services. It’s kinda OpenShift, kinda Azure, etc. but with a bit of hipster style blended in. Just a bit.

Since the very first moment that I knew something about this service, I have been very intrigued by the promise that you can simply type something like

deploy just-this-war.war

in you terminal window and have your application up and running in the Internet. Something that I have been searching for since a looong time ago. I do not know why they sent me the invitation and I do not even remeber when I asked for it (It was probably a late drunk friday night) but here it is. Today I found some time to try the wordeful and valuable capabilities that Pivotal provides you with.

Sadly, the beginning has not been one of the most memorable. Or probably it has been, but in a not-so-positive sense. Just like OpenShift, Pivotal Web Services (PWS), require that you install some client side command line utilities to remotely manage your applications. Unlike OpenShift though, you do not have to go through an infinite sequence of installations. In this case you just have to install their little tiny lighweight client: cf.exe (cf stands for Cloud Foundry, I guess). Don’t get me wrong, it is a great improvement with respect to the paramount load of things that you have to install in order to manage your OpenShift instance. The only problem is that, once you’ve run the cf installer, no known command works anymore. “mvn package something“? No way: “mvn is not recognized as an internal or external command, operable program or batch file“. What?! Even if you type “cmd” you get the same laconic answer. You could already figure out the problem: the cf installer completely erases the ‘path’ environment variable. If you have been working with your machine for almost two years, as I did, installing tons and tons of programs, tools and utilities, this puts you in a very uncomfortable situation.

Luckily I found a solution to this problem online. Thank you to the guy who answered and thank you Internet. This saved me a lot of troubles.

At this point I was a bit upset, as you might imagine. But!… When the cf command is set up and working properly, the steps to deploy a Java webapp are the following:

first, tell cf which API endpoint to use with the command

cf api api.run.pivotal.io

then, you have to log in with:

cf login

API endpoint: https://api.run.pivotal.io

Username> xxx.xxx@gmail.com

Password>
Authenticating...
OK

API endpoint: https://api.run.pivotal.io (API version: 2.2.0)
User: xxx.xxx@gmail.com
Org: xxx
Space: stubgen

and, finally, the real magic:

cf push stubgen -p <path-to-your-war-file>

and voilà, the application is deployed and works like a charm.

Easy deployment made hard

I recently started “evaluating” OpenShift, the fanta-mega-giant cloud offer by Red Hat. OpenShift basically offers you what most so called cloud services offer today: virtual servers that you can remotly manage with a certain degree of autonomy. What took me to OpenShift was the fact that I was searching for a way to host a Java EE web application, possibly with a free basic plan. My initial idea was to find a provider of a simlple Tomcat 7 or 6 and a basic way to upload a WAR file. This requirement has turned out to be surprisingly hard to meet. So long, OpenShift has been the only platform to be able to satisfy me but it has been anything but easy to achieve.

OpenShift is capable of hosting a vast range of applications, spanning from PHP to Ruby On Rails, with almost anything you can imagine in the middle. One of the options is JBoss EWS, a profile that is able to host Tomcat which, in turn, can contain your applications.

Once you have your account you are in Red Hat territory and you have to follow their rules. It can take quite a long time to get started, especially if it is the first time that you do that. First, you have to install on your machine a lot of stuff to enable the development tools necessary to upload the applications and manage the server. Note: you have to install stuff to be able to install the OpenShift tools. Once you are done with Ruby, ssh and the rhc utility, you can create an application and start coding.

The basic configuration of the application is decided by OpenShift: you choose the name, OS choose all the rest. It creates a remote Git repository with a directory tree for your project and a Maven pom file for managing the build process. Now, if you have not already given up, you can clone the project and start coding on your dev machine. So OS gives you anything: a Git repo, an application server for deploying, a build process and a standard directory structure for your source files. Whenever you want to deploy your application remotely, you can do a “git push”: the server will automaticaly recognize the changes, start a build and, if anything goes right, deploy the resulting war. Seems easy, doesn’t it? Nop.

OS gives you much. It actually gives you too much. What if I have a preexistent project, possibly connected with another repository, and with dependencies from other projects? I just want to deploy the fucking war and see what happens, ok? I don’t what to spend three hours trying to figure out how I can map it all on the project created by OS. And I am sincerely thankful, OpenShift, for your commitment in making me aware of the advantages of continuous integration, but I just wanted to deploy the war, please.

I finally figured out that this is the answer to all my problems. The only thing is: you better read all the thread, because the final post is foundamental: you have to tell JBoss to unpack the war.